摘要：为什么我们就要使用 n（物理）层体系结构来构建系统？这是一篇基础性的文章，介绍了人们对于软件的一种理念，即当我们面对新项目时往往将系统明确地分为三个物理层次：表现层、业务逻辑层和数据访问或资源层。然而，对于循规蹈矩的做事方式应当重新审视。

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

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

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

例如，为什么我们就要使用 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 站点，并输入跟踪号码。使用相同的后端算法搜索同一后端数据存储系统，而不同的是，现在信息直接由客户输入而不是通过内部员工间接输入。但是，企业系统覆盖范围的扩大势必伴随着相应的成本，从前只有几百名用户（客户服务代表）的内部系统，目前却拥有几十万的潜在用户（客户）。这时我们会遇到一个瓶颈问题，大多数数据库服务器可以支持几百个并发的连接，然而并发连接如果达到几十万，很快就会使数据库陷于瘫痪。

但结果是，人们发现了这些并发连接的一个有趣特性：对于大多数客户机/服务器应用环境而言，针对数据库所建立的连接大多数时间（95% 以上）都处于空闲状态，来等待要针对数据库所执行的请求。也就是说，瓶颈在于连接的数量，而不在于所执行的任务。这就说明，要增加数据库的可伸缩性，我们需要以某种方式增加通过这些连接所完成的工作量。因此，我们创建了一个过渡层，客户机通过连接该过渡层以多工方式向数据库传输请求。简单地说，如果数据库只能支持 100 个连接，而每个客户机连接被用去 1% 的时间，那么我们可以这样来增加数据库的可伸缩性：将 100 个客户机连接到中间服务器，这个中间服务器仅使用 1 个连接（总共 100% 的时间，每个客户端占 1%）来对数据库进行操作。瞧，可伸缩性增加了一百倍。真不错。

尽管如此，有多少应用环境真正需要这种可伸缩性呢？当然，在将企业应用环境带到最终客户群面前的情况下，这种可伸缩性可能时必要的。但许多应用环境（无论是否基于 Web）仍然是完全部署在内部的，这种情况下只有不到 100（有时少于 10）个客户机将同时访问系统。在内部小用户群应用环境中还需要 n（物理）层方法吗？

这时安全因素发挥了作用。对于运行在最终用户计算机上的应用程序（基于 Web 或“富客户机”），任何系统管理员或安全顾问都不可能推荐将包含关键任务数据的数据库直接放在防火墙的后面（例如，从在安全范围之外运行的计算机直接访问）。如果加入一个中间计算机并将另一个防火墙置于其后，可以创建通常称为隔离区或 DMZ 的区域，在其中可以进一步限制对数据库的访问。这样一个 DMZ 极大地巩固了安全基础结构，降低了成功渗透的可能性。这不仅可以防止数据被窃取，而且还有助于保护服务器（及剩下的应用程序或系统）免受成功的拒绝服务攻击。

使许多大型系统所有者青睐 n（物理）层系统的另一个因素是部署，即物理地将软件放入客户机所能访问的计算机的过程。在传统的客户机/服务器环境中，业务逻辑与表现逻辑和数据访问逻辑交织在一起，使编程人员感觉非常不舒服：每次需要新的更新时（例如需要更改企业对数据的处理方式或增加数据的新视图），位于用户桌面的“胖客户机”就必须更换并/或加入新代码。这就意味着，至少在这个时候，有人（通常是开发人员或系统管理员，两者中级别较低的一个）需要在各计算机之间奔走，来安装新代码。或者是要求用户从网络下载最新的代码。当然，大多数的用户不是忽略了这一点就是不能正确操作。这两种情况都不能使人们对频繁发布这种明智之举真正产生信任。而且部署是需要时间的，在这段时间内，系统必须暂停工作，以避免因混合版本的应用程序匆忙操作数据库而造成的任何类型的语义数据损坏。

这一部署因素在很大程度上影响着人们对 n（物理）层模型，特别是对基于 Web 的应用程序的青睐程度。现在，人们无需再将代码部署到各用户桌面，而可以将其部署到（单个）Web 服务器，最终用户的浏览器只需去选取这些更改，而这并不需要任何进一步的工作。就其本身而言，部署并不是铺开 n（物理）层系统的原因；在传统客户机/服务器应用环境时代所无法获得的一些备选方案现在已经加入可能部署方案清单中，这其中包括“无触式部署”（在 .NET 1.x 中）和 ClickOnce（在 .NET 2.0 中），更不用说人们对 AJAX 和各种混合式结构日益浓厚的兴趣。事实上，发布能在启动时进行自我更新的富客户机应用程序（如我们在 iTunes 软件管理器、Windows Media Player，甚至是流行的 .NET 开发工具 Reflector 中所看到的）已变得越来越普遍。

采用 n 个物理层的第三个原因经常会被人们所提到，但往往却不能真正实现，即中间物理层可以成为一些业务逻辑的集中点，这些逻辑可以由多个表现物理层访问，却不能为它们所知。关于这一点的典型例子就是组合式内联网/外联网应用环境，其中内部员工使用 WinForms（很快将升级为 Windows Presentation Foundation）应用程序来访问中间层系统，中间层系统进而再访问数据库，而外部用户（合作伙伴和/或客户）使用 ASP.NET 或者可能是基于 SharePoint 的 Web 站点来进行同样的操作：访问中间层，中间层进而再访问数据库。

这个想法尽管在概念上似乎非常简单，然而事实证明要从结构上来可靠地实现它是极其困难的。也因为这个原因，区分物理层和逻辑层越发显得重要。如果在表现（逻辑）层、业务逻辑（逻辑）层和中间（物理）层之间有明确的区分，就可能将业务逻辑层嵌入客户机（物理）层（如果是富客户机应用前端）并通过避免网络访问来大大节约性能。

但是，设计在两个不同（物理）层中使用的业务逻辑层是非常棘手的事情。这就意味着，业务逻辑（逻辑）层必须避免对于表现（逻辑）层或数据访问（逻辑）层是否共同位于同一（物理）层做出任何假定，这样一来就必须假定两者都不位于其中。具体来说，在针对实际上运行于中间（物理）层服务器上的远程业务对象执行数据绑定（通过 .NET Remoting）时，这足以毁掉一个应用程序。现在，每次属性访问和方法调用都是一次网络遍历，性能将会比…嗯…比构建出如此糟糕系统的结构设计师的信誉下降得还要快。

幸运的是，世界各地的结构设计师已经开始意识到“分布式对象”方法的危险性，现在时代的主旋律是“松散耦合”和“粗粒度通信”，而所有这些都需要以面向服务的结构体系方法的支持。与软件开发的其他方面一样，服务导向也有其自身的缺陷，但那是其他月份另一个专栏的话题。