一、三层架构

1、什么是三层架构

         三层架构（3-tier architecture）通常意义上的三层架构就是将整个业务应用划分为：表示层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。  

         区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。

 

2、各个层级的作用

表示层：主要对用户的请求接受，以及数据的返回，为客户端提供应用程序的访问。

业务逻辑层：主要负责对数据层的操作。也就是说把一些数据层的操作进行组合。

数据访问层：主要看数据层里面有没有包含逻辑处理，实际上它的各个函数主要完成各个对数据文件的操作。而不必管其他操作。

3、常见三层架构关系-饭店

                服务员(表示层)：待客/提交菜单 (客户)

　　　　 厨 师(业务逻辑层)：取材/炒菜/交菜  (逻辑处理)

　　　　 采购员(数据访问层)：采购 (数据库访问数据)

 4、三层架构中各功能模块如何联系

        这里就要提到Entity(实体层)：它不属于三层中的任何一层，但是它是必不可少的一层。对于大量的数据来说，用变量做参数有些复杂，因为参数量太多，容易搞混。比如：我要把员工信息传递到下层，信息包括：员工号、姓名、年龄、性别、工资.......用变量做参数的话，那么我们的方法中的参数就会很多，极有可能在使用时，将参数匹配搞混。这时候，如果用实体做参数，就会很方便，不用考虑参数匹配的问题，用到实体中哪个属性拿来直接用就可以，很方便。这样做也提高了效率。

 

两个相同功能的方法，User实体封装了userId、name、age、address 。

5、Entity在三层架构中的作用

        1）实现面向对象思想中的"封装";

        2）贯穿于三层，在三层之间传递数据;（注：确切的说实体层贯穿于三层之间，来连接三层）

        3）对于初学者来说，可以这样理解：每张数据表对应一个实体，即每个数据表中的字段对应实体中的属性（注：当然，事实上不是这样。         为什么？        1>)可能我们需要的实体在数据表对应的实体中并不存在        2>)我们完全可以将所有数据表中的所有字段都放在一个实体里）

        4）每一层（UI—>BLL—>DAL）之间的数据传递（单向）是靠变量或实体作为参数来传递的，这样就构造了三层之间的联系，完成了功能的实现。

6、三层架构的优势

        1）结构清晰、耦合度低

        2）可维护性高，可扩展性高

        3）利于开发任务同步进行, 容易适应需求变化

7、三层架构的劣势

        1）降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。

        2）有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码

        3）增加了代码量，增加了工作量

二、MVC模式

1、MVC模式是什么

        MVC是一种分层开发的模式，其中：

        M：Model，业务模型，处理业务

        V：View，视图，界面展示

        C：Controller，控制器，处理请求，调用模型和视图

        控制器（serlvet）用来接收浏览器发送过来的请求，控制器调用模型（javaBean）来获取数据，比如从数据库查询数据；控制器获取到数据后在交由视图（JSP）进行数据展示。

2、MVC好处

        1）职责单一。每个角色做它自己的事，各司其职。

        2）有利于分工协作。

        3）有利于组件重用

3、MVC模式在三层架构中的体现

数据访问层：对数据库的CRUD基本操作（单操作）

业务逻辑层：对业务逻辑进行封装，组合数据访问层层中基本功能，形成复杂的业务逻辑功能。例如 注册业务功能 ，我们会先调用 数据访问层 的 selectByName() 方法判断该用户名是否存在，如果不存在再调用 数据访问层 的 insert() 方法进行数据的添加操作 （复合操作）

表现层：接收请求，封装数据，调用业务逻辑层，响应数据

 

4、MVC模式在三层架构的每一层都有特有的包名称：

表现层： com.java.controller 或者 com.java.web或者 com.java.action

业务逻辑层：com.java.service

数据访问层：com.java.dao 或者 com.java.mapper

5、通过 MVC 和 三层架构 的学习，有些人肯定混淆了。那他们有什么区别和联系？

         如上图上半部分是 MVC 模式，上图下半部分是三层架构。 MVC 模式 中的 C（控制器）和 V（视图）就是 三层架构 中的表现层，而 MVC 模式 中的 M（模型）就是 三层架构 中的 业务逻辑层 和 数据访问层。

       可以将 MVC 模式 理解成是一个大的概念，而 三层架构 是对 MVC 模式 实现架构的思想。 那么我们以后按照要求将不同层的代码写在不同的包下，每一层里功能职责做到单一，将来如果将表现层的技术换掉，而业务逻辑层和数据访问层的代码不需要发生变化。

三、层次与名词解释

1、Controller层

        本层定义接口并调用service层接口方法完成业务逻辑。功能：接受前端请求，调用service，接受service返回的数据，之后响应给客户端。

2、Service层

        service层为业务服务，调用mapper层并提供给controller层使用，间接和数据库打交道。项目结构包括两部分，接口文件和接口实现类文件，接口文件中定义在controller层中调用的service层方法；接口实现类文件中完成service层接口中定义的方法的实现。注意：这里接口实现类中方法的实现是指业务逻辑的实现，可能有些方法并不能在实现类里完成真正意义上的实现，还需要在mapper层文件完成其真正意义上的实现（主要是和数据库交互）。

3、Mapper层

        mapper层为操作数据库的一层。mapper层分为两部分，mapper接口层和mapper.xml层。mapper接口层：定义在service接口中没有完成真正实现，需要通过书写SQL语句才能完成其功能的方法。

 4、Entity层

        也就是所谓的model，也称为pojo层，是数据库在项目中的类，该文件包含实体类的属性和对应属性的set、get方法。实体类中属性同数据库表字段一一对应，对于相应的set、get方法一般不需要书写，实体类上引入@Data注解，会自动为实体类注入get、set以及toString方法，减少代码量。

5、VO层

        视图对象，用于展示层，把某个指定页面的所有数据封装起来，方便前端获取数据，后端将前端需要 的数据做整合，打包成一个类。使用场景：如果在前端页面需要展示经过某些数据库操作才能展示的特定数据，一般在vo层中把操作过程中涉及的数据进行封装，方便前端获取。并在controller层定义对应接口时把返回类型规定为vo类。

6、DTO层

        数据对象传输层，负责屏蔽后端实体层，将UI要的数据进行重新定义和封装。因为后端在实际业务场景中需要存储大量数据，而用户需要的数据只是一部分，为了快速获取用户需要的数据，应该把用户经常用到的数据在dto层中进行封装，在调用服务层时，只需要调用一次便可完成所有的逻辑操作。

7、POJO、VO、DTO......都是什么？

 

PO(persistant object) 持久对象

        在 o/r 映射的时候出现的概念，如果没有 o/r 映射，没有这个概念存在了。通常对应数据模型 ( 数据库 ), 本身还有部分业务逻辑的处理。可以看成是与数据库中的表相映射的 java 对象。最简单的 PO 就是对应数据库中某个表中的一条记录，多个记录可以用 PO 的集合。 PO 中应该不包含任何对数据库的操作。

DO（Domain Object）领域对象

        就是从现实世界中抽象出来的有形或无形的业务实体。

TO(Transfer Object) ，数据传输对象 

        在应用程序不同 tie( 关系 ) 之间传输的对象

DTO（Data Transfer Object）数据传输对象

        这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于表示层与服务层之间的数据传输对象。

VO(value object) 值对象 

        视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来

BO(business object) 业务对象

        从业务模型的角度看 , 见 UML 元件领域模型中的领域对象。封装业务逻辑的 java 对象 , 通过调用 DAO 方法 , 结合 PO,VO 进行业务操作。 business object: 业务对象 主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。 比如一个简历，有教育经历、工作经历、社会关系等等。 我们可以把教育经历对应一个 PO ，工作经历对应一个 PO ，社会关系对应一个 PO 。 建立一个对应简历的 BO 对象处理简历，每个 BO 包含这些 PO 。 这样处理业务逻辑时，我们就可以针对 BO 去处理。

POJO(plain ordinary java object) 简单无规则 java 对象

        纯的传统意义的 java 对象。就是说在一些 Object/Relation Mapping 工具中，能够做到维护数据库表记录的 persisent object 完全是一个符合 Java Bean 规范的纯 Java 对象，没有增加别的属性和方法。我的理解就是最基本的 Java Bean ，只有属性字段及 setter 和 getter 方法！。

DAO(data access object) 数据访问对象

        是一个 sun 的一个标准 j2ee 设计模式， 这个模式中有个接口就是 DAO ，它负持久层的操作。为业务层提供接口。此对象用于访问数据库。通常和 PO 结合使用， DAO 中包含了各种数据库的操作方法。通过它的方法 , 结合 PO 对数据库进行相关的操作。夹在业务逻辑与数据库资源中间。配合 VO, 提供数据库的 CRUD 操作。