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