JavaEE 三层架构模式

什么是架构模式

要理解三层架构模式，我们得先搞清楚什么是架构模式。（这里说的架构模式是针对后端开发）

所谓架构就是系统最高级别的设计，一个系统特别复杂时才需要架构设计，如果只是开发一个很小程序，就谈不上架构设计了。而专门做架构设计的人就是架构师，这种人一般都是技术顶尖高手，而且只在大公司大系统开发中才有。而中小型公司是不太需要架构师的，为什么呢，马上就你会知道了。

所谓模式就是套路，换句话说，就是项目开发的固定流程或方式。

那么架构模式就是系统最高级别设计的套路。当架构师设计出架构模式，那么项目开发人员就必须按照相应的模式或流程做开发。

由于项目需求不同，所以架构师会设计很多不同的架构模式。而一些架构模式在很多项目开发中使用后，这些架构模式就变得非常流行了。比如，三层架构模式就是一个搞后端开发众所周知的架构模式，也是非常重要，需要掌握的架构模式。

为何三层架构模式对于后端开发人员这么重要呢？因为可以用它开发很多大型企业级 Web 项目。

什么是三层架构模式

三层架构模式采用一种分层的架构设计思想，将后端开发过程按照职责分为了三层：三层分别为表现层(UI)、业务逻辑层(BLL)、数据访问层或持久层(DAL)。

表现层（UI）：

表现层的职责：直接跟前端打交互（一是接收前端ajax请求，二是返回JSON数据给前端）。

业务逻辑层（BLL）：

业务逻辑层的职责：一是处理表现层转发过来的前端请求（也就是具体业务），二是将从数据访问层或持久层获取的数据返回到表现层。可以看出，业务逻辑层无疑是系统架构中体现核心价值的部分。

数据访问层或持久层（DAL）：

数据访问层或持久层的职责：直接操作数据库（针对数据的增添、删除、修改、查找等），并将获得的数据返回到上一层（也就是业务逻辑层）。

通过上图可以很清楚的看到整个前后端的流程，如下：

前端页面发送请求，请求通过网络来到 Web服务器（如Tomcat），Web 服务器收到请求将其转发给表现层；
表现层接收到请求后，取出请求数据但自己并不处理，然后转发给业务逻辑层专门负责处理请求；
业务逻辑层处理请求时，如果需要返回响应数据，则需要调用数据访问层或持久层；
数据访问层或持久层只干一件事，就是专门和数据库打交道，将数据库操作获得的数据返回给业务逻辑层；
业务逻辑层处理好后，又返回给表现层；
表现层又返回给 Web 服务器，Web 服务器则直接返回给前端页面；
前端页面收到数据后解析，并显示在页面上
整个一次 Web 请求/响应流程就结束了。

只要搞懂了这个流程，你就很容易明白基于三层架构模式的Web项目开发过程了。

三层架构模式的优缺点

优点：

降低软件系统构件之间的耦合度，实现“低耦合、高内聚”原则
提升系统灵活性，可以在接口相同的情况下替换某层的具体实现
可以增强复用度，下层可以为多个上层提供服务

缺点：

三层架构模式一定程度会降低系统的性能。这是不言而喻的，如果不采用三层架构，可以直接访问数据库，以此获取相应的数据，如今却必须通过三层来中转完成。　　
三层架构模式可能会导致各层的级联修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合三层架构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

总结

在软件架构设计中，三层架构模式是最常见，也是最重要的一种架构模式。人们期待分层设计能够达到“高内聚、低耦合”的设计目标。各层各司其职，使得开发人员分工明确，极大的提高了开发效率。虽然三层架构仍有不可避免的缺陷，但分层确实使代码维护、扩展非常方便，各层一定程度上达到了相互独立的目的，利大于弊。