分层架构理论基础

一、三层架构

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层,是数据库在项目中的类,该文件包含实体类的属性和对应属性的setget方法。实体类中属性同数据库表字段一一对应,对于相应的setget方法一般不需要书写,实体类上引入@Data注解,会自动为实体类注入getset以及toString方法,减少代码量。

5、VO

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

6、DTO

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

7、POJOVODTO......都是什么?

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 操作。

猜你喜欢

转载自blog.csdn.net/weixin_36723038/article/details/128117824