层次结构风格

最常见的架构模式是分层架构模式，也被称为N层架构模式。这种模式是大多数Java EE应用程序的事实标准，因此被大多数架构师、设计师和开发人员广泛了解。分层架构模式与大多数公司的传统IT通信和组织结构密切相关，这使得它成为大多数商业应用程序的自然选择。

层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的）。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。

分层软件体系结构中的组件被组织成水平层，每一层在应用程序中执行特定的角色（例如，表现逻辑或业务逻辑）。尽管分层体系结构模式没有规定模式中必须存在的层的数量和类型，但大多数分层体系结构包括四个标准层：表现层、业务层、持久层和数据库（如下图所示）。在某些情况下，业务层和持久化层被合并成一个业务层，特别是当持久化逻辑（如SQL或HSQL）被嵌入到业务层组件中时。因此，较小的应用程序可能只有三个层，而较大和较复杂的商业应用程序可能包含五个或更多的层。

典型的层次结构图如下图所示：

如前所述，分层架构模式的每一层在应用程序中都有特定的角色和责任。例如，表现层将负责处理所有的用户界面和浏览器通信逻辑；而业务层将负责执行与请求相关的特定业务规则。架构中的每一层都围绕着满足特定业务请求所需的工作形成了一个抽象。例如，表现层不需要知道或担心如何获得客户数据；它只需要在屏幕上以特定格式显示这些信息。同样，业务层也不需要关心如何将客户数据格式化以便在屏幕上显示，甚至不需要关心客户数据来自哪里；它只需要从持久化层获得数据，对数据执行业务逻辑（例如，计算值或聚合数据），并将该信息传递给预发送层。

分层架构模式的一个强大的特点是组件之间的关注点分离。一个特定层中的组件只处理与该层有关的逻辑。例如，表现层的组件只处理预发送逻辑，而驻扎在业务层的组件只处理业务逻辑。这种类型的组件分类使得在你的架构中建立有效的角色和责任模型变得很容易，而且由于定义明确的组件接口和有限的组件范围，也使得使用这种架构模式开发、测试、管理和维护应用程序变得很容易。

这种风格支持基于可增加抽象层的设计。这样，允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件重用提供了强大的支持。

分层系统采用多个层次组织，每一层必须起且仅起两个作用：

（1）使用下层提供的功能。

（2）为上层提供服务。

最底层通常由硬件连接。

广为人知的分层系统的应用是TCP/IP五层网络模型、操作系统、数据库系统等。

优点：

–支持逐层抽象的系统设计，有利于设计者对一个复杂系统进行分解；

–支持更新，因为每一层至多和相邻的上下层交互，因此功能的改变通常只影响相邻的上下层；

–支持复用，如果某独立层保证了功能的完整性并且提供了文档化的接口，便可在多个语境中复用。一组标准接口也可以使用各种不同的实现方法。

–支持测试。具有定义明确的层接口以及交换层接口的各个实现的能力提高了可测试性。

缺点：

1. 并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；

2. 效率的降低：

–由分层风格构成的系统，运行效率往往低于整体结构。

–在上层中的服务如果有很多依赖于最底层，则相关的数据必须通过一些中间层的若干次转化，才能传到；

3. 很难找到合适的、正确的层次抽象方法：

–层数太少，分层不能完全发挥这种风格的可复用性、可更改性和可移植性上的潜力。

–层数过多，则引入不必要的复杂性和层间隔离冗余以及层间传输开销。

–目前，没有可行的广为人们所认可的层粒度的确定和层任务的分配方法。

三层架构是近年来经常使用的软件体系结构。该体系结构可以分为通用的3层架构与运行在互联网上的三层架构软件

传统的三层层次体系结构

显示层(Presentation layer): 

显示层通常包括用户图形界面，用于用户输入、用户请求与显示用户请求的返回结果等。

显示层调用应用层组件的过程，函数或者方法。但是应用层从来不会调用显示层的功能。

应用层(Application layer)：或者称为业务逻辑(Business Logic)层。主要包括应用的业务逻辑，实现了应用的商业功能。

该层的组件封装了应用的核心数据与功能。

在该层中，如果要访问数据库或者要将程序运行中产生的数据存储到数据库，必须调用永久数据存储层的相应的数据库访问方法，而不能直接访问数据库。

永久数据存储层(Permanent Data Storage layer)：该层包含数据库的访问与将永久数据存储到数据库中的功能。

在Java实现中，该层包含了利用JDBC写的数据库访问代码。

该层不能调用应用层与显示层，而只能将执行应用层的请求对数据库的访问结果返回给应用层。而应用层有可能将该数据返回给显示层。

三层层次架构与MVC软件体系结构的比较

在形式上，三层架构类似于MVC 架构，都是由三部分软件模块组成的，但是实际上它们是不同的。

两种架构相似之处如下：

都是由三部分软件模块组成的

三层架构的显示层与MVC架构的View类似；

三层架构的应用层与MVC架构的Model类似。

三层体系结构与MVC体系结构的区别如下：

各个模块之间的调用关系不同：

三层架构的一个根本原则是显示层不能直接越过应用层直接调用永久数据存储层的代码。首先显示层必须调用应用层，然后再由应用层的相关的方法转而调用永久数据存储层。不允许有相反方向的调用。因此，三层架构的交互是线性的； 

MVC架构的程序组件之间的交互是三角形的：View对象发送更新给Controller对象，Controller对象更新Model对象，并且View对象直接地从Model对象得到更新。

对数据库的访问方式不同：

三层架构指定一个永久数据访问层，所有对数据库的访问均有此层承担；

MVC架构没有指定专门的数据库访问模块，一般的情况下是由Model直接访问数据库，但是也没有排除Controller中直接访问数据库的可能。

关于控制模块的不同：

MVC架构中存在一个专门的Controller模块；

而层次架构中通常没有这样专门的模块。事实上，很多设计者在层次架构中的应用层里面单独地指定一个类似的控制模块。

值得注意的是，在3层架构中，应用层与表示层之间使用观察者模式必然会导致应用层对显示层的调用(notifyObservers())，这违反了层次架构的原则。但是考虑到采用观察者机制更新图形界面的效率，以上的小小的“违规”也是值得的。