存储库层是否应该返回数据传输对象 (DTO)？答案

【问题标题】：Should the repository layer return data-transfer-objects (DTO)?存储库层是否应该返回数据传输对象 (DTO)？
【发布时间】：2011-07-01 10:30:26
【问题描述】：

我有一个负责我的数据访问的存储库层，它由服务层调用。服务层返回被序列化并通过线路发送的 DTO。通常，服务只是访问存储库并返回存储库返回的任何内容。

但要使其正常工作，存储库必须返回该 DTO 的实例。否则，您首先必须将存储库返回的数据层对象映射到服务层中的 DTO 并返回。这似乎很浪费。

最重要的是，如果 DTO 的创建发生在服务层中，以前可能在一个存储库调用和一个数据库查询中完成的操作，现在必须在服务层中的多个存储库调用中发生撰写'最终的 DTO。当然，除非我在数据和服务层之间创建一个可以包含这样一个组合对象的传输对象。 then 必须映射到 DTO。为了纯洁，这似乎是浪费。但是让存储库层返回刚刚存在的对象以通过网络发送也感觉不对。

【问题讨论】：

标签： c# data-access-layer n-tier-architecture dto service-layer

【解决方案1】：

简短回答：不。

长答案：存储库负责将持久化数据转回实体（模型），反之亦然。

Model 是代表业务实体的业务模型。另一方面，DTO - 虽然看起来像模型 - 关注对象在各种环境之间的转移，本质上是一个瞬态对象。通常 mappers 负责将模型转换为 DTO。

【讨论】：

好的，所以如果我想要纯粹，我会让我的存储库返回一个实体（数据模型），然后服务层将其映射到 DTO 并通过网络发送它？用于更复杂查询的服务和数据层之间的专用传输对象如何避免必须执行多个查询？
如果您的持久层从 DB 变为 Web 服务会怎样？因此，在这种情况下，您将不再需要 EF 创建的数据实体（模型）。现在要持久化数据，您需要填充一个 WebService 请求对象并将其传递给服务。我认为 EF 实体和 WebServiceRequest/Response 对象应该只包含在 Repos 中。话虽如此，可以从存储库中传回 DTO（或应用程序对象）。只有持久层需要 EF 实体或 Request/Resonse 对象。
@caa 有人说 repo 正在返回 EF 实体吗？
所以您的存储库需要为整个实体补充水分，即使它没有被使用？这似乎效率很低。

【解决方案2】：

所以即使没有使用，您的存储库也需要为整个实体补充水分？这似乎非常低效。 – ajbeaven 2018 年 10 月 29 日 23:25

您不能为不需要对整个实体进行水合的调用添加方法到存储库接口吗？我想这可能会导致接口臃肿，我认为这是反对的主要论据之一。

为了回答这个问题，我同意“否”的公认答案。存储库实现在持久层中。领域层可能需要从持久层检索深层或浅层对象，除了它必须实现的接口之外，它什么都不知道。如果域在只需要黄油时不断地要求一个完整的冰箱，那么接口（或者可能是数据模型）可能需要一些工作。

【讨论】：