1.2　多层软件架构

对程序员来说很常见的一种情况是在没有合理的软件架构时就开始编程。在没有一个清晰的和定义好的架构的情况下，大多数开发者和架构师通常会使用标准式的传统多层架构模式（也被称为多层架构）。在多层架构中，通常将源码模块分割为几个不同的层。

应用程序缺乏合理的架构一般会导致程序的过度耦合、容易被破坏、难以应对变化等情况。这样的结果是，如果没有充分理解程序系统里的每个组件和模块，就很难定义这个程序的结构特征。

1.2.1　多层软件架构简介

多层架构是一种很常见的架构模式，也称为N层架构。这种架构是大多数企业级应用系统的实际标准，因此很多的架构师、设计师以及程序员都很熟悉多层架构。许多传统IT公司的组织架构和分层模式十分相似。因此，多层架构很自然地成为大多数应用程序的架构模式。

图1.8　常见的多层软件架构

多层架构模式的组件被分成几个平行的层次，每一层都代表了应用程序的一个功能（展示逻辑或者业务逻辑）。尽管多层架构没有规定自身要分成几层，大多数多层架构其结构都包括以下4个层次：展示层（也称为表现层，Presentation Layer）、业务层（也称为业务逻辑层，Business Layer）、持久层（也称为持久化层，Persistence Layer）和数据库层（Database Layer），如图1.8所示。有时候，业务层和持久层会合并成单独的业务层，尤其是持久层的逻辑绑定在业务层的组件当中。因此，有一些小的应用程序可能只有3层，而一些有着更复杂业务的应用程序可能会有5层或者更多的分层。

多层架构中的每一层都有着特定的角色和职能。例如，展示层负责处理所有的界面展示以及交互逻辑；业务层负责处理请求对应的业务。每一层是具体工作的高度抽象，都是为了实现某种特定的业务请求。例如，展示层不需要关心如何得到用户查询的数据，只需在屏幕上以特定的格式来展示这些数据。业务层不关心数据的展现形式，也不关心数据来自何处，只负责从持久层得到数据，执行与数据有关的相应业务逻辑，然后把这些信息传递给展示层。

多层架构的一个突出特点是组件之间的关注点分离。一个层中的组件只会处理本层的逻辑。例如，展示层的组件只会处理展示逻辑，而业务层中的组件则只会处理业务逻辑。利用组件分离的技术，能够更容易构造有效的角色和强有力的软件模型。这样极大地降低了应用程序的开发、测试、管理和维护等工作的成本。

1.2.2　多层软件架构的特点

图1.9　多层架构中每一层的封闭性

注意图1.9中每一层都是封闭的。这是多层架构中非常重要的特点。这意味着用户的请求必须一层一层地传递。例如，从展示层传递来的请求首先会传递到业务层，然后传递到持久层，最后才传递到数据层。

那么为什么不允许展示层直接访问数据层呢？如果只是获得以及读取数据，展示层直接访问数据层，比穿过很多层一步步得到数据快得多。之所以这么做，涉及一个概念：层隔离。层隔离是指架构中的某一层的改变不会影响到其他层，这些变化的影响范围仅限于当前层次。如果展示层能够直接访问持久层，展示层就会与持久层紧密相关。如果持久层中的结构变化了，展示层就会受到影响，很可能需要修改程序。这样会让应用变得紧耦合，组件之间互相依赖，这种架构的致命缺点是难以维护。从另外一个方面来说，分层隔离使得层与层之间都是相互独立的，架构中的每一层的相互了解都很少。为了说明这个概念的强大之处，可以想象一个超级重构：把展示层从JSP换成JSF。假设展示层和业务层之间的联系保持一致，业务层不会受到重构的影响，它和展示层所使用的界面技术完全独立。

然而封闭的架构层次也有不便之处，有时候也需要开放某一层。例如，如图1.10所示，新建了一个服务层。新的服务层是处于业务逻辑层之下的，表现层不能直接访问这个服务层中的组件。如果服务层是封闭的，业务逻辑层需要通过服务层才能访问到持久层，这样使操作复杂化，不合理。应将服务层设置为开放的，所有请求可以绕过这一层，直接访问持久层，这样就更加合理、灵活了。

图1.10　增加了开放的服务层的多层软件架构

开放和封闭层的概念确定了架构层和请求流之间的关系，并且给设计师和开发人员提供了必要的信息，以理解架构里各种层之间的访问限制。如果随意地开放或者封闭架构里的层，整个项目可能都是紧耦合、一团糟的，以后也难以测试、维护和部署。

多层架构是一个很可靠的架构模式，适合大多数的应用程序开发。从架构的角度考虑，选择这个模式还要考虑很多的因素，例如，整体灵活性、易于部署、可测试性、系统总体性能、可伸缩性、易开发性等方面。