在软件开发的过程中，我们通常分为三层，即Controller、Service、Dao，这样做的核心目的是：
- 分层解耦：各层职责固定单一，修改其中某一层不会影响其他层
- 复用性：Service 层可被多个 Controller 复用，Dao 层可被多个 Service 复用
- 可测试性：可单独测试每一层（如 Mock Service 测试 Controller，Mock Dao 测试 Service）。
- 可维护性：代码结构清晰，便于团队协作和后期维护。
1、控制层（controller）
-
职责：
- 接收用户请求（如HTTP请求），解析请求参数（如 URL、表单数据、JSON 等）
- 调用业务逻辑层（Service层）处理请求，获取处理结果
- 返回响应（如渲染页面、返回 JSON 数据、重定向等）
-
特点：
- 属于 表现层（Presentation Layer）的一部分，负责与用户直接交互
- 不处理业务逻辑，仅作为请求的入口和响应的出口
- 可能包含简单的参数校验（如格式检查），但核心校验应交给 Service 层
2、业务逻辑层（Service）
-
职责：
- 处理核心业务逻辑（如订单创建、用户权限校验、数据计算等）
- 协调多个 Dao 操作（如事务管理，确保多个数据库操作原子性）
- 数据验证（如业务规则的校验，例如“用户余额是否足够”）
-
特点：
- 属于 业务逻辑层（Business Logic Layer）
- 不直接操作数据库，而是通过调用 Dao 层完成数据存取
- 可能依赖多个 Dao 类，组合其功能完成复杂业务逻辑
3、持久层（Dao）
-
职责：
- 直接与数据库交互，完成数据的增删改查（CRUD）
- 封装 SQL 或 ORM 操作（如 MyBatis、Hibernate）
- 屏蔽底层数据库差异，对上层提供统一的数据访问接口
-
特点：
- 属于 数据访问层（Data Access Layer）
- 不处理业务逻辑，仅关注数据操作
- 通常以接口 + 实现类的形式存在，便于切换数据库或 ORM 框架
各层交互流程
- 用户发起请求 →
- Controller 接收请求，解析参数 →
- Controller 调用 Service 层处理业务逻辑 →
- Service 调用 Dao 层操作数据库 →
- Dao 返回数据 →
- Service 处理数据并返回结果 →
- Controller 将结果封装为响应返回给用户。
总结
- Controller：门面，负责 请求与响应的流转。
- Service：大脑，负责 业务逻辑的实现。
- Dao：双手，负责 与数据库的直接对话。
