分层模式是最通用的架构,也被叫做N层架构模式
一、 模式分析
分层架构模式里的组件被分成几个平行的层次，每一层都代表了应用的一个功能(展示逻辑 或者业务逻辑)。尽管分层架构没有规定自身要分成几层几种，大多数的结构都分成四个层次: 表现层，业务层，持久层，和数据库层。 如图一，有时候，业务层和持久层会合并成单独的一个业务层，尤其是持久层的逻辑绑定在业 务层的组件当中，形成。因此，有一些小的应用可能只有3层，一些有着更复杂的业务的大应 用可能有5层或者更多的分层。
架构里的层次是具体工作的高度抽象，它们每一层都有特定的角色和职能，都是为了实现某种 特定的业务请求。比如说展示层并不需要关心怎样得到用户数据，它只需在屏幕上以特定的格 式展示信息。业务层并不关心要展示在屏幕上的用户数据格式，也不关心这些用户数据从哪里 来。它只需要从持久层得到数据，执行与数据有关的相应业务逻辑，然后把这些信息传递给展 示层。各层实现的功能如下:
表现层(presentation):用户界面,负责视觉和用户互动
业务层(business):实现业务逻辑
持久层(persistence):提供数据,SQL 语句就放在这一层
数据库(database):保存数据
二、 关系概念—层隔离
每一层都是封闭的。这是分层架构中非常重要的特点。这意味request必须一 层一层的传递。举个例子，从展示层传递来的请求首先会传递到业务层，然后传递到持久层， 最后才传递到数据层。
层隔离是说架构中的某一层的改变不会影响到其他层:这些变化的影响范围限于当前层次。 如果展示层能够直接访问持久层了，假如持久层中的SQL变化了，这对业务层和展示层都有一 定的影响。这只会让应用变得紧耦合，组件之间互相依赖。这种架构会非常的难以维护。分层 隔离使得层与层之间都是相互独立的，架构中的每一层的互相了解都很少。 然而封闭的架构层次也有不便之处，有时候也应该开放某一层。如果想往包含了一些由业 务层的组件调用的普通服务组件的架构中添加一个分享服务层。在这个例子里，新建一个服务 层通常是一个好主意，因为从架构上来说，它限制了分享服务访问业务层(也不允许访问展示 层)。如果没有隔离层，就没有任何架构来限制展示层访问普通服务，难以进行权限管理。 例如下面的例子，新的服务层是处于业务层之下的，展示层不能直接访问这个服务层中的 组件。但是现在业务层还要通过服务层才能访问到持久层，这一点也不合理。这是分层架构中 的老问题了，解决的办法是开放某些层。如图三所示，服务层现在是开放的了。请求可以绕过 这一层，直接访问这一层下面的层。既然服务层是开放的，业务层可以绕过服务层，直接访问 数据持久层。这样就非常合理。
开放和封闭层的概念确定了架构层和请求流之间的关系，并且给设计师和开发人员提供了 必要的信息理解架构里各种层之间的访问限制。如果随意的开放或者封闭架构里的层，整个项 目可能都是紧耦合，一团糟的。以后也难以测试，维护和部署。
三、 分层架构
用户界面只管接受请求以及显示客户信息。它不管怎么得到数据的，或者说得到这些数据 要用到哪些数据表。如果用户界面接到了一个查询客户信息的请求，它就会转发这个请求给用 户委托(Customer Delegate)模块。这个模块能找到业务层里对应的模块处理对应数据(约束关 系)。业务层里的customer object聚合了业务请求需要的所有信息(在这个例子里获取客户信 息)。这个模块调用持久层中的 customer dao 来得到客户信息，调用order dao来得到订单信 息。这些模块会执行SQL语句，然后返回相应的数据给业务层。当 customer object收到数据以 后，它就会聚合这些数据然后传递给 customer delegate,然后传递这些数据到customer screen 展示在用户面前
四、 分层架构的优缺点
优点：
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。
6、结构更加的明确
7、在后期维护的时候，极大地降低了维护成本和维护时间
缺点：
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数 据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加 一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增 加相应的代码。
3、增加了开发成本
