我可以从 DAL 返回 DTO吗

Question

我开始使用洋葱架构，因为我对以前的项目结构不满意。我的主要问题是，我可以从数据访问层返回 DTO 吗？

这是我当前的结构：

/Core
 - Application
 - Domain
/Infrastructure
 - Persistence
 - Identity
/WebApi
 - WebApi

快速解释：

• 应用程序层是我所有业务逻辑的地方
• 领域层是定义所有实体/模型的地方
• 持久层是我查询数据库的地方
• 身份层用于用户管理
• WebApi 层是我拥有控制器的地方

数据流程如下：

Client <- WebApi Layer <- (DTO) Application Layer <- (Entity) Persistence Layer

截至目前，持久层返回在域层中定义的实际数据库实体，应用程序层将其转换为 DTO。

我的问题是，持久层实际上经常需要执行不同的查询，这将使类型与实体类型不同。例如，我可以连接不同的表、应用分组等。因此，我无法返回实体类型。

我是否可以从持久层（数据访问层）返回 DTO？如果是，我在哪里定义这些 DTO？将它们与应用程序层中的其他 DTO 一起定义并在持久层中使用这些 DTO 会使其依赖于应用程序层（我认为这不是很好，因为我们希望最大限度地减少耦合）。另一种选择是在域层中与实体一起创建它们（可能是更好的方法）？为了保持一致性，我应该只从应用程序层返回 DTO，还是可以同时返回实体类型和 DTO？

很多问题我都找不到。只是想成为一名更好的程序员:)

Answer 1

我的主要问题是，我可以从数据访问层返回 DTO 吗？

是的。注意到：

1. 是的，因为谁会阻止你？
2. 是的，因为这是一种足够常见的公认模式，一般来说，如果采取这种方法，没有小猫会死亡。

我是否可以从持久层（数据访问层）返回 DTO？如果是，我在哪里定义这些 DTO？

我对分层应用程序的默认“在没有理由不这样做的情况下”架构是使用 DTO，我通常在公共库中定义它。详细的文章在这里（pdf）。数据访问、业务逻辑和 UI 都将此作为通用词汇表。

这使得它们对于使用依赖注入来抽象数据访问的地方非常有用 - 您定义的接口还必须在其签名中使用 DTO。

如果您愿意，您可以定义只有数据访问层和消费者知道的 DTO - 问题是您为什么要这样做？并不是说你不能——只是说，只有当你经过深思熟虑并且有一个有意义的理由时才应该这样做。

我的问题是，持久层实际上经常需要执行不同的查询，这将使类型与实体类型不同。例如，我可以连接不同的表、应用分组等。因此，我无法返回实体类型。

有时，您会遇到这样的情况：您创建的 DTO 非常特定于场景（不会被重用）。只有你才能说这是否可以接受。这是您想要维护的代码量与 DTO 的适用性之间的权衡。我认为拥有场景特定的 DTO 本身并不坏，如果这意味着架构保持干净并且实现场景的方式是明智的。