增加新发现的问题
This commit is contained in:
@@ -3,6 +3,9 @@
|
||||
1. **服务层直接吐出数据库模型：** 导致控制器层直接感知并操作领域模型，增加了控制器与数据持久化细节的耦合。
|
||||
2. **服务层接收数据库对象或仓库层特定结构：** 控制器层直接构建数据库模型或仓库层查询选项并传递给服务层/仓库层，使得服务层接口不够抽象，且控制器承担了不应有的数据转换职责。
|
||||
3. **业务逻辑散落在控制器层：** 控制器层包含了大量的业务规则判断、领域对象的创建与验证、以及对仓库层和领域服务的直接协调，这违反了控制器层应只做数据校验、绑定解析和调用服务层方法的原则，导致业务逻辑分散、难以维护和测试。
|
||||
* **控制器直接进行领域模型内部字段的序列化/反序列化：** 例如，控制器直接对 `req.Properties` 进行 `json.Marshal` 操作，将领域模型的内部结构（如 JSON 字符串存储）暴露给控制器。
|
||||
* **控制器直接实例化领域模型对象：** 控制器直接通过 `&models.Xxx{...}` 实例化领域模型对象，而非通过服务层进行创建。
|
||||
* **控制器通过检查底层（仓库层或服务层）的特定错误类型或错误信息来执行业务判断：** 例如，通过 `strings.Contains(err.Error(), "...")` 或 `errors.Is(err, service.ErrXxx)` 来判断具体的业务错误类型，使得控制器与底层实现细节紧密耦合。
|
||||
|
||||
这些问题导致了代码的紧密耦合、可维护性差、测试困难，并且不利于后续的业务扩展和架构演进。
|
||||
|
||||
@@ -10,6 +13,9 @@
|
||||
本次重构旨在解决上述领域侵入问题，明确各层的职责，提升代码质量。主要变更包括：
|
||||
- **服务层接口标准化：** 确保服务层方法只接收 DTO 或基本参数，并只返回 DTO 或业务领域对象（而非数据库模型）。
|
||||
- **控制器层职责收敛：** 控制器层将仅负责请求参数的绑定与校验、调用服务层方法，并将服务层返回的 DTO 转换为 HTTP 响应。所有业务逻辑、领域对象的创建与验证、以及与仓库层的直接交互都将从控制器层移除并下沉到服务层。
|
||||
* **移除控制器中的领域模型内部字段序列化/反序列化逻辑：** 将此类操作下沉到服务层或专门的转换器中。
|
||||
* **移除控制器中直接实例化领域模型对象的逻辑：** 领域模型的创建应通过服务层完成。
|
||||
* **优化控制器中的业务错误处理：** 服务层将返回更抽象的业务错误，控制器层根据这些抽象错误进行统一的 HTTP 响应处理，避免直接依赖仓库层或服务层内部的具体错误类型或错误信息。
|
||||
- **DTO 转换逻辑下沉：** 将数据库模型与 DTO 之间的转换逻辑从控制器层移动到服务层内部或专门的转换器中。
|
||||
- **业务错误处理优化：** 服务层将返回更抽象的业务错误，控制器层根据这些抽象错误进行统一的 HTTP 响应处理，避免直接依赖仓库层或服务层内部的具体错误类型。
|
||||
|
||||
|
||||
@@ -28,13 +28,16 @@
|
||||
- [ ] 在服务层内部将输入 DTO 转换为 `models` 对象。
|
||||
- [ ] 在服务层内部将 `repository` 返回的 `models` 对象转换为 `dto.XxxResponse`。
|
||||
- [ ] 将 `SelfCheck()` 验证逻辑从控制器移入服务层。
|
||||
- [ ] 将 `Properties`, `Commands`, `Values` 的 JSON 序列化逻辑移入服务层。
|
||||
- [ ] 将 `ManualControl` 中的业务逻辑（如动作映射）移入服务层。
|
||||
- [ ] 将 `Properties`, `Commands`, `Values` 的 JSON 序列化逻辑从控制器移入服务层。
|
||||
- [ ] 将 `ManualControl` 中的业务逻辑（如动作映射）从控制器移入服务层。
|
||||
- [ ] 将控制器中直接调用 `repository` 方法的逻辑移入服务层。
|
||||
- [ ] 将控制器中通过检查 `repository` 错误信息处理业务规则的逻辑移入服务层。
|
||||
- [ ] 2.2.3 **修改 `internal/app/controller/device/device_controller.go`：**
|
||||
- [ ] 移除控制器中直接创建 `models.Device`, `models.AreaController`, `models.DeviceTemplate` 对象的逻辑。
|
||||
- [ ] 移除控制器中直接调用 `SelfCheck()` 的逻辑。
|
||||
- [ ] 移除控制器中直接调用 `repository` 方法的逻辑。
|
||||
- [ ] 移除控制器中通过检查 `repository` 错误信息处理业务规则的逻辑。
|
||||
- [ ] 移除控制器中 `Properties`, `Commands`, `Values` 的 JSON 序列化逻辑。
|
||||
- [ ] 调整服务层方法的调用，使其接收新的服务层输入 DTO 或基本参数，并直接处理服务层返回的 `dto.XxxResponse`。
|
||||
|
||||
### 2.3 `pig-farm` 模块
|
||||
@@ -83,11 +86,13 @@
|
||||
- [ ] 将 `CreateUser` 中处理用户名重复的业务逻辑移入服务层。
|
||||
- [ ] 将 `Login` 中进行密码验证的业务逻辑和协调 `tokenService` 的逻辑移入服务层。
|
||||
- [ ] 将 `ListUserHistory` 中强制覆盖 `UserID`、构建仓库层查询选项、枚举类型转换、以及处理服务层特定错误的逻辑移入服务层。
|
||||
- [ ] 将控制器中通过检查底层（仓库层或服务层）的特定错误类型或错误信息来执行业务判断的逻辑移入服务层。
|
||||
- [ ] 2.5.3 **修改 `internal/app/controller/user/user_controller.go`：**
|
||||
- [ ] 移除控制器中直接创建 `models.User` 对象和 `repository.UserActionLogListOptions` 的逻辑。
|
||||
- [ ] 移除控制器中处理用户名重复的业务逻辑。
|
||||
- [ ] 移除控制器中进行密码验证的业务逻辑和协调 `tokenService` 的逻辑。
|
||||
- [ ] 移除控制器中强制覆盖 `UserID`、构建仓库层查询选项、枚举类型转换、以及处理服务层特定错误的逻辑。
|
||||
- [ ] 移除控制器中通过检查底层（仓库层或服务层）的特定错误类型或错误信息来执行业务判断的逻辑。
|
||||
- [ ] 调整服务层方法的调用，使其接收新的服务层输入 DTO 或基本参数，并直接处理服务层返回的 `dto.XxxResponse`。
|
||||
|
||||
## 3. 验证与测试
|
||||
|
||||
Reference in New Issue
Block a user