层次化技术

Layered Technologies

首先从顶层的展现层开始讲述，因为这是最为简单的一层。就Web页面而言，我们的展现层会包含CSS（级联样式表）。我们也可以选择使用<font>标签以及它的color属性，但总体上应该避免使用此类标记。而且为了能够做到层次清晰，我们希望能通过某些方式来将标记与展现层分离。CSS完美地恰如其分地扮演了这个角色。

展现层之下就是各种标记了。对于Web标记，我们有两种主流选择，这两种选择之下又有一些更为明细的选项。两种选择分别是HTML和XHTML，它们又各自有不同的版本。虽然业内人士推荐使用XHTML，并且强调注意标准兼容。但我们也要认识到，就算你使用了HTML4也同样可以做到和标准兼容，只不过兼容的是另一个不同的标准罢了。对于分离标记和位于其下的逻辑层，我们有多种可用方法：模板技术和传统的简单的代码分离。如果来自于代码和标记混用的环境，保持代码分离会是一个良好的开端。通过将所有显示逻辑置于不同的文件中，并且将它们包含到你的逻辑中，你就能够在保持这两样事物的分离的同时，继续拥有在标记部分中使用一门威力强大的语言的能力。需要注意的是，沿用这种方法时，除非你能一直保持严格的标准并且有足够的危机意识，否则代码和标记很容易被逐渐混杂在一起。这种情况屡有发生，开发人员往往是还能坚持将显示逻辑分置

于不同文件中，但是应用逻辑却在不知不觉中混了进来。为了能够有效分离，显示逻辑和业务逻辑这两个方向的分离必须同时被保持。

代码分离也有很多不足之处：比如上一小节所提到的，容易牺牲原则，越过两层之间的分界线。一个开发人员的话，严格一些就可以避免产生这个问题。但是如果有多个开发人员一起工作于系统的逻辑层和标记层，真正的问题就来了。通过使用模板系统，我们可以强制实现逻辑和标记的分离，要求所需要的数据被明确地导出到模板域中，并且消除了标记的复杂语法。显式地将数据导入到模板，会强制系统设计人员考虑有哪些数据是需要被展示到标记层的，同时也保护了逻辑层，以免它不小心被标记层侵入。如果逻辑层必须明确命名要导出到模板的数据，那么模板开发人员就无法使用那些负责逻辑的开发人员不想导出的数据。这意味着逻辑开发人员可以按照他所喜爱的方式重写逻辑层，只要继续保持导出的接口不变，就无需担心这种改写会破坏其他层次。这是层次化软件的核心原则，我们在下一节会对这个问题进行进一步探讨。

至于模板系统的选择，每种语言都有一些优秀的备选项。对PHP开发人员，Smarty （http://smarty.php.net/）提供了一个抽象模板引擎，它将模板编译成为PHP，从而能够快速执行。Smarty的语法短小精炼，并强制将模板内外的数据清晰分离开来。如果你需要速度更快、功能更为强大的模板系统，可以考虑Savant（http://phpsavant.com/），它提供了一个这样的模板系统，这个系统中的模板是用PHP写的，但是它提供了数据作用域的强制分离和有用的数据格式化功能（事实上，代码端接口看上去就和Smarty一样）。对于Perl的偏好者，通常的选择是模板工具箱（Template Toolkit http://www.template-toolkit.org/）和Mason（http://www.masonhq.com/），这两者都提供了可扩展的模板语法。选择哪一个只是风格问题罢了，这两者都值得一看。

展现/页面逻辑和业务/应用逻辑这两个逻辑层次位于标记层之下。这些层次间保持分离非常重要——因为数据存储、操作的规则和用户与数据进行交互的规则在逻辑上截然不同。分离方法很大程度上取决于系统的总体架构以及采用哪种语言来构建这两个逻辑层次。

如果两层都使用PHP构建，那么这两层通常都会被放置在不同的文件组中。页面逻辑放在Web根目录下的.php文件中，而业务逻辑习惯上放在Web根目录以外的.inc文件中（我个人并不喜欢这种文件命名规则。我不推荐这么做，因为采用不同的方式命名这些文件暗示着你可能有时会将它们放在一起）。

如果两层都采用Perl语言，那么习惯上是通过使用模块的命名空间来区分层次，这也会达到文件在物理上分离的附加效果。比如页面逻辑可能放置在MyApp::WWW::*模块中，而

业务逻辑则放置在MyApp::Core::*模块中。这种结构也方便了将其他的交互逻辑层添加到不同的命名空间中，比如说MyApp::Mobile::*或者MyApp::WebServices::*。

如果两层采用了不同的技术实现，如企业级的主要的业务逻辑用C++/Java实现，而交互逻辑使用PHP/Perl实现，那么你自然而然的被强制分层了。现在的难点就转移到了如何让各个层次之间进行有效的交互。这个时候数据交换的接口和方法就非常重要了（因为缺少了这种交换，系统就什么也做不了），所以我们需要仔细地规划这个方面。第7章会深入探讨各种异构层次之间是如何进行通信的。

持久化存储居于我们“美味”的应用程序的最底部。将它和业务逻辑分离是很普遍的，尽管数据库的存储过程可能略微影响到这幅美景（影响这两层的分离）。本书不会涉及存储过程在业务逻辑中的使用，因为我们所用的核心技术并不支持存储过程，但存储过程对Web应用系统中的业务逻辑架构的重大影响还是值得一提的。如果你在使用PostgreSQL或者Oracle，那么你可能应该去找一本如何应用存储过程作为Web系统的逻辑核心的好书。

具体的用来进行数据存储的技术并不是很重要，因为无论采用哪种技术，它总是完成同样的工作。根据你的应用系统的目的，数据存储可能是数据库和/或文件系统。本书使用MySQL作为数据库技术以及类似于POSIX的文件系统作为文件存储技术（尽管我们通常不会提及这些）。关于如何设计和扩展你的应用中数据存储部分的详细内容将在随后的第9章介绍。