Spring MVC关于三层架构
在我们进行学习之前要先了解什么开发的三层架构以及MVC模式是啥。
概述
我们的开发架构一般都是基于两种形式,一种是C/S架构,也就是客户端/服务器,另一种是B/S架构,也就是浏览器/服务器。在JavaEE开发中,几乎全都是基于B/S架构的开发。那么在B/S架构中,系统标准的三层架构包括:表现层、业务层、持久层。三层架构在我们的实际开发中使用的非常多,所以我们的案例也都是基于三层架构设计的。
什么是三层架构
三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为:界面层(User Interface layer)、业务逻辑层(Business Logic Layer)、数据访问层(Data access layer)。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或称为领域层)、表示层。
简单的意思来讲就是要有三个层次,表现层用来描述界面以及和界面响应的比如web层以及与web层相连的MVC以及Servlet等等。业务层是写业务逻辑的,将表现层的数据拿到之后,根据需求进行业务逻辑的编写,具体要实现哪些接口,是调用哪些方法等等。最后就是持久层(数据层)这个层是处理数据的,用来后台连接数据库,MySQL,SQL Server等等,将后台的数据拿到手,在传回业务层。这种架构和我们在餐厅里的点餐的效果是一样的如下图所示。
三层架构中,每一层各司其职。
表现层:
表现层也就是我们常说的web层。他负责接受客服端请求,向客户端响应结果,通常客户端使用http协议请求web层,web需要接收http请求,完成http响应。
表现层包括展示层和控制层:控制层负责接收请求,展示层负责结果的展示。
表现层依赖业务层,接受到客户端请求一般会调用业务层进行业务处理,并将处理结果响应给客户端。
表现层的设计一般都使用MVC模型。(MVC是变现层的设计模型,和其他层没有关系)
业务层:
也就是我们常说的service层。他负责业务逻辑处理,和我们开发项目的需求息息相关。web层依赖业务层,但业务层不依赖web层。
业务层在业务处理时可能会依赖持久层,如果对数据持久化需要保证食物一致性。(也就是我们说的,事务应该放到业务层来控制)
持久层
也就是我们常说的dao层。负责数据持久化,包括数据层即数据库和数据访问层,数据库是对数据进行持久化的载体,数据访问层是业务层和持久层交互的接口,业务层需要通过数据访问层将数据持久化到数据库中。通俗地讲,持久层就是数据库交互,对数据库表进行增删改查的。
为什么使用三层
使用三层架构的目的:解耦!!!
耦合是指两个或两个以上的体系或两种运动形式间通过相互作用而彼此影响以至联合起来的现象。 解耦就是将两种运动分离开来处理问题,常用解耦方法就是忽略或简化对所研究问题影响较小的一种运动,只分析主要的运动。
同样拿上面饭店的例子来讲:
(1)服务员(UI层)请假——另找服务员;厨师(BLL层)辞职——招聘另一个厨师;采购员(DAL)辞职——招聘另一个采购员; (2)顾客反映:
-
1、你们店服务态度不好——服务员的问题。开除服务员;
-
2、你们店菜里有虫子——厨师的问题。换厨师;
任何一层发生变化都不会影响到另外一层!!!
综上所述、三层架构的优势:
- 1,结构清晰、耦合度低
- 2,可维护性高,可扩展性高
- 3,利于开发任务同步进行, 容易适应需求变化
三层架构的劣势:
- 1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。
- 2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码
- 3、增加了代码量,增加了工作量