分层架构介绍
# 分层
不分层的坏处有哪些?
耦合度过高,代码复用性差、扩展力弱
系统为什么要分层?
希望分工明确,各司其职。达到这样一个效果:降低代码耦合度、增强扩展力、组件的可复用性
各司其职(高内聚),轻松协作(低耦合),就是分层思想的目标
# 三层架构
1.表示层/界面层(User Interface): 跟用户打交道,接受用户的请求参数,显示处理结果的(jsp html servlet 等)
2.业务逻辑层(Business Logic Layer,对应 Service 层): 接受了界面层传递的数据,计算逻辑,调用数据库,获取数据
一个业务方法对应一个完整的事务
事务一定是在业务逻辑层控制的
3.持久化层/数据访问层(Data Access Layer,对应 DAO 层): 访问数据库,执行对数据的增删改查等
持久化
将 内存中的数据 保存到 关系型数据库 的过程称为持久化
# MVC 模式
MVC 架构模式是有名的软件架构模式之一
1.Model: 数据/业务
2.View: 视图/展示
3.Controller: 控制器
详见:
# DAO 模式
通俗的例子(自顶向下):
Controller 层像是一个服务员,他把客人(前端)点的菜(数据、请求的类型等)进行汇总什么口味、咸淡、量的多少,交给厨师长(Service 层)
厨师长(Service 层)则告诉沾板厨师(Dao 1)、汤料房(Dao 2)、配菜厨师(Dao 3)等(统称 Dao 层)他需要什么样的半成品
副厨们(Dao 层)就负责完成厨师长(Service)交代的任务
4 层
pojo (Plain Old Java Object)层:在各层之间传输数据。将数据库中的表对应成 Java 中的 Class。比如封装用户信息。
dao(Data Access Object)层(也叫 mapper 层):将 pojo 层的 class 中的操作(CRUD),映射成 sql 语句。与数据库交互,比如获取或更新用户数据。
service 层:组合使用 mapper 层 中的操作,实现具体的业务逻辑,如验证登录。
controller 层:用户与系统交互的入口。负责请求转发,接受前端页面过来的参数,传给相应 Service 处理,接到返回值,再传给页面。
class 操作 | 数据库操作 |
---|---|
Create | insert |
Retrieve | select |
剩下的 2 个操作:Update 对应 update,Delete 对应 delete
通俗的例子自底向上:
如果一个厨师既负责跑堂,又负责烹饪。那这个饭店的管理一定非常混乱吧!
小工就是 DAO,从食材库里(数据源)取出食材(原始数据),进行简单处理(数据对象化)
厨师就是 Service,找到小工(DAO),获取各种半成品(对象化数据),加工成顾客需要的菜肴(最终数据)
跑堂就是 Controller,负责接单(提交数据)上菜(响应数据),是顾客与后厨间的媒介(提供用户与后台程序的接口)
这个通俗易懂的故事从该链接转载:https://blog.csdn.net/qq_41810415/article/details/126545376 (opens new window)