时间戳

首页 > 解决方案 > Repository->Service->Controller的正确设计？

.net - Repository->Service->Controller的正确设计？

问题描述

我想知道我是否在我的应用程序中使用了正确的架构。

在我的 API 中调用端点后，我目前正在经历以下流程： Api.EmployeeController.Update(Api.EmployeeUpdateDto)=> Services.EmployeeService.Update(Service.EmployeeUpdateDto)=> Data.EmployeeRepository.Update(Entities.Employee)=>Data.EfDbContext.Employees.Update(Entities.Employee)

为了解释更多，我的 API 端点采取Api.EmployeeUpdateDto，在控制器中它被映射Services.EmployeeUpdateDto并传递给Services.EmployeeService.Update(). 在Services.EmployeeService.Update()其中通过 Id 检索实际的 db 实体并更新它的值，然后将其传递给EmployeeRepository.Update()后者，然后调用底层 EF db 上下文。

出于某种原因，我的直觉告诉我它的层次太多了，我错过了什么吗？

标签： .netarchitecturedomain-driven-designrepository-pattern

解决方案

好的。这些步骤：

  1. Api.EmployeeController.Update(Api.EmployeeUpdateDto)
  2. Services.EmployeeService.Update(Service.EmployeeUpdateDto)
  3. Data.EmployeeRepository.Update(Entities.Employee)
  4. Data.EfDbContext.Employees.Update(Entities.Employee)

首先。很高兴您拥有一个，EmployeeUpdateDto因为您通常不会更新与创建新实体时完全相同的字段。但是，我通常会做更多基于任务的方法LockUserDTO，例如RenameUserDTO等，

DDD 中有两种类型的服务。应用服务和领域服务。应用程序服务充当保护您的域的门面，而域服务用于协调多个实体之间的工作。

Service.EmployeeUpdateDto并没有真正增加任何价值。如果 API dto 发生变化，或者实体发生变化，它仍然需要更新。所以它没有提供任何进一步的抽象，只是拥有 API dto。因此我会删除它并让应用程序服务直接使用 API dto。

  1. Api.EmployeeController.Update(Api.EmployeeUpdateDto)
  2. Services.EmployeeService.Update(Api.EmployeeUpdateDto)
  3. Data.EmployeeRepository.Update(Entities.Employee)
  4. Data.EfDbContext.Employees.Update(Entities.Employee)

我通常避免将域实体用作数据库实体，因为它通常需要在设计中做出妥协，以便 ORM 可以正确地保留它。请记住，领域实体是您最宝贵的财富。唯一应该推动他们设计的是领域。

推荐阅读