分层解耦形象化解析

---“餐厅模式”

---

一、 三层架构 (Three-Tier Architecture)

在专业开发中，我们绝不会把所有代码都塞进 Controller。我们会把程序拆成三个各司其职的“部门”：

1. Controller（表现层/控制层） ：餐厅的服务员。

   • 负责接收请求（点菜），检查参数，并把结果返回给用户。
   • 它不负责做饭，只负责沟通。

2. Service（业务逻辑层） ：后厨的大厨。

   • 负责核心逻辑。比如你之前写的“解析 user.txt、计算年龄、过滤数据”，都应该写在这里。
   • 它是整个程序的“大脑”。

3. Dao / Mapper（数据访问层） ：仓库管理员。

   • 负责跟数据打交道。不管是读 user.txt 还是读 MySQL 数据库，都是它的活。
   • 它只负责拿数据，不关心数据拿去干嘛。

---

二、 分层解耦 (Layered Decoupling)

为什么要分层？ 想象一下，如果厨师生病了，服务员是不是也得跟着下岗？这就是“强耦合”。

解耦的目的：

• 各司其职：如果以后你要把 user.txt 换成数据库，你只需要修改 Dao 层，Controller 和 Service 的代码一行都不用动。
• 方便协作：在公司里，你可能负责写 Service，同事负责写 Controller，大家互不干扰。

---

三、 IOC & DI 入门与详解

这是实现“解耦”的终极手段。

1. IoC (Inversion of Control) —— 控制反转

• 概念：正如我之前说的，它是“大管家”。

• 详解：你不再在代码里写 new UserService()，而是把这个类交给 Spring 管理。

• 怎么做：在类上面打个“戳”。常用的注解有：

  • @Component：通用组件。（不属于以下三类时用）
  • @Controller：专门给 Controller 层用的。
  • @Service：专门给 Service 层用的。
  • @Repository：专门给 Dao 层用的。(由于与mybatis整合，用的少）

2. DI (Dependency Injection) —— 依赖注入

• 概念：它是管家的“送货行为”。
• 详解：当 Controller 告诉 Spring “我需要一个 UserService”时，Spring 会自动把已经创建好的对象塞（注入）进你的变量里。
• 怎么做：使用 @Autowired 注解。

---

四、 总结对比表

概念	角色	核心注解	负责的任务
Controller	服务员	@RestController	接收请求，响应数据
Service	大厨	@Service	业务逻辑处理
Dao	仓管	@Repository	原始数据操作（读文件/数据库）
IoC/DI	管家	@Autowired	把上面三者粘合在一起，实现解耦

---