数据传输对象DTO在何处构建

Question

尝试重构一些代码。我看到一些创建DTO对象的类正在服务层中传递，后来由@RestController返回。据我所知，最好只在控制器中构建数据传输对象并将它们传递给视图，尤其是当我们使用带有get和set值的WrapperDTO<T>之类的东西时。当我们使用复杂对象或简单数据类型构建WrapperDTO时，可能存在差异。所有的oppinions将非常感激。

Answer 1

DTO可用于在应用程序的不同层之间传输数据：DAO，服务，外观，控制器。根据我的经验，DTO是一个自以为是的主题。

在我看来，转换越晚越好，如果不需要转换则更好。通常，后者位于应用程序边界。 DTO不是免费的，它涉及映射及其支持。因此，当存在域模型不匹配或模型技术不匹配时，DTO将是有意义的。有关详细信息，请查看LocalDTO article and the associated link。

如果我专注于服务 - ＆gt; facade - ＆gt; controller 图层：

• 服务：他们正在做服务，他们可能会互相打电话进行处理。如果您的域模型在服务边界service => facade内保持一致，那么将结果转换为DTO为时尚早。

• Facades：他们可能会协调服务并转换输入/输出。在我看来，它将是转换到DTO或从DTO转换的正确位置。但只有在需要时才是这样。因为您的域模型必须在此边界内进行转换（过滤字段，聚合......）

• 网关/控制器：它们位于应用程序边界。他们的逻辑很简单，简化为边界逻辑。外观和控制器之间的关系通常是one <-> one。 ***

  合并外墙和控制器通常是有意义的

因此，在我看来，你的第一个提案更适合，例如。 UserController....。最重要的是保持务实。

Answer 2

我想说在服务层创建DTO会更好。

控制器不得知道业务逻辑细节。例如。我们需要返回用户信息，但必须排除某些字段（密码等）。这些字段存在于用户实体中，但必须从DTO中删除。

我们在Controller上获得SomePaginationDTO的另一个案例，我们仍然需要将DTO传递给服务来解析过滤器，应用排序，限制结果等。所有逻辑都是服务责任的一部分。所以我会将SomePaginationDTO传递给服务。

Answer 3

我想说没有规范的正确方法可以做到这一点。这取决于DTO的用途。

我为自己找到了一个简单的规则，即在服务级别使用DTO的位置以及不在何处使用：如果服务级别只有一个客户端，我会在服务级别使用DTO。如果有两个或更多客户端，最好不要在服务级别使用DTO。

让我更详细地解释一下：

基本上很明显，不将DTO纳入服务级别需要更多的努力。因此，如果只有一个客户端，我会保持简单，并使用DTO作为服务方法的返回类型。

如果服务的客户端多于一个，则客户端最有可能需要不同的DTO（例如，我希望对象的json和csv表示。在这种情况下，我不会从服务中返回DTO。否则，我需要为每个DTO或不同的服务方法等提供不同的服务。

注意：我不是说如果你不在服务级别使用DTO，你必须将转换逻辑移动到控制器级别。我仍然认为控制器级别必须尽可能简单。您可能在控制器和服务之间有一些中间转换级别 - 不舒服，但它比使用多个服务要好得多。

Answer 4

作为其他问题的一部分，我找到了一个很好的答案。当然这个/我的答案不参与赏金。这只是一个解释如何实现事物的灵感。所以看看：

• 模型类。他们不会为所有事情获得吸气剂/安装者。它 取决于模型逻辑。否则，您可以轻松获得模型 打破一致性。或者许多不明显的事情在哪里。假设你 有User.registrationDate字段。构建新用户时 对象，你不应该忘记字段registrationDate字段 手中。所以，只需将registrationDate初始化放在你的 构造函数并删除setter！
• 模型中的存储库界面。假设你有一些 依赖于现有存储对象的业务逻辑。你不能 明确地将您的域逻辑引用到基础架构中 依赖关系，如JPA，Hibernate，JDBC等。所以你查询这个存储 来自接口的对象。
• 商业服务（可选）。他们实现了一些复杂的逻辑 涉及许多不同的实体，不包括安全和 交易管理。你的问题是关于它的。是的，如果你需要的话 查询域逻辑中的实体，将查询放入存储库 并从您的商业服务中调用它。
• 基础架构包内的存储库实现。器物 存储库接口使用JPA或mockito或其他任何东西。他们 也不包括安全性和交易。
• 应用程序服务（可选）。如果有一些复杂的 与基础设施或安全检查的互动。
• 远程外观界面。客户端和服务器只能通过 远程门面界面。
• 远程外观实现（控制器）。转换厚实体 将对象转换为精简DTO（数据传输对象）。所有交易 划分和安全在这里（通常使用注释）。

您对该设计有何看法？是否适用于众所周知的春季mvc？