2.3 核心组件与注解

2.3 核心组件与注解

本节摘要：Spring Boot 是"注解驱动"的框架——注解是给框架的指令。本节讲清三层组件（Controller、Service、Repository）的职责、常用注解的含义、以及"依赖注入"这个核心机制。

上手前先明确

阅读完本节，你应当能够：

1. 说出三层组件的职责
2. 掌握常用注解
3. 理解依赖注入
4. 看懂组件之间的调用
5. 按层组织自己的代码

一、问题与直觉

"注解是啥？"——把注解想成**"贴标签 + 下指令"**：贴上 @RestController，框架知道"这是接口层"；贴上 @Autowired，框架知道"帮我自动接上这个依赖"。注解让 Spring 自动做"接线"工作，你只关心业务。

二、核心原理

2.1 三层组件

2.2 依赖注入

@Service
public class UserService { ... }

@RestController
public class UserController {
    @Autowired
    private UserService userService;  // Spring 自动注入
}
​

依赖注入 = Spring 自动创建对象并接好依赖，不用手动 new——这是注解体系的核心机制。

💡 关键直觉：分层 + 注入 = 松耦合——每层只管自己的事，依赖由框架注入。改一层不动其他层，是三层架构的价值。

三、工程实践要点

3.1 常用注解速查

3.2 开发习惯

请求 → Controller 接
逻辑 → Service 写
数据 → Repository 管
别在 Controller 写业务逻辑
​

⚠️ 常见坑：Controller 里塞满业务逻辑。接口类只管"收请求返结果"，逻辑放 Service——混层代码难维护、难测试。

温故知新

• 要点一：三层——Controller、Service、Repository
• 要点二：注解是给框架的指令
• 要点三：依赖注入 = 框架自动接线
• 要点四：分层 + 注入 = 松耦合
• 要点五：Controller 别写业务逻辑
• 要点六：注解体系是 Spring 的"黑魔法"

组件会用了，下一节写接口——RESTful API 开发。

常见疑问

Q1：三层架构（Controller/Service/Repository）为什么要拆？

为了"职责单一、变化隔离"。Controller 只管收请求返结果，Service 只管业务规则，Repository 只管数据存取。好处有三：第一，改数据层的实现不影响接口层；第二，业务逻辑可以被多个接口复用；第三，每层可以独立测试。如果不分层，所有代码堆在 Controller 里，几百行后谁都改不动。所以"Controller 别写业务逻辑"不是洁癖，是工程必需。

Q2：依赖注入是什么？为什么不用 new？

依赖注入的核心是"对象不用自己创建依赖，由容器注入"。写 @Service 标记一个类，写 @Autowired 标记一个字段，Spring 启动时会扫描这些注解，自动创建对象并装配好依赖。好处是对象之间不硬编码绑定（松耦合），也方便测试时替换成 mock。你手动 new 也能跑，但那样就绕过了容器管理，拿不到 Spring 提供的代理、事务、日志等能力。

Q3：注解到底是怎么起作用的？

注解本身只是"标记"（元数据），起作用的是框架的扫描机制。Spring 启动时扫描指定包下的类，遇到 @RestController/@Service/@Repository 就把它们注册成"Bean"（由容器管理的对象），遇到 @Autowired 就把匹配的 Bean 注入进来。你可以把注解理解成"贴给框架看的标签"，框架按标签执行对应逻辑。看懂这个机制，你就理解了"注解驱动"的底层逻辑。

Q4：一个接口完整的调用链路是怎样的？

以"查用户列表"为例：请求到 Controller → Controller 调用 Service 的方法 → Service 调 Repository 查数据库 → 结果一路返回 → Controller 把对象列表转成 JSON 返回。整个链路体现了分层职责：Controller 不碰数据库，Repository 不写业务逻辑，Service 串联规则。画一遍这个链路图，Spring Boot 的分层就刻在你脑子里了。

工程实践要点

动手建议：写一个"用户管理"的小功能，强制自己按三层去组织：Controller 里只写接口和参数校验，Service 里写业务逻辑（比如"用户年龄不能小于 18"这类规则），Repository 里只做数据存取。写完观察每个类的注解和职责，你会发现代码结构清晰、各归其位。再试着在 Controller 里塞一段业务逻辑，运行后虽然能工作，但你会立刻感受到"混层"带来的混乱——亲身体会比讲道理管用。

实战演练：拆一个真实接口

为了真正理解三层架构，请把自己写的"用户管理"接口做一次"解剖"。步骤如下：

第一步，找出你写的用户接口，从请求入口开始，把一次"查用户列表"请求经过的每个类、每个方法按顺序写下来。你会得到一条链：控制器里的方法 → 服务里的方法 → 数据访问层的方法 → 返回结果。这条链就是本节讲的"请求的旅行路线"。

第二步，检查每一层的职责是否纯粹。问自己：控制器里有业务判断吗（比如判断用户年龄合不合法）？如果有，把这段逻辑挪到服务层。服务层里有数据访问代码吗（直接写 JPA 调用）？如果有，挪到数据访问层。清理完这两处，你会发现每一层都"各司其职"。

第三步，给你的服务层加一个事务注解，让一次"新增用户并记录日志"的操作在异常时能整体回滚。运行后故意让第二步抛异常，观察第一步的修改是否也被回滚——你亲手看到了事务对多层调用的保护。

第四步，把控制器、服务、数据访问三个类各写一个单元测试，验证它们各自的职责。测试写得糙没关系，重点是通过"能不能独立测"来检验你的分层是否干净——分层干净，每层都能单独测。

做完这四步，你不是"背下了三层架构"，而是"验证了三层架构"。这两者天差地别。

一句话记忆

三层架构的价值要靠动手来验证：画一次请求链路，清理一遍职责，加一次事务，测一遍每层。做完你会明白，注解不是装饰，分层不是摆设，它们共同撑起"能维护的后端代码"。