实用体系结构：逻辑分层(1)

有些事物是如此坚定地挺进了我们的通俗文化之中，以至于不发生灾难性的事故就无法将其摈弃，即使它们早已不能适应我们的生活。这样的例子在法律界比比皆是，在当今时代或其他时代美国的市、州甚至联邦政府针对无意义的书籍都有相关的法律（据说，在亚利桑那州的某个小镇上，在公路中间倒车是违法的）。这不禁使人联想到一个老笑话：

一个刚结婚的男人看到妻子正在准备晚餐要吃的烤肉。他吃惊地发现，妻子在将肉放到烤盘中前，分别在两端切掉了大约两英寸的肉，然后扔掉。而当男人对妻子的这一行为表示惊讶时，妻子回答道“这会使肉的味道更好。而且，我的妈妈也总是这样做”。他好奇地给岳母打了电话，问她是否也切掉烤肉的两端，以及这样做的原因。“因为这会使肉的味道更好。而且，我的妈妈也总是这样做”。男人决心找出这个习惯的源头，于是又给妻子的外婆打了电话，当外婆回答她在准备烤肉的时候也要切掉肉的两端时，男人又接着问为什么。外婆立刻回答说“因为我的盘子太小了，装不下整块肉”。

毫无疑问，对于这种明显的循规蹈矩的做事方式应当重新审视。但遗憾的是，其他情况并不都如此显而易见。

例如，为什么我们就要使用 n（物理）层体系结构来构建系统？这是一篇基础性的文章，介绍了人们对于软件的一种理念，即当我们面对新项目时往往将系统明确地分为三个物理层次：表现层，用以处理所有用户输入和数据显示问题；业务逻辑层，存放所有“业务逻辑”（本身是一个完全无定性的名词，可准确表示说话者希望其表达的意思）；数据访问或资源层，存放用于检索、修改或存储数据的所有代码。当被问道为什么要这样做时，许多人只能说出最普通的答案，“因为我的老师（或前任主管或刚读过的一本书）总是这种做”。与普通的进程内调用相比，跨物理层通信会带来高达三到六个数量级的巨大性能成本，两者的差距就相当于一个是到楼下杂货店而另一个是到冥王星。（请参阅《Effective Enterprise Java》（有效的企业 Java）第 17 条）。仅仅因为妈妈总是这样做，我们就要丢掉好肉… 嗯 CPU 周期吗？

归根结底，请记住以物理分层的方式构建应用程序并不是开发人员的唯一选择。举个例子，想想 UNIX 开发人员早已熟知而 .NET 开发人员随着 Microsoft Windows PowerShell 的即将推出才开始领悟到的一个真谛：将小部件分割成可以互馈的片段可以创建出一些功能极强的合成工具，避免了用来维护复杂应用程序所需的相应复杂性。例如，对一般的 C# 或 Visual Basic 语言开发人员而言，创建一个能够在文本文件中搜索并替换某个字符串序列的工具可能是件容易的工作，而这对于掌握 PowerShell 的人则更加显得微不足道，因为它只需串联几个“cmdlets”：其中一个用于遍历文件，另一个用于搜索文件内容并用新文本替换所搜索的文本，第三个用于将新内容写入磁盘。这是一个非常好的模型。具体而言，由于每个组件都能够专注于特定的任务（遍历、搜索、写入），从而简化了它们的维护和设计工作。

在匆忙地对 n（物理）层模型做出审判之前，它应该得到一次救赎的机会。对于初学者，我们可以对过于通用的“n 层”一词的使用稍加重新界定，并指出“物理层”和“逻辑层”的重要区别。（请参阅 Martin Fowler 的《Patterns of Enterprise Application Architecture》（企业应用体系结构的模式），阅读关于这一主题的完整论述。）

“逻辑层”是对软件的逻辑分割，是在开发人员级对各关注点的基础分割，这样我们可以更加容易地划分系统的职责。这在 [POSA1] 中有进一步的论述。在这本书中谈及逻辑层模式时讲到，使用逻辑层“有助于构筑可以分解为子任务组（每组子任务处于某个抽象级别）的应用程序”。换句话说，它是对各关注点的典型分割方式：将企业系统中所涉及的各种任务（包括检索数据、存储数据、针对数据执行业务规则、显示数据、搜集输入值等等）分割为组件或子节，以便我们能够更加轻松地跟踪在何时何处发生了什么。当然，最为常见的方式是将任务分为“表现”、“逻辑”和“数据访问”（逻辑）层。但请注意，我们并没有立即假定每个逻辑层将在“哪里”运行，目前还没有。

而另一方面，“物理层”是硬件（通常是某种形式的计算机）的物理分层，我们系统的一部分或全部可以运行于其上。传统的客户机/服务器计算（即写入可以针对运行于单独服务器上的数据库执行 SQL 语句的程序）是一个由两个物理层构成的系统。我们每天都享用的万维网也是在两（物理）层方法的基础上构建的，其中一个物理层（即客户机）位于某人的家中或办公室内并远程访问位于某处服务器机房中的另一个物理层。这样的例子数不胜数。

这似乎有些文不切题。归根结底，表现层不总是在客户计算机上吗？数据访问层不总是在数据库服务器上吗？而业务逻辑层不总是在前两者之间某处的计算机上吗？我们来进一步研究一下基于 Web 的典型三（物理）层应用程序模型：

◆基于 Web 的应用程序中的“表现”逻辑层是 Web 浏览器，因此不在我们的掌控之中。浏览器将要显示的 HTML 通常必须从服务器内所运行的某种形式（ASP 或 ASP.NET）的代码组件中生成并被发送给浏览器。这就意味着“表现”逻辑层现在要跨两个物理层进行分割。 

◆同样，“数据访问“逻辑层也并不是完全位于数据库物理层，因为用于访问和处理数据的命令（即 SQL）必须从数据库层之外被生成和发送。这就意味着，与表现逻辑层一样，数据访问逻辑层代码现在至少要跨两个物理层进行分割。  

这使我们认识到，尽管人们似乎很自然地认为表现逻辑层是在客户机物理层上运行，而实际上这种情况仅存在于目前称为“富客户机”或“智能客户机”的应用环境中。除此之外，“物理层”和“逻辑层”之间的联系多半是偶然的，决不是从前认为的一对一的映射。

软件设计逻辑分层背后的原理和原因是众所周知的，并且在软件体系结构领域已被普遍接受。（如果您不相信，或是想了解关于这一主题的详细论述，请参阅 2006 年 8 月“MSDN 杂志”的“设计模式”专栏。该专栏详细介绍了 Model-View-Presenter 模式，说明了将逻辑与用户界面相分割的意图和原因。）然而，物理分层仍然是一个见仁见智的讨论话题；如果要将数据推到网络中去，确保进行物理分层确实是十分必要的。

在某种程度上，要理解我们为什么至少需要两个物理层是相当容易的，因为出于成本和数据集中化考虑，我们通常不希望将服务器级计算机放在用户面前。但大多数关于 n 个物理层的讨论中会提到第三个物理层，负责托管业务组件或逻辑；在规范的 Web 应用程序图表中，有时还会出现第四个物理层，这四层分别是客户端层、Web 服务器层、业务逻辑层和数据库层。为什么是四个物理层？就这点而论，为什么要多于两个物理层？

从历史角度来说，有两种力量相互结合催生了 n（物理）层方法。第一种是对可伸缩性的需求：随着 Internet 的发展以及 Web 为越来越多的最终用户所使用，企业意识到他们可以将企业系统推向个人客户，将许多从前由内部系统（呼叫中心员工）所做的工作从公司转移到 Web 上。例如，在 1980 年，客户必须打电话给运输公司，来向客户服务代表询问某件包裹到了哪里了。客户服务代表会询问跟踪号码，然后使用内部软件系统来发现包裹的位置。而到了 2005 年，该客户只需将所选 Web 浏览器指向运输公司的 Web 站点，并输入跟踪号码。使用相同的后端算法搜索同一后端数据存储系统，而不同的是，现在信息直接由客户输入而不是通过内部员工间接输入。但是，企业系统覆盖范围的扩大势必伴随着相应的成本，从前只有几百名用户（客户服务代表）的内部系统，目前却拥有几十万的潜在用户（客户）。这时我们会遇到一个瓶颈问题，大多数数据库服务器可以支持几百个并发的连接，然而并发连接如果达到几十万，很快就会使数据库陷于瘫痪。