多关联实体场景下控制器依赖注入与服务层的合理组织问询

当前实现背景 #

数据库中有Request模型，与分类、备注等多个表存在关联关系。针对每个实体都创建了CRUD服务接口，比如IRequestService、IRequestNoteService、IRequestKPIService等。

现存问题 #

当前的RequestController需要获取Request及其关联实体的数据，导致构造函数注入了大量接口：

public RequestController(
    IMapper mapper,
    IRequestService requestService,
    IRequestorService requestorService,
    UserManager<ApplicationUser> userManager,
    IWebHostEnvironment environment,
    IRequestCategoryService requestCategoryService,
    IRequestNoteService requestNoteService,
    ICommitteeNoteService committeeNoteService)
{
    _mapper = mapper;
    _requestService = requestService;
    _userManager = userManager;
    _requestorService = requestorService;
    _environment = environment;
    _requestCategoryService = requestCategoryService;
    _requestNoteService = requestNoteService;
    _committeeNoteService = committeeNoteService;
    //etc.
}

该控制器包含以下方法：

public async Task<ActionResult> GetRequestKPIs() { }
public async Task<JsonResult> GetRequests() { }
public async Task<JsonResult> GetNotesForRequest(int RequestIdForNote) { }
public async Task<JsonResult> UpdateNoteForRequest() { }
public async Task<JsonResult> DeleteATGRequest(int Id) { }

核心疑问 #

注入的CRUD接口仅在该控制器中使用了GET相关方法，目前纠结两种优化方向：

• 是否应该拆分出RequestNoteController、RequestorController等独立控制器来处理关联数据（比如把UpdateRequestNote()这类方法移过去）？
• 还是需要创建仅实现控制器所需接口方法的特定类？

希望了解在模型存在大量关联实体的场景下，控制器与服务层的组织规范及相关最佳实践。

解答 #

1. 控制器拆分的判断逻辑

• 按资源边界拆分：如果关联实体（如Note、Requestor）本身是独立业务资源，能被其他业务场景复用，就应该拆分独立控制器。比如RequestNote如果除了和Request关联，还可能被其他模块调用，单独做RequestNotesController更合理，符合RESTful设计中“每个资源对应一个控制器”的原则。
• 按聚合根划分：如果关联实体是Request聚合的一部分（比如RequestNote只能依附于Request存在，没有独立业务意义），可以保留在RequestController里，但要通过应用层服务来简化依赖注入。

2. 服务层优化方案

• 引入应用层服务：创建RequestAppService这类应用服务，把多个底层CRUD服务的依赖封装进去，控制器只注入这个应用服务。比如在RequestAppService里封装GetRequestWithNotes()、UpdateRequestNote()等方法，控制器只需调用应用服务，无需直接依赖多个CRUD接口，大幅减少注入数量。
• 避免裁剪接口：不要为了控制器需求特意创建仅包含部分方法的接口，这会导致接口爆炸，违反接口隔离原则的初衷。如果某个CRUD接口大部分方法用不上，说明要么该接口设计冗余，要么控制器职责越界了。

3. 最佳实践总结

• 控制器遵循单一职责：每个控制器只处理一类核心资源的请求，避免成为“万能控制器”。
• 应用层服务做业务编排：把跨多个领域服务的逻辑封装在应用服务里，控制器只负责接收请求、参数校验、返回响应，不处理业务逻辑。
• 聚合根优先：如果关联实体属于Request聚合，就围绕Request聚合设计接口和服务，避免过度拆分导致业务逻辑分散。

内容的提问来源于stack exchange，提问作者Selthien