Day19：Service 业务层（企业架构核心）

一、今日学习目标

1. Service 层职责（什么代码必须写这里，什么不能写）
2. IService 接口 + ServiceImpl 实现类（标准规范）
3. 依赖注入 DI
4. Service 调用仓储（Repository）
5. 事务、校验、逻辑、组合、DTO 转换
6. Controller 只做路由、参数接收、返回结果

---

二、核心理论（背会）

1. Service 层是干什么的？

• 处理业务规则
• 处理参数校验
• 处理事务
• 处理多表操作
• 处理Dto → Entity
• 处理异常抛出
• 不处理前端交互
• 不处理路由

2. 三层架构铁律

• Controller：接收请求 → 调用 Service → 返回格式
• Service：业务 + 事务 + 逻辑 + 组合调用仓储
• Repository：单表 CURD

3. 为什么要 IService 接口？

• 面向接口编程
• 方便单元测试
• 方便替换实现
• 企业规范

---

三、高频面试题 + 答案

1. Service 层为什么要写接口？不写行不行？

答案 ：行，但不规范。接口是为了解耦、规范、扩展、测试 。企业项目必须写接口。

2. Service、Repository、Controller 区别？

答案：

• Controller：接收参数、校验模型、返回格式
• Service：业务、事务、多表、逻辑
• Repository：单表 CURD

3. 事务应该写在哪一层？

答案 ：必须写在 Service，一个事务 = 一个业务方法。

4. Service 可以调用 Service 吗？

答案 ：可以，但避免循环依赖 。推荐：Service 调用 Repository / 其他 Service。

5. 业务逻辑可以写在 Controller 吗？

答案 ：**绝对不行！**Controller 只做入口，业务必须下沉 Service。

6. Service 是单例还是作用域？

答案 ：AddScoped 作用域（一次请求一个实例）。

---

四、今日实战练习：用户业务 Service 完整实现

要求

1. 新建 IUserService 接口
2. 新建 UserService 实现类
3. 注入 IUnitOfWork
4. 实现所有用户业务
5. Controller 完全不写业务
6. 统一返回 R<T>
7. 全部异步 async/await