EF Core、服务和存储库模式

Question

为了了解模式，我正在使用以下项目创建 Web API：实体、存储库、服务和 API 应用程序。

API 中的每个控制器都对其相应的服务使用依赖注入；每个服务使用 DI 到多个存储库；存储库用于从 DbContext 获取数据，实体包含 DbContext 和 DbSet。

例如，当我调用 /teams/1 端点时：

• GetTeam(id)控制器调用中的函数_teamService.GetTeam(id);
• 服务电话_teamRepository.GetTeam(id);
• 存储库执行 LINQ 调用，将Context.Team.First(...)团队实体模型返回给服务；
• 服务获取模型并将其映射到返回控制器的 DTO；
• 控制器以 JSON 格式将其提供给应用程序。

这是管理流量的正确方法吗？

此外，想象一下控制器必须检索团队及其所有比赛：注入CompetitionRepository 并从TeamService 使用它是否正确？就像是：

TeamService.cs

return new DTOObject {
    team = _teamRepo.GetTeam(id),
    competitions = _compRepo.GetCompsByTeam(id) <-- is a list
}

Answer 1

我更喜欢从我的服务返回实体而不是 DTO。原因是有时服务调用的结果用于创建 ASP.NET MVC 视图模型，有时用于创建 DTO 以作为 JSON 返回。有时这些DTO的要求是不同的，服务器端ViewModel可以看到不应该暴露给客户端的东西。您可以在服务层中创建 DTO，但在大多数情况下，它只是您必须处理的另一个映射，没有多大价值。这就是我直接从控制器中的实体创建 DTO 或 ViewModel 的原因。

此外，存储库模式大多无用。如果您更改数据存储，这可能会很有用，但实际上，此类更改会伴随着对业务逻辑的许多其他更改，因此您的大部分服务层无论如何都会被重写，因此价值会丢失。