归档改动方案
This commit is contained in:
@@ -0,0 +1,34 @@
|
||||
# 任务接口增加获取关联设备ID方法设计
|
||||
|
||||
## 1. 需求
|
||||
|
||||
为了在设备删除前进行验证，需要为任务接口增加一个方法，该方法能够直接返回指定任务配置中所有关联的设备ID列表。所有实现 `task` 接口的对象都必须实现此方法。
|
||||
|
||||
## 2. 新接口定义：`TaskDeviceIDResolver`
|
||||
|
||||
```go
|
||||
// TaskDeviceIDResolver 定义了从任务配置中解析设备ID的方法
|
||||
type TaskDeviceIDResolver interface {
|
||||
// ResolveDeviceIDs 从任务配置中解析并返回所有关联的设备ID列表
|
||||
// 返回值: uint数组，每个字符串代表一个设备ID
|
||||
ResolveDeviceIDs() ([]uint, error)
|
||||
}
|
||||
```
|
||||
|
||||
## 3. `task` 接口更新
|
||||
|
||||
`task` 接口将嵌入 `TaskDeviceIDResolver` 接口。
|
||||
|
||||
```go
|
||||
// Task 接口（示例，具体结构可能不同）
|
||||
type Task interface {
|
||||
// ... 其他现有方法 ...
|
||||
|
||||
// 嵌入 TaskDeviceIDResolver 接口
|
||||
TaskDeviceIDResolver
|
||||
}
|
||||
```
|
||||
|
||||
## 4. 实现要求
|
||||
|
||||
所有当前及未来实现 `Task` 接口的类型，都必须实现 `TaskDeviceIDResolver` 接口中定义的所有方法，即 `ResolveDeviceIDs` 方法。
|
||||
@@ -0,0 +1,41 @@
|
||||
# 方案：删除设备前的使用校验
|
||||
|
||||
## 1. 目标
|
||||
|
||||
在删除设备前，检查该设备是否被任何任务关联。如果设备正在被使用，则禁止删除，并向用户返回明确的错误提示。
|
||||
|
||||
## 2. 核心思路
|
||||
|
||||
我们将遵循您项目清晰的分层架构，将“检查设备是否被任务使用”这一业务规则放在 **应用层** (`internal/app/service/`)
|
||||
中进行协调。当上层请求删除设备时，应用服务会先调用仓库层查询 `device_tasks` 关联表，如果发现设备仍被任务关联，则会拒绝删除并返回一个明确的业务错误。
|
||||
|
||||
## 3. 实施步骤
|
||||
|
||||
### 3.1. 仓库层 (`DeviceRepository`)
|
||||
|
||||
- **动作**: 在 `internal/infra/repository/device_repository.go` 的 `DeviceRepository` 接口中，增加一个新方法
|
||||
`IsDeviceInUse(deviceID uint) (bool, error)`。
|
||||
- **实现**: 在 `gormDeviceRepository` 中实现此方法。该方法将通过对 `models.DeviceTask` 模型执行 `Count`
|
||||
操作来高效地判断是否存在 `device_id` 匹配的记录。这比查询完整记录性能更好。
|
||||
|
||||
### 3.2. 应用层 (`DeviceService`)
|
||||
|
||||
- **动作**:
|
||||
1. 在 `internal/app/service/device_service.go` 文件顶部定义一个新的错误变量 `ErrDeviceInUse`，例如
|
||||
`var ErrDeviceInUse = errors.New("设备正在被一个或多个任务使用，无法删除")`。
|
||||
2. 修改该文件中的 `DeleteDevice` 方法。
|
||||
- **实现**: 在 `DeleteDevice` 方法中，在调用 `s.deviceRepo.Delete()` 之前，先调用我们刚刚创建的
|
||||
`s.deviceRepo.IsDeviceInUse()` 方法。如果返回 `true`，则立即返回 `ErrDeviceInUse` 错误，中断删除流程。
|
||||
|
||||
### 3.3. 表现层 (`DeviceController`)
|
||||
|
||||
- **动作**: 修改 `internal/app/controller/device/device_controller.go` 中的 `DeleteDevice` 方法。
|
||||
- **实现**: 在错误处理逻辑中，增加一个 `case` 来专门捕获从服务层返回的 `service.ErrDeviceInUse`
|
||||
错误。当捕获到此错误时，返回一个带有明确提示信息（如“设备正在被任务使用，无法删除”）和合适 HTTP 状态码（例如 `409 Conflict`）的错误响应。
|
||||
|
||||
## 4. 方案优势
|
||||
|
||||
- **职责清晰**: 业务流程的编排和校验逻辑被正确地放置在应用层，符合您项目清晰的分层架构。
|
||||
- **高效查询**: 通过 `COUNT` 查询代替 `Find`，避免了不必要的数据加载，性能更佳。
|
||||
- **代码内聚**: 与设备相关的数据库操作都统一封装在 `DeviceRepository` 中。
|
||||
- **用户友好**: 通过在控制器层处理特定业务错误，可以给前端返回明确、可操作的错误信息。
|
||||
@@ -0,0 +1,111 @@
|
||||
# 方案：维护设备与任务的关联关系
|
||||
|
||||
## 1. 目标
|
||||
|
||||
在对计划（Plan）及其包含的任务（Task）进行创建、更新、删除（CRUD）操作时，同步维护 `device_tasks` 这张多对多关联表。
|
||||
|
||||
这是实现“删除设备前检查其是否被任务使用”这一需求的基础。
|
||||
|
||||
## 2. 核心挑战
|
||||
|
||||
1. **参数结构异构性**：不同类型的任务（`TaskType`），其设备 ID 存储在 `Parameters` (JSON) 字段中的 `key` 和数据结构（单个 ID
|
||||
或 ID 数组）各不相同。
|
||||
2. **分层架构原则**：解析 `Parameters` 以提取设备 ID 的逻辑属于 **业务规则**，需要找到一个合适的位置来封装它，以维持各层职责的清晰。
|
||||
|
||||
## 3. 方案设计
|
||||
|
||||
本方案旨在最大化地复用现有领域模型和逻辑，通过扩展 `TaskFactory` 来实现设备ID的解析，从而保持了各领域模块的高内聚和低耦合。
|
||||
|
||||
### 3.1. 核心思路：复用领域对象与工厂
|
||||
|
||||
我们不移动任何结构体，也不在 `plan` 包中引入任何具体任务的实现细节。取而代之，我们利用现有的 `TaskFactory`
|
||||
和各个任务领域对象自身的能力来解析参数。
|
||||
|
||||
每个具体的任务领域对象（如 `ReleaseFeedWeightTask`）最了解如何解析自己的 `Parameters`。因此，我们将解析设备ID的责任完全交还给它们。
|
||||
|
||||
### 3.2. 扩展 `TaskFactory`
|
||||
|
||||
- **动作**：在 `plan.TaskFactory` 接口中增加一个新方法 `CreateTaskFromModel(*models.Task) (TaskDeviceIDResolver, error)`。
|
||||
- **目的**：此方法允许我们在非任务执行的场景下（例如，在增删改查计划时），仅根据数据库模型 `models.Task` 来创建一个临时的、轻量级的任务领域对象。
|
||||
- **实现**：在 `internal/domain/task/task.go` 的 `taskFactory` 中实现此方法。它会根据传入的 `taskModel.Type`，`switch-case`
|
||||
来调用相应的构造函数（如 `NewReleaseFeedWeightTask`）创建实例。
|
||||
- **实现**：
|
||||
- **优势**：
|
||||
- **高内聚，低耦合**：`plan` 包保持通用，无需了解任何具体任务的参数细节。参数定义和解析逻辑都保留在各自的 `task` 包内。
|
||||
- **逻辑复用**：完美复用了您已在 `ReleaseFeedWeightTask` 中实现的 `ResolveDeviceIDs` 方法，避免了重复代码。
|
||||
|
||||
### 3.3. 调整领域服务层 (`PlanService`)
|
||||
|
||||
`PlanService` 将作为此业务用例的核心编排者。借助 `UnitOfWork` 模式，它可以在单个事务中协调多个仓库，完成数据准备和持久化。
|
||||
|
||||
- **职责**：在创建或更新计划的业务流程中，负责解析任务参数、准备设备关联数据，并调用仓库层完成持久化。
|
||||
- **实现**：
|
||||
- 向 `planServiceImpl` 注入 `repository.UnitOfWork` 和 `plan.TaskFactory`。
|
||||
- 在 `CreatePlan` 和 `UpdatePlan` 方法中，使用 `unitOfWork.ExecuteInTransaction` 来包裹整个操作。
|
||||
- 在事务闭包内，遍历计划中的所有任务 (`models.Task`)：
|
||||
1. 调用 `taskFactory.CreateTaskFromModel(taskModel)` 创建一个临时的任务领域对象。
|
||||
2. 调用该领域对象的 `ResolveDeviceIDs()` 方法获取设备ID列表。
|
||||
3. 使用事务性的 `DeviceRepository` 查询出设备实体。
|
||||
4. 将查询到的设备实体列表填充到 `taskModel.Devices` 字段中。
|
||||
- 最后，将填充好关联数据的 `plan` 对象传递给事务性的 `PlanRepository` 进行创建或更新。
|
||||
- **优势**：
|
||||
- **职责清晰**：`PlanService` 完整地拥有了“创建/更新计划”的业务逻辑，而仓库层则回归到纯粹的数据访问职责。
|
||||
- **数据一致性**：`UnitOfWork` 确保了从准备数据（查询设备）到最终持久化（创建计划和关联）的所有数据库操作都在一个原子事务中完成。
|
||||
|
||||
### 3.4. 调整仓库层 (`PlanRepository`)
|
||||
|
||||
仓库层被简化，回归其作为数据持久化网关的纯粹角色。
|
||||
|
||||
- **职责**：负责 `Plan` 及其直接子对象（`Task`, `SubPlan`）的 CRUD 操作。
|
||||
- **实现**：
|
||||
- `CreatePlan` 和 `UpdatePlanMetadataAndStructure` 方法将被简化。它们不再需要任何特殊的关联处理逻辑（如 `Association().Replace()`）。
|
||||
- 只需接收一个由 `PlanService` 准备好的、`task.Devices` 字段已被填充的 `plan` 对象。
|
||||
- 在 `CreatePlan` 中，调用 `tx.Create(plan)` 时，GORM 会自动级联创建 `Plan`、`Task` 以及 `device_tasks` 中的关联记录。
|
||||
- 在 `UpdatePlanMetadataAndStructure` 的 `reconcileTasks` 逻辑中，对于新创建的任务，GORM 的 `tx.Create(task)` 同样会自动处理其设备关联。
|
||||
|
||||
### 3.5. 整体流程
|
||||
|
||||
以 **创建计划** 为例：
|
||||
|
||||
1. `PlanController` 调用 `PlanService.CreatePlan(plan)`。
|
||||
2. `PlanService` 调用 `unitOfWork.ExecuteInTransaction` 启动一个数据库事务。
|
||||
3. 在事务闭包内，`PlanService` 遍历 `plan` 对象中的所有 `task`。
|
||||
4. 对于每一个 `task` 模型，调用 `taskFactory.CreateTaskFromModel(task)` 创建一个临时的领域对象。
|
||||
5. 调用该领域对象的 `ResolveDeviceIDs()` 方法，获取其使用的设备 ID 列表。
|
||||
6. 如果返回了设备 ID 列表，则使用事务性的 `DeviceRepository` 查询出 `[]models.Device` 实体。
|
||||
7. 所有 `task` 的关联数据准备好后，调用事务性的 `PlanRepository.CreatePlan(plan)`。GORM 在创建 `plan` 和 `task` 的同时，会自动创建
|
||||
`device_tasks` 表中的关联记录。
|
||||
8. `UnitOfWork` 提交事务。
|
||||
|
||||
**更新计划** 的流程与创建类似，在 `UpdatePlanMetadataAndStructure` 方法中，由于会先删除旧任务再创建新任务，因此在创建新任务后执行相同的设备关联步骤。
|
||||
|
||||
**删除计划** 时，由于 `Task` 模型上配置了 `OnDelete:CASCADE`，GORM 会自动删除关联的 `Task` 记录。同时，GORM 的多对多删除逻辑会自动清理
|
||||
`device_tasks` 表中与被删除任务相关的记录。因此 `DeletePlan` 方法无需修改。
|
||||
|
||||
## 4. 实施步骤
|
||||
|
||||
1. **扩展 `TaskFactory` 接口**
|
||||
- 在 `internal/domain/plan/task.go` 文件中，为 `TaskFactory` 接口添加
|
||||
`CreateTaskFromModel(*models.Task) (TaskDeviceIDResolver, error)` 方法。
|
||||
|
||||
2. **实现 `TaskFactory` 新方法**
|
||||
- 在 `internal/domain/task/task.go` 文件中，为 `taskFactory` 结构体实现 `CreateTaskFromModel` 方法。
|
||||
|
||||
3. **修改 `PlanService`**
|
||||
- 在 `internal/domain/plan/plan_service.go` 中：
|
||||
- 修改 `planServiceImpl` 结构体，增加 `unitOfWork repository.UnitOfWork` 和 `taskFactory TaskFactory` 字段。
|
||||
- 修改 `NewPlanService` 构造函数，接收并注入这些新依赖。
|
||||
- 重构 `CreatePlan` 和 `UpdatePlan` 方法，使用 `UnitOfWork` 包裹事务，并在其中实现数据准备和关联逻辑。
|
||||
|
||||
4. **修改 `PlanRepository`**
|
||||
- 在 `internal/infra/repository/plan_repository.go` 中：
|
||||
- **简化 `CreatePlan` 和 `UpdatePlanMetadataAndStructure` 方法**。移除所有手动处理设备关联的代码（例如，如果之前有 `Association("Devices").Replace()` 等调用，则应删除）。
|
||||
- 确保这两个方法的核心逻辑就是调用 GORM 的 `Create` 或 `Updates`，信任 GORM 会根据传入模型中已填充的 `Devices` 字段来自动维护多对多关联。
|
||||
|
||||
5. **修改依赖注入**
|
||||
- 在 `internal/core/component_initializers.go` (或类似的依赖注入入口文件) 中：
|
||||
- 将 `unitOfWork` 和 `taskFactory` 实例传递给 `plan.NewPlanService` 的构造函数。
|
||||
|
||||
## 5. 结论
|
||||
|
||||
此方案通过复用现有的领域对象和工厂模式，优雅地解决了设备关联维护的问题。它保持了清晰的架构分层和模块职责，在实现功能的同时，为项目未来的扩展和维护奠定了坚实、可扩展的基础。
|
||||
@@ -0,0 +1,103 @@
|
||||
# 设备与任务多对多关联模型设计
|
||||
|
||||
## 需求背景
|
||||
|
||||
用户需要为系统中的“设备”和“任务”增加多对多关联，即一个设备可以执行多个任务，一个任务可以被多个设备执行。
|
||||
|
||||
## 现有模型分析
|
||||
|
||||
### `internal/infra/models/device.go`
|
||||
|
||||
`Device` 模型定义：
|
||||
|
||||
```go
|
||||
type Device struct {
|
||||
gorm.Model
|
||||
Name string `gorm:"not null" json:"name"`
|
||||
DeviceTemplateID uint `gorm:"not null;index" json:"device_template_id"`
|
||||
DeviceTemplate DeviceTemplate `json:"device_template"`
|
||||
AreaControllerID uint `gorm:"not null;index" json:"area_controller_id"`
|
||||
AreaController AreaController `json:"area_controller"`
|
||||
Location string `gorm:"index" json:"location"`
|
||||
Properties datatypes.JSON `json:"properties"`
|
||||
}
|
||||
```
|
||||
|
||||
### `internal/infra/models/plan.go`
|
||||
|
||||
`Task` 模型定义：
|
||||
|
||||
```go
|
||||
type Task struct {
|
||||
ID int `gorm:"primarykey"`
|
||||
CreatedAt time.Time
|
||||
UpdatedAt time.Time
|
||||
DeletedAt gorm.DeletedAt `gorm:"index"`
|
||||
|
||||
PlanID uint `gorm:"not null;index" json:"plan_id"`
|
||||
Name string `gorm:"not null" json:"name"`
|
||||
Description string `json:"description"`
|
||||
ExecutionOrder int `gorm:"not null" json:"execution_order"`
|
||||
Type TaskType `gorm:"not null" json:"type"`
|
||||
Parameters datatypes.JSON `json:"parameters"`
|
||||
}
|
||||
```
|
||||
|
||||
## 方案设计
|
||||
|
||||
为了实现设备和任务的多对多关系，我们将引入一个中间关联模型 `DeviceTask`。考虑到 `Task` 模型定义在 `plan.go` 中，为了保持相关模型的内聚性，我们将 `DeviceTask` 模型也定义在 `internal/infra/models/plan.go` 文件中。
|
||||
|
||||
### 1. 在 `internal/infra/models/plan.go` 中新增 `DeviceTask` 关联模型
|
||||
|
||||
`DeviceTask` 模型将包含 `DeviceID` 和 `TaskID` 作为外键，以及 GORM 的标准模型字段。
|
||||
|
||||
```go
|
||||
// DeviceTask 是设备和任务之间的关联模型，表示一个设备可以执行多个任务，一个任务可以被多个设备执行。
|
||||
type DeviceTask struct {
|
||||
gorm.Model
|
||||
DeviceID uint `gorm:"not null;index"` // 设备ID
|
||||
TaskID uint `gorm:"not null;index"` // 任务ID
|
||||
|
||||
// 可选：如果需要存储关联的额外信息，可以在这里添加字段，例如：
|
||||
// Configuration datatypes.JSON `json:"configuration"` // 任务在特定设备上的配置
|
||||
}
|
||||
|
||||
// TableName 自定义 GORM 使用的数据库表名
|
||||
func (DeviceTask) TableName() string {
|
||||
return "device_tasks"
|
||||
}
|
||||
```
|
||||
|
||||
### 2. 修改 `internal/infra/models/device.go`
|
||||
|
||||
在 `Device` 结构体中添加 `Tasks` 字段，通过 `gorm:"many2many:device_tasks;"` 标签声明与 `Task` 的多对多关系，并指定中间表名为 `device_tasks`。
|
||||
|
||||
```go
|
||||
// Device 代表系统中的所有普通设备
|
||||
type Device struct {
|
||||
gorm.Model
|
||||
|
||||
// ... 其他现有字段 ...
|
||||
|
||||
// Tasks 是与此设备关联的任务列表，通过 DeviceTask 关联表实现多对多关系
|
||||
Tasks []Task `gorm:"many2many:device_tasks;" json:"tasks"`
|
||||
}
|
||||
```
|
||||
|
||||
### 3. 修改 `internal/infra/models/plan.go`
|
||||
|
||||
在 `Task` 结构体中添加 `Devices` 字段，通过 `gorm:"many2many:device_tasks;"` 标签声明与 `Device` 的多对多关系，并指定中间表名为 `device_tasks`。
|
||||
|
||||
```go
|
||||
// Task 代表计划中的一个任务，具有执行顺序
|
||||
type Task struct {
|
||||
// ... 其他现有字段 ...
|
||||
|
||||
// Devices 是与此任务关联的设备列表，通过 DeviceTask 关联表实现多对多关系
|
||||
Devices []Device `gorm:"many2many:device_tasks;" json:"devices"`
|
||||
}
|
||||
```
|
||||
|
||||
## 总结
|
||||
|
||||
通过上述修改，我们将在数据库中创建一个名为 `device_tasks` 的中间表，用于存储 `Device` 和 `Task` 之间的关联关系。在 Go 代码层面，`Device` 和 `Task` 模型将能够直接通过 `Tasks` 和 `Devices` 字段进行多对多关系的查询和操作。
|
||||
@@ -0,0 +1,24 @@
|
||||
# 需求
|
||||
|
||||
删除设备/设备模板/区域主控前进行校验
|
||||
|
||||
## issue
|
||||
|
||||
http://git.huangwc.com/pig/pig-farm-controller/issues/50
|
||||
|
||||
## 需求描述
|
||||
|
||||
1. 删除设备时检测是否被任务使用
|
||||
2. 删除设备模板时检测是否被设备使用
|
||||
3. 删除区域主控时检测是否被设备使用
|
||||
|
||||
# 实现
|
||||
|
||||
1. [重构计划领域](./plan_service_refactor.md)
|
||||
2. [让任务可以提供自身使用设备](./add_get_device_id_configs_to_task.md)
|
||||
3. [现有计划管理逻辑迁移](./plan_service_refactor_to_domain.md)
|
||||
4. [增加设备任务关联表](./device_task_many_to_many_design.md)
|
||||
5. [增加任务增删改查时对设备任务关联表的维护](./device_task_association_maintenance.md)
|
||||
6. [删除设备时检查](./check_before_device_deletion.md)
|
||||
7. [删除设备模板时检查和删除区域主控时检查](./refactor_deletion_check.md)
|
||||
8. [优化设备服务方法的入参](./refactor_id_conversion.md)
|
||||
@@ -0,0 +1,83 @@
|
||||
# 计划服务重构设计方案
|
||||
|
||||
## 1. 目标
|
||||
|
||||
将 `internal/domain/scheduler` 包重构为 `internal/domain/plan`，并创建一个新的 `Service` 对象，将原 `scheduler`
|
||||
包中的核心调度逻辑集成到 `Service` 中作为一个子服务，统一由 `Service`
|
||||
对外提供服务。此重构旨在提高代码的模块化、可维护性和可测试性，并为后续的“设备删除前校验”功能奠定基础。
|
||||
|
||||
## 2. 方案详情
|
||||
|
||||
### 2.1. 包重命名
|
||||
|
||||
* 将 `internal/domain/scheduler` 目录重命名为 `internal/domain/plan`。
|
||||
* 修改 `internal/domain/plan` 目录下所有 Go 文件中的 `package scheduler` 为 `package plan`。
|
||||
* 更新 `internal/domain/plan` 目录下所有 Go 文件中所有引用
|
||||
`git.huangwc.com/pig/pig-farm-controller/internal/domain/scheduler` 的导入路径为
|
||||
`git.huangwc.com/pig/pig-farm-controller/internal/domain/plan`。
|
||||
|
||||
### 2.2. `internal/domain/plan` 包内部结构调整
|
||||
|
||||
* **`internal/domain/plan/task.go`**:
|
||||
* 保持不变。它定义了任务的接口和工厂，是领域内的核心抽象。
|
||||
|
||||
* **`internal/domain/plan/plan_execution_manager.go`**:
|
||||
* 将 `Scheduler` 结构体更名为 `ExecutionManagerImpl`。这个名称更准确地反映了它作为计划任务执行的协调者和管理者的具体实现。
|
||||
* 将 `NewScheduler` 构造函数更名为 `NewExecutionManagerImpl`。
|
||||
* 文件内部所有对 `Scheduler` 的引用都将更新为 `ExecutionManagerImpl`。
|
||||
|
||||
* **`internal/domain/plan/analysis_plan_task_manager.go`**:
|
||||
* 将 `AnalysisPlanTaskManager` 结构体更名为 `AnalysisPlanTaskManagerImpl`。
|
||||
* 将 `NewAnalysisPlanTaskManager` 构造函数更名为 `NewAnalysisPlanTaskManagerImpl`。
|
||||
* 文件内部所有对 `AnalysisPlanTaskManager` 的引用都将更新为 `AnalysisPlanTaskManagerImpl`。
|
||||
|
||||
* **定义领域层接口**:
|
||||
* 在 `internal/domain/plan` 包中定义 `ExecutionManager` 接口，包含 `ExecutionManagerImpl` 对外暴露的所有公共方法。
|
||||
* 在 `internal/domain/plan` 包中定义 `AnalysisPlanTaskManager` 接口，包含 `AnalysisPlanTaskManagerImpl` 对外暴露的所有公共方法。
|
||||
* `ExecutionManagerImpl` 和 `AnalysisPlanTaskManagerImpl` 将分别实现对应的接口。
|
||||
|
||||
### 2.3. 创建 `internal/domain/plan/plan_service.go`
|
||||
|
||||
* 创建新文件 `internal/domain/plan/plan_service.go`。
|
||||
|
||||
* **定义领域服务接口**:
|
||||
* 在 `internal/domain/plan` 包中定义 `Service` 接口，该接口将聚合 `ExecutionManager` 和 `AnalysisPlanTaskManager`
|
||||
的所有公共方法，并由 `planServiceImpl` 实现这些方法的委托。
|
||||
|
||||
* **实现领域服务**:
|
||||
* 该文件将定义 `planServiceImpl` 结构体，并包含 `ExecutionManager` 接口和 `AnalysisPlanTaskManager` 接口的实例作为其依赖。
|
||||
* 实现 `NewService` 构造函数，负责接收 `ExecutionManager` 接口和 `AnalysisPlanTaskManager` 接口的实例，并将其注入到
|
||||
`planServiceImpl` 中。
|
||||
* `planServiceImpl` 将对外提供高层次的 API，这些 API 会协调调用其依赖的接口方法。例如：
|
||||
* `Service.Start()` 方法会调用 `ExecutionManager` 接口的 `Start()` 方法。
|
||||
* `Service.Stop()` 方法会调用 `ExecutionManager` 接口的 `Stop()` 方法。
|
||||
* `Service.RefreshPlanTriggers()` 方法会调用 `AnalysisPlanTaskManager` 接口的 `Refresh()` 方法。
|
||||
* `Service.CreateOrUpdateTrigger()` 方法会调用 `AnalysisPlanTaskManager` 接口的 `CreateOrUpdateTrigger()` 方法。
|
||||
* `Service.EnsureAnalysisTaskDefinition()` 方法会调用 `AnalysisPlanTaskManager` 接口的
|
||||
`EnsureAnalysisTaskDefinition()` 方法。
|
||||
* 未来所有与计划相关的领域操作，都将通过 `Service` 接口进行。
|
||||
|
||||
### 2.4. 调整依赖注入和引用
|
||||
|
||||
* **查找并替换导入路径：** 使用 `grep` 命令查找整个项目中所有引用
|
||||
`git.huangwc.com/pig/pig-farm-controller/internal/domain/scheduler` 的地方，并将其替换为
|
||||
`git.huangwc.com/pig/pig-farm-controller/internal/domain/plan`。
|
||||
* **更新 `internal/core/component_initializers.go`**:
|
||||
* 在初始化阶段，我们将创建 `plan.ExecutionManagerImpl` 和 `plan.AnalysisPlanTaskManagerImpl` 的具体实例。
|
||||
* 然后，将这些具体实例作为 `plan.ExecutionManager` 接口和 `plan.AnalysisPlanTaskManager` 接口类型传递给
|
||||
`plan.NewService` 构造函数，创建 `planServiceImpl` 实例。
|
||||
* 最终，`plan.NewService` 返回 `plan.Service` 接口类型。
|
||||
* 应用程序的其他部分将通过 `plan.Service` 接口来访问计划相关的逻辑，而不是直接访问底层的管理器或其具体实现。
|
||||
|
||||
## 3. 优势
|
||||
|
||||
* **职责分离清晰：** `internal/domain/plan` 包专注于计划领域的核心逻辑和管理，并提供统一的 `Service` 接口作为领域服务的入口。
|
||||
* **符合领域驱动设计：** 领域层包含核心业务逻辑和管理器，应用层（如果需要）作为领域层的协调者。
|
||||
* **与现有项目风格一致：** 借鉴 `domain/pig` 包的模式，提高了项目内部的一致性。
|
||||
* **可测试性增强：** `Service` 可以更容易地进行单元测试，因为其依赖的接口可以被模拟。
|
||||
* **可维护性提高：** 当计划相关的业务逻辑发生变化时，可以更精确地定位到需要修改的组件。
|
||||
* **松耦合：** `Service` 不依赖于具体的实现，而是依赖于接口，提高了系统的灵活性和可扩展性。
|
||||
|
||||
## 4. 验证和测试
|
||||
|
||||
在完成所有修改后，需要运行项目并进行测试，确保调度器功能正常，没有引入新的错误。
|
||||
@@ -0,0 +1,179 @@
|
||||
# 重构方案：将 `app/service/plan_service.go` 的核心逻辑迁移到 `domain/plan/plan_service.go`
|
||||
|
||||
## 目标：
|
||||
|
||||
* `app/service/plan_service.go` (应用服务层): 仅负责接收 DTO、将 DTO 转换为领域实体、调用 `domain/plan/plan_service` 的领域方法，并将领域方法返回的领域实体转换为 DTO 返回。
|
||||
* `domain/plan/plan_service.go` (领域层): 封装所有与计划相关的业务逻辑、验证规则、状态管理以及对领域实体的查询操作。
|
||||
|
||||
## 详细步骤：
|
||||
|
||||
### 第一步：修改 `domain/plan/plan_service.go` (领域层)
|
||||
|
||||
1. **引入必要的依赖**:
|
||||
* `repository.PlanRepository`：用于与计划数据存储交互。
|
||||
* `repository.DeviceRepository`：如果计划逻辑中需要设备信息。
|
||||
* `models.Plan`：领域实体。
|
||||
* `errors` 和 `gorm.ErrRecordNotFound`：用于错误处理。
|
||||
* `models.PlanTypeSystem`, `models.PlanStatusEnabled`, `models.PlanContentTypeSubPlans`, `models.PlanContentTypeTasks` 等常量。
|
||||
* `git.huangwc.com/pig/pig-farm-controller/internal/infra/models`
|
||||
* `git.huangwc.com/pig/pig-farm-controller/internal/infra/repository`
|
||||
* `errors`
|
||||
* `gorm.io/gorm`
|
||||
|
||||
2. **定义领域层错误**: 将 `app/service/plan_service.go` 中定义的错误（`ErrPlanNotFound`, `ErrPlanCannotBeModified` 等）迁移到 `domain/plan/plan_service.go`，并根据领域层的语义进行调整。
|
||||
|
||||
```go
|
||||
var (
|
||||
// ErrPlanNotFound 表示未找到计划
|
||||
ErrPlanNotFound = errors.New("计划不存在")
|
||||
// ErrPlanCannotBeModified 表示计划不允许修改
|
||||
ErrPlanCannotBeModified = errors.New("系统计划不允许修改")
|
||||
// ErrPlanCannotBeDeleted 表示计划不允许删除
|
||||
ErrPlanCannotBeDeleted = errors.New("系统计划不允许删除")
|
||||
// ErrPlanCannotBeStarted 表示计划不允许手动启动
|
||||
ErrPlanCannotBeStarted = errors.New("系统计划不允许手动启动")
|
||||
// ErrPlanAlreadyEnabled 表示计划已处于启动状态
|
||||
ErrPlanAlreadyEnabled = errors.New("计划已处于启动状态，无需重复操作")
|
||||
// ErrPlanNotEnabled 表示计划未处于启动状态
|
||||
ErrPlanNotEnabled = errors.New("计划当前不是启用状态")
|
||||
// ErrPlanCannotBeStopped 表示计划不允许停止
|
||||
ErrPlanCannotBeStopped = errors.New("系统计划不允许停止")
|
||||
)
|
||||
```
|
||||
|
||||
3. **扩展 `plan.Service` 接口**:
|
||||
* 将 `app/service/plan_service.go` 中 `PlanService` 接口的所有方法（`CreatePlan`, `GetPlanByID`, `ListPlans`, `UpdatePlan`, `DeletePlan`, `StartPlan`, `StopPlan`）添加到 `domain/plan/Service` 接口中。
|
||||
* 这些方法的参数和返回值将直接使用领域实体（`*models.Plan`）或基本类型，而不是 DTO。例如：
|
||||
* `CreatePlan(plan *models.Plan) (*models.Plan, error)`
|
||||
* `GetPlanByID(id uint) (*models.Plan, error)`
|
||||
* `ListPlans(opts repository.ListPlansOptions, page, pageSize int) ([]models.Plan, int64, error)`
|
||||
* `UpdatePlan(plan *models.Plan) (*models.Plan, error)`
|
||||
* `DeletePlan(id uint) error`
|
||||
* `StartPlan(id uint) error`
|
||||
* `StopPlan(id uint) error`
|
||||
|
||||
4. **修改 `planServiceImpl` 结构体**:
|
||||
* 添加 `planRepo repository.PlanRepository` 字段。
|
||||
* 添加 `deviceRepo repository.DeviceRepository` 字段 (如果需要)。
|
||||
* `analysisPlanTaskManager plan.AnalysisPlanTaskManager` 字段保持不变。
|
||||
|
||||
```go
|
||||
type planServiceImpl struct {
|
||||
executionManager ExecutionManager
|
||||
taskManager AnalysisPlanTaskManager
|
||||
planRepo repository.PlanRepository // 新增
|
||||
// deviceRepo repository.DeviceRepository // 如果需要，新增
|
||||
logger *logs.Logger
|
||||
}
|
||||
```
|
||||
|
||||
5. **实现 `plan.Service` 接口中的新方法**:
|
||||
* 将 `app/service/plan_service.go` 中 `planService` 的所有业务逻辑方法（`CreatePlan`, `GetPlanByID`, `ListPlans`, `UpdatePlan`, `DeletePlan`, `StartPlan`, `StopPlan`）的实现，迁移到 `domain/plan/planServiceImpl` 中。
|
||||
* **关键修改点**:
|
||||
* **参数和返回值**: 确保这些方法现在接收和返回的是 `*models.Plan` 或其他领域实体，而不是 DTO。
|
||||
* **业务逻辑**: 保留所有的业务规则、验证和状态管理逻辑。
|
||||
* **依赖**: 这些方法将直接调用 `planRepo` 和 `analysisPlanTaskManager`。
|
||||
* **日志**: 日志记录保持不变，但可能需要调整日志信息以反映领域层的上下文。
|
||||
* **错误处理**: 错误处理逻辑保持不变，但现在将返回领域层定义的错误。
|
||||
* **ContentType 自动判断**: `CreatePlan` 和 `UpdatePlan` 中的 `ContentType` 自动判断逻辑应该保留在领域层。
|
||||
* **执行计数器重置**: `UpdatePlan` 和 `StartPlan` 中的执行计数器重置逻辑应该保留在领域层。
|
||||
* **系统计划限制**: 对系统计划的修改、删除、启动、停止限制逻辑应该保留在领域层。
|
||||
* **验证和重排顺序**: `models.Plan` 的 `ValidateExecutionOrder()` 和 `ReorderSteps()` 方法的调用应该在 `CreatePlan` 和 `UpdatePlan` 方法的领域层实现中进行，而不是在 DTO 转换函数中。
|
||||
|
||||
6. **修改 `NewPlanService` 函数**: 接收 `repository.PlanRepository` 和 `repository.DeviceRepository` (如果需要) 作为参数，并注入到 `planServiceImpl` 中。
|
||||
|
||||
```go
|
||||
func NewPlanService(
|
||||
executionManager ExecutionManager,
|
||||
taskManager AnalysisPlanTaskManager,
|
||||
planRepo repository.PlanRepository, // 新增
|
||||
// deviceRepo repository.DeviceRepository, // 如果需要，新增
|
||||
logger *logs.Logger,
|
||||
) Service {
|
||||
return &planServiceImpl{
|
||||
executionManager: executionManager,
|
||||
taskManager: taskManager,
|
||||
planRepo: planRepo, // 注入
|
||||
// deviceRepo: deviceRepo, // 注入
|
||||
logger: logger,
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 第二步：修改 `app/service/plan_service.go` (应用服务层)
|
||||
|
||||
1. **修改 `planService` 结构体**:
|
||||
* 移除 `planRepo repository.PlanRepository` 字段。
|
||||
* 将 `analysisPlanTaskManager plan.AnalysisPlanTaskManager` 字段替换为 `domainPlanService plan.Service`。
|
||||
|
||||
```go
|
||||
type planService struct {
|
||||
logger *logs.Logger
|
||||
// planRepo repository.PlanRepository // 移除
|
||||
domainPlanService plan.Service // 替换为领域层的服务接口
|
||||
// analysisPlanTaskManager plan.AnalysisPlanTaskManager // 移除，由 domainPlanService 内部持有
|
||||
}
|
||||
```
|
||||
|
||||
2. **修改 `NewPlanService` 函数**:
|
||||
* 接收 `domainPlanService plan.Service` 作为参数。
|
||||
* 将 `planRepo` 和 `analysisPlanTaskManager` 的注入替换为 `domainPlanService`。
|
||||
|
||||
```go
|
||||
func NewPlanService(
|
||||
logger *logs.Logger,
|
||||
// planRepo repository.PlanRepository, // 移除
|
||||
domainPlanService plan.Service, // 接收领域层服务
|
||||
// analysisPlanTaskManager plan.AnalysisPlanTaskManager, // 移除
|
||||
) PlanService {
|
||||
return &planService{
|
||||
logger: logger,
|
||||
domainPlanService: domainPlanService, // 注入领域层服务
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
3. **修改 `PlanService` 接口**:
|
||||
* 接口定义保持不变，仍然接收和返回 DTO。
|
||||
|
||||
4. **修改 `planService` 接口实现**:
|
||||
* **`CreatePlan`**:
|
||||
* 接收 `dto.CreatePlanRequest`。
|
||||
* 使用 `dto.NewPlanFromCreateRequest` 将 DTO 转换为 `*models.Plan`。**注意：此时 `NewPlanFromCreateRequest` 不再包含 `ValidateExecutionOrder()` 和 `ReorderSteps()` 的调用。**
|
||||
* 调用 `s.domainPlanService.CreatePlan(*models.Plan)`。
|
||||
* 将返回的 `*models.Plan` 转换为 `dto.PlanResponse`。
|
||||
* **`GetPlanByID`**:
|
||||
* 调用 `s.domainPlanService.GetPlanByID(id)`。
|
||||
* 将返回的 `*models.Plan` 转换为 `dto.PlanResponse`。
|
||||
* **`ListPlans`**:
|
||||
* 将 `dto.ListPlansQuery` 转换为 `repository.ListPlansOptions`。
|
||||
* 调用 `s.domainPlanService.ListPlans(...)`。
|
||||
* 将返回的 `[]models.Plan` 转换为 `[]dto.PlanResponse`。
|
||||
* **`UpdatePlan`**:
|
||||
* 使用 `dto.NewPlanFromUpdateRequest` 将 `dto.UpdatePlanRequest` 转换为 `*models.Plan`。**注意：此时 `NewPlanFromUpdateRequest` 不再包含 `ValidateExecutionOrder()` 和 `ReorderSteps()` 的调用。**
|
||||
* 设置 `plan.ID = id`。
|
||||
* 调用 `s.domainPlanService.UpdatePlan(*models.Plan)`。
|
||||
* 将返回的 `*models.Plan` 转换为 `dto.PlanResponse`。
|
||||
* **`DeletePlan`**:
|
||||
* 调用 `s.domainPlanService.DeletePlan(id)`。
|
||||
* **`StartPlan`**:
|
||||
* 调用 `s.domainPlanService.StartPlan(id)`。
|
||||
* **`StopPlan`**:
|
||||
* 调用 `s.domainPlanService.StopPlan(id)`。
|
||||
* **错误处理**: 应用服务层将捕获领域层返回的错误，并可能将其转换为更适合应用服务层或表示层的错误信息（例如，将领域层的 `ErrPlanNotFound` 转换为 `app/service` 层定义的 `ErrPlanNotFound`）。
|
||||
|
||||
### 第三步：修改 `internal/app/dto/plan_converter.go`
|
||||
|
||||
1. **移除 `NewPlanFromCreateRequest` 和 `NewPlanFromUpdateRequest` 中的领域逻辑**:
|
||||
* 从 `NewPlanFromCreateRequest` 和 `NewPlanFromUpdateRequest` 函数中移除 `plan.ValidateExecutionOrder()` 和 `plan.ReorderSteps()` 的调用。这些逻辑应该由领域服务来处理。
|
||||
|
||||
### 第四步：更新 `main.go` 或其他依赖注入点
|
||||
|
||||
* 调整 `NewPlanService` 的调用，确保正确注入 `domain/plan/Service` 的实现。
|
||||
|
||||
## 风险与注意事项：
|
||||
|
||||
* **事务管理**: 如果领域层的方法需要事务，确保事务在领域层内部或由应用服务层协调。
|
||||
* **错误映射**: 仔细处理领域层错误到应用服务层错误的映射，确保对外暴露的错误信息是恰当的。
|
||||
* **循环依赖**: 确保 `domain` 层不依赖 `app` 层，`app` 层可以依赖 `domain` 层。
|
||||
* **测试**: 重构后需要对所有相关功能进行全面的单元测试和集成测试。
|
||||
@@ -0,0 +1,196 @@
|
||||
# 重构方案：将删除前关联检查逻辑迁移至 Service 层
|
||||
|
||||
## 1. 目标
|
||||
|
||||
将删除**区域主控 (AreaController)** 和**设备模板 (DeviceTemplate)** 时的关联设备检查逻辑，从 Repository（数据访问）层重构至 Service（业务逻辑）层。
|
||||
|
||||
## 2. 动机
|
||||
|
||||
当前实现中，关联检查逻辑位于 Repository 层的 `Delete` 方法内。这违反了分层架构的最佳实践。Repository 层应仅负责单纯的数据持久化操作（增删改查），而不应包含业务规则。
|
||||
|
||||
通过本次重构，我们将实现：
|
||||
- **职责分离**: Service 层负责编排业务逻辑（如“删除前必须检查关联”），Repository 层回归其数据访问的单一职责。
|
||||
- **代码清晰**: 业务流程在 Service 层一目了然，便于理解和维护。
|
||||
- **可测试性增强**: 可以独立测试 Service 层的业务规则，而无需依赖数据库的事务或约束。
|
||||
|
||||
## 3. 详细实施步骤
|
||||
|
||||
### 第 1 步：在 Service 层定义业务错误
|
||||
|
||||
在 `internal/app/service/device_service.go` 文件中，导出两个新的错误变量，用于清晰地表达业务约束。
|
||||
|
||||
```go
|
||||
// ErrAreaControllerInUse 表示区域主控正在被设备使用，无法删除
|
||||
var ErrAreaControllerInUse = errors.New("区域主控正在被一个或多个设备使用，无法删除")
|
||||
|
||||
// ErrDeviceTemplateInUse 表示设备模板正在被设备使用，无法删除
|
||||
var ErrDeviceTemplateInUse = errors.New("设备模板正在被一个或多个设备使用，无法删除")
|
||||
```
|
||||
|
||||
### 第 2 步：调整 Repository 接口与实现
|
||||
|
||||
#### 2.1 `device_repository.go`
|
||||
在 `DeviceRepository` 接口中增加一个方法，用于检查区域主控是否被使用，并在 `gormDeviceRepository` 中实现它。
|
||||
|
||||
```go
|
||||
// internal/infra/repository/device_repository.go
|
||||
|
||||
type DeviceRepository interface {
|
||||
// ... 其他方法
|
||||
IsAreaControllerInUse(areaControllerID uint) (bool, error)
|
||||
}
|
||||
|
||||
func (r *gormDeviceRepository) IsAreaControllerInUse(areaControllerID uint) (bool, error) {
|
||||
var count int64
|
||||
if err := r.db.Model(&models.Device{}).Where("area_controller_id = ?", areaControllerID).Count(&count).Error; err != nil {
|
||||
return false, fmt.Errorf("检查区域主控使用情况失败: %w", err)
|
||||
}
|
||||
return count > 0, nil
|
||||
}
|
||||
```
|
||||
|
||||
#### 2.2 `area_controller_repository.go`
|
||||
简化 `Delete` 方法，移除所有业务逻辑，使其成为一个纯粹的数据库删除操作。
|
||||
|
||||
```go
|
||||
// internal/infra/repository/area_controller_repository.go
|
||||
|
||||
func (r *gormAreaControllerRepository) Delete(id uint) error {
|
||||
// 移除原有的事务和关联检查
|
||||
if err := r.db.Delete(&models.AreaController{}, id).Error; err != nil {
|
||||
return fmt.Errorf("删除区域主控失败: %w", err)
|
||||
}
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
#### 2.3 `device_template_repository.go`
|
||||
同样，简化 `Delete` 方法。`IsInUse` 方法保持不变，因为它仍然是一个有用的查询。
|
||||
|
||||
```go
|
||||
// internal/infra/repository/device_template_repository.go
|
||||
|
||||
func (r *gormDeviceTemplateRepository) Delete(id uint) error {
|
||||
// 移除原有的关联检查逻辑
|
||||
if err := r.db.Delete(&models.DeviceTemplate{}, id).Error; err != nil {
|
||||
return fmt.Errorf("删除设备模板失败: %w", err)
|
||||
}
|
||||
return nil
|
||||
}
|
||||
```
|
||||
|
||||
### 第 3 步：在 Service 层实现业务逻辑
|
||||
|
||||
#### 3.1 `device_service.go` - 删除区域主控
|
||||
修改 `DeleteAreaController` 方法，加入关联检查的业务逻辑。
|
||||
|
||||
```go
|
||||
// internal/app/service/device_service.go
|
||||
|
||||
func (s *deviceService) DeleteAreaController(id string) error {
|
||||
idUint, err := strconv.ParseUint(id, 10, 64)
|
||||
if err != nil {
|
||||
return fmt.Errorf("无效的ID格式: %w", err)
|
||||
}
|
||||
acID := uint(idUint)
|
||||
|
||||
// 1. 检查是否存在
|
||||
_, err = s.areaControllerRepo.FindByID(acID)
|
||||
if err != nil {
|
||||
return err // 如果未找到，gorm会返回 ErrRecordNotFound
|
||||
}
|
||||
|
||||
// 2. 检查是否被使用（业务逻辑）
|
||||
inUse, err := s.deviceRepo.IsAreaControllerInUse(acID)
|
||||
if err != nil {
|
||||
return err // 返回数据库检查错误
|
||||
}
|
||||
if inUse {
|
||||
return ErrAreaControllerInUse // 返回业务错误
|
||||
}
|
||||
|
||||
// 3. 执行删除
|
||||
return s.areaControllerRepo.Delete(acID)
|
||||
}
|
||||
```
|
||||
|
||||
#### 3.2 `device_service.go` - 删除设备模板
|
||||
修改 `DeleteDeviceTemplate` 方法，加入关联检查的业务逻辑。
|
||||
|
||||
```go
|
||||
// internal/app/service/device_service.go
|
||||
|
||||
func (s *deviceService) DeleteDeviceTemplate(id string) error {
|
||||
idUint, err := strconv.ParseUint(id, 10, 64)
|
||||
if err != nil {
|
||||
return fmt.Errorf("无效的ID格式: %w", err)
|
||||
}
|
||||
dtID := uint(idUint)
|
||||
|
||||
// 1. 检查是否存在
|
||||
_, err = s.deviceTemplateRepo.FindByID(dtID)
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
|
||||
// 2. 检查是否被使用（业务逻辑）
|
||||
inUse, err := s.deviceTemplateRepo.IsInUse(dtID)
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
if inUse {
|
||||
return ErrDeviceTemplateInUse // 返回业务错误
|
||||
}
|
||||
|
||||
// 3. 执行删除
|
||||
return s.deviceTemplateRepo.Delete(dtID)
|
||||
}
|
||||
```
|
||||
|
||||
### 第 4 步：在 Controller 层处理新的业务错误
|
||||
|
||||
#### 4.1 `device_controller.go` - 删除区域主控
|
||||
在 `DeleteAreaController` 的错误处理中，增加对 `ErrAreaControllerInUse` 的捕获，并返回 `409 Conflict` 状态码。
|
||||
|
||||
```go
|
||||
// internal/app/controller/device/device_controller.go
|
||||
|
||||
func (c *Controller) DeleteAreaController(ctx echo.Context) error {
|
||||
// ...
|
||||
if err := c.deviceService.DeleteAreaController(acID); err != nil {
|
||||
switch {
|
||||
case errors.Is(err, gorm.ErrRecordNotFound):
|
||||
// ...
|
||||
case errors.Is(err, service.ErrAreaControllerInUse): // 新增
|
||||
c.logger.Warnf("%s: 尝试删除正在被使用的主控, ID: %s", actionType, acID)
|
||||
return controller.SendErrorWithAudit(ctx, controller.CodeConflict, err.Error(), actionType, "主控正在被使用", acID)
|
||||
default:
|
||||
// ...
|
||||
}
|
||||
}
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
#### 4.2 `device_controller.go` - 删除设备模板
|
||||
在 `DeleteDeviceTemplate` 的错误处理中，增加对 `ErrDeviceTemplateInUse` 的捕获，并返回 `409 Conflict` 状态码。
|
||||
|
||||
```go
|
||||
// internal/app/controller/device/device_controller.go
|
||||
|
||||
func (c *Controller) DeleteDeviceTemplate(ctx echo.Context) error {
|
||||
// ...
|
||||
if err := c.deviceService.DeleteDeviceTemplate(dtID); err != nil {
|
||||
switch {
|
||||
case errors.Is(err, gorm.ErrRecordNotFound):
|
||||
// ...
|
||||
case errors.Is(err, service.ErrDeviceTemplateInUse): // 新增
|
||||
c.logger.Warnf("%s: 尝试删除正在被使用的模板, ID: %s", actionType, dtID)
|
||||
return controller.SendErrorWithAudit(ctx, controller.CodeConflict, err.Error(), actionType, "模板正在被使用", dtID)
|
||||
default:
|
||||
// ...
|
||||
}
|
||||
}
|
||||
// ...
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,106 @@
|
||||
# 重构方案：将 ID 类型转换逻辑迁移至 Controller 层
|
||||
|
||||
## 1. 目标
|
||||
|
||||
将所有通过 URL 路径传入的 `id`（`string` 类型），其到 `uint` 类型的转换和验证逻辑，从 Service（业务逻辑）层统一迁移至 Controller（控制器）层。
|
||||
|
||||
## 2. 动机
|
||||
|
||||
当前实现中，Controller 将从 URL 获取的 `string` 类型的 ID 直接传递给 Service 层，由 Service 层负责使用 `strconv.ParseUint` 进行类型转换。
|
||||
|
||||
这种模式存在以下问题：
|
||||
- **职责不清**：Service 层被迫处理了本应属于输入验证和转换的逻辑，而这部分工作更贴近 Controller 的职责。
|
||||
- **Service 不纯粹**：业务核心逻辑与原始输入（字符串）耦合，降低了 Service 的可复用性。理想情况下，Service 的接口应该只处理内部定义的、类型安全的数据。
|
||||
- **延迟的错误处理**：对于一个无效的 ID（如 "abc"），请求会穿透到 Service 层才会失败，而这种格式错误在 Controller 层就应该被拦截。
|
||||
|
||||
通过本次重构，我们将实现：
|
||||
- **职责分离**：Controller 负责处理 HTTP 请求的原始数据（验证、转换），Service 负责处理核心业务。
|
||||
- **接口清晰**：Service 层的所有方法将只接受类型安全的 `uint` 作为 ID，使其意图更加明确。
|
||||
- **快速失败**：无效的 ID 将在 Controller 层被立即拒绝，并返回 `400 Bad Request`，提高了系统的健壮性。
|
||||
|
||||
## 3. 详细实施步骤
|
||||
|
||||
### 第 1 步：修改 `device_service.go`
|
||||
|
||||
#### 3.1 修改 `DeviceService` 接口
|
||||
所有接收 `id string` 参数的方法签名，全部修改为接收 `id uint`。
|
||||
|
||||
**受影响的方法列表：**
|
||||
- `GetDevice(id string)` -> `GetDevice(id uint)`
|
||||
- `UpdateDevice(id string, ...)` -> `UpdateDevice(id uint, ...)`
|
||||
- `DeleteDevice(id string)` -> `DeleteDevice(id uint)`
|
||||
- `ManualControl(id string, ...)` -> `ManualControl(id uint, ...)`
|
||||
- `GetAreaController(id string)` -> `GetAreaController(id uint)`
|
||||
- `UpdateAreaController(id string, ...)` -> `UpdateAreaController(id uint, ...)`
|
||||
- `DeleteAreaController(id string)` -> `DeleteAreaController(id uint)`
|
||||
- `GetDeviceTemplate(id string)` -> `GetDeviceTemplate(id uint)`
|
||||
- `UpdateDeviceTemplate(id string, ...)` -> `UpdateDeviceTemplate(id uint, ...)`
|
||||
- `DeleteDeviceTemplate(id string)` -> `DeleteDeviceTemplate(id uint)`
|
||||
|
||||
#### 3.2 修改 `deviceService` 实现
|
||||
在 `deviceService` 的方法实现中，移除所有 `strconv.ParseUint` 的调用，直接使用传入的 `uint` 类型的 ID。
|
||||
|
||||
**示例 (`DeleteDeviceTemplate`):**
|
||||
|
||||
**修改前:**
|
||||
```go
|
||||
func (s *deviceService) DeleteDeviceTemplate(id string) error {
|
||||
idUint, err := strconv.ParseUint(id, 10, 64)
|
||||
if err != nil {
|
||||
return fmt.Errorf("无效的ID格式: %w", err)
|
||||
}
|
||||
dtID := uint(idUint)
|
||||
// ... 业务逻辑
|
||||
}
|
||||
```
|
||||
|
||||
**修改后:**
|
||||
```go
|
||||
func (s *deviceService) DeleteDeviceTemplate(id uint) error {
|
||||
// 直接使用 id
|
||||
// ... 业务逻辑
|
||||
}
|
||||
```
|
||||
|
||||
### 第 2 步：修改 `device_controller.go`
|
||||
|
||||
在所有调用受影响 Service 方法的 Controller 方法中，增加 ID 的转换和错误处理逻辑。
|
||||
|
||||
**示例 (`DeleteDeviceTemplate`):**
|
||||
|
||||
**修改前:**
|
||||
```go
|
||||
func (c *Controller) DeleteDeviceTemplate(ctx echo.Context) error {
|
||||
const actionType = "删除设备模板"
|
||||
dtID := ctx.Param("id") // dtID is a string
|
||||
|
||||
if err := c.deviceService.DeleteDeviceTemplate(dtID); err != nil {
|
||||
// ... 错误处理
|
||||
}
|
||||
// ... 成功处理
|
||||
}
|
||||
```
|
||||
|
||||
**修改后:**
|
||||
```go
|
||||
func (c *Controller) DeleteDeviceTemplate(ctx echo.Context) error {
|
||||
const actionType = "删除设备模板"
|
||||
idStr := ctx.Param("id")
|
||||
|
||||
// 在 Controller 层进行转换和验证
|
||||
idUint, err := strconv.ParseUint(idStr, 10, 64)
|
||||
if err != nil {
|
||||
c.logger.Warnf("%s: 无效的ID格式: %s", actionType, idStr)
|
||||
return controller.SendErrorWithAudit(ctx, controller.CodeBadRequest, "无效的ID格式", actionType, "ID格式错误", idStr)
|
||||
}
|
||||
dtID := uint(idUint)
|
||||
|
||||
// 调用 Service，传入 uint 类型的 ID
|
||||
if err := c.deviceService.DeleteDeviceTemplate(dtID); err != nil {
|
||||
// ... 错误处理 (保持不变)
|
||||
}
|
||||
|
||||
// ... 成功处理
|
||||
}
|
||||
```
|
||||
此模式将应用于所有受影响的 Controller 方法。
|
||||
Reference in New Issue
Block a user