三层架构
三层架构把程序分成三部分，各司其职，便于维护与扩展：
Controller（控制层 / 接口层）→ Service（业务层）→ Mapper/DAO（持久层）
概览
- 目标：每层只做一类事，职责单一，降低耦合。
- 好处：易维护、易测试、易扩展、便于多人协作。
Controller（控制层 / 接口层）
前台接待与传话筒。
主要职责
- 接收请求（URL、Headers、Body、参数）。
- 做入参校验（是否缺失、格式是否合法、简单鉴权）。
- 调用 Service，传递必要参数。
- 封装 Service 返回值为响应格式（JSON/HTTP status），返回给前端。
不该做
- 不实现复杂业务逻辑。
- 不写 SQL、不直接访问数据库。
原则
- 薄控制层：只做协调与验证，保持简单易读。
Service（业务层）
业务逻辑的大脑。
主要职责
- 实现业务规则（权限判断、折扣规则、状态机、事务编排等）。
- 组织调用多个 Mapper 或第三方服务，串联业务流程。
- 处理事务边界（开启/提交/回滚）。
- 返回业务结果给 Controller。
不该做
- 不直接操作 SQL 或处理请求/响应的细节（HTTP、序列化等）。
原则
- 业务集中化、可复用、可单元测试。尽量纯粹（无 UI/协议依赖）。
Mapper / DAO（持久层）
数据库搬运工与翻译官。
主要职责
- 执行 SQL（查询/插入/更新/删除）。
- 将数据库记录映射为实体对象（Entity/POJO），或将对象转换为 SQL 参数。
- 提供基础的增删改查接口给 Service 使用。
不该做
- 不处理复杂业务规则、不做跨表业务决策。
原则
- 单一职责：只关心数据持久化与映射，保持稳定、可替换（例如切换 ORM 或数据库）。
请求/数据流（简明）
前端请求 ↓ Controller（校验、解析） ↓ Service（业务逻辑、事务、调用多个 Mapper） ↓ Mapper/DAO（执行 SQL、返回实体） ↓ Service（整合结果） ↓ Controller（封装为 JSON） ↓ 前端收到响应快速对照表
| 层 | 主要角色 | 做什么 | 不做 |
|---|---|---|---|
| Controller | 接口/路由 | 接收请求、校验、转交、响应 | 写业务、写 SQL |
| Service | 业务逻辑 | 核心逻辑、流程编排、事务 | 直接操作数据库、处理 HTTP 细节 |
| Mapper/DAO | 持久化 | 执行 SQL、对象映射 | 写业务规则、处理事务决策 |
常见示例流程（订单更新）
- 前端发来更新订单请求（
/orders/123/update）。 - Controller 校验 token、校验参数是否完整。
- Controller 调用
OrderService.updateOrder(userId, orderDto)。 - Service 检查用户权限、校验订单状态、开始事务。
- Service 调用
OrderMapper.selectById(123)、InventoryMapper.decrease(...)等。 - Mapper 执行 SQL 并返回实体。
- Service 整合结果，提交事务，返回业务结果。
- Controller 将结果封装为 JSON 并返回前端。
结论
三层架构让“接待（Controller）→ 决策（Service）→ 搬运（Mapper）”各自专注，系统更清晰、可维护、可测试。
