分层架构介绍
# 分层
不分层的坏处有哪些？
耦合度过高，代码复用性差、扩展力弱
系统为什么要分层？
希望分工明确，各司其职。达到这样一个效果：降低代码耦合度、增强扩展力、组件的可复用性
各司其职（高内聚），轻松协作（低耦合），就是分层思想的目标
# 三层架构
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)