企业应用程序中层的演化(The Evolution of Layers in Enterprise Applications)

层的概念在90年代随着客户端-服务端(以下简称C/S)系统的而出现。它们是两层系统：客户端持有用户界面和其它应用程序代码。服务端通常是关系型数据库。常用的客户端工具是VB，Powerbuilder和Delphi。因为这些工具拥有可以调用SQL的UI组件，使得创建数据密集型的应用程序变得很容易。你可以通过将控件拖到设计区域，使用控件属性关联属性和数据库的方式来创建一个表单。

如果应用程序都是对关系数据进行显示和做简单的更新，那么这些C/S系统会工作得非常好。但是问题出自于domain logic：业务逻辑、校验、计算，等等。通常人们会在客户端进行这些处理，但这种方法是非常难以使用的，并经常通过将逻辑直接嵌入UI界面中。当domain logig变得越来越复杂时，处理这些代码会变得非常难以处理。而且，在界面中嵌入逻辑很容易出现重复代码，这就意味着一个简单的改动就必须在多个界面中进行修改。

一个替代方案是将domain logic放到数据库的存储过程中。但是，存储过程对于结构化的限制会导致笨拙的代码。并且，很多人喜欢关系型数据库的原因是SQL是标准的，这样可以允许他们更换他们的数据库而不用过高的迁移成本。但因为存储过程是每种数据库所私有的，它会致使人们放弃这种选择。

同时，C/S变得普及起来，面向对象的设计方法使用得越来越多。面向对象的支持者为domain logic的问题提供了一个答案：转移到三层系统。在这个方案中，你有一个处理UI的表现层，处理业务逻辑的的domain层，和数据源。通过这个方法，可以将所有复杂domain logic移出UI，将它放入到一个你可以使用对象正确构建它的层中。

不管这些，面向对象的流行取得了一些进展。事实就是，很多系统是很简单的，或者至少刚开始的时候是如此。虽然三层架构有很多的优点，如果你的问题是简单的，那么使用C/S是更好的选择。如果使用三层配置，C/S系统的构建是非常困难，甚至是不可能的。（这一段不好理解）

突然间Web流行起来，人们希望使用Web浏览器部署C/S应用程序。然而，如果你的所有业务逻辑都在富客户端中，那么现在这些业务逻辑必须在Web界面中重复一次。一个设计良好的三层系统应该可以仅仅加入一个表现层就解决这个问题了。此外Java这个面向的语言可以创建更少地依赖SQL的Web页面，这样就出现了第三层。

当人们讨论分层的时候，通常会混淆两个“layer”和“tier”术语。一般情况下，它们是同义词，但是多数人把“tier”看作是对物理分离的实现。C/S系统有时也称作两层（tow-tier）系统，因为它的分离是物理的：客户端是一个桌面系统，服务器是一个服务器系统。我使用“layer”来强调你不需要在不同的机器上运行不同的层。domain logic中不同的层可以运行在桌面或数据库服务器上。在这种情况下我们有两个结点，但是却有三个不同的层。在一台拥有本地数据库的笔记本电脑上，我们有完整的三层，却只有一个结点。