我可以从 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，我通常在公共库中定义它。 here (pdf) 的详细记录。数据访问、业务逻辑和 UI 都将其作为一个通用词汇表共享。

这使得它们在您使用依赖注入抽象出您的数据访问时非常有用 - 您定义的接口也必须在其签名中使用 DTO。

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

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

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