使用DTO（数据传输对象）有什么意义？

使用DTO的意义何在？它是过时的概念吗？我在视图层中使用POJO来传输和保留数据。可以将这些POJO视为DTO的替代方法吗？

DTO是一种模式，它独立于实现（POJO / POCO）。DTO说，由于对任何远程接口的每次调用都是昂贵的，因此对每个调用的响应应带来尽可能多的数据。因此，如果需要多个请求来携带特定任务的数据，则可以将要携带的数据合并到DTO中，以便只有一个请求可以携带所有必需的数据。企业应用程序体系结构模式目录有更多详细信息。

DTO是一个基本概念，并非过时。

DTO作为一个概念（目的是收集要由服务器返回给客户端的数据的对象）当然不是过时的。

什么是有些过时是具有不包含逻辑在所有的DTO的概念中，使用仅用于发送数据和从域对象“映射”传输之前给客户端，并且有映射它们传递给显示层之前查看模型。在简单的应用程序中，域对象通常可以直接用作DTO，并直接传递到显示层，因此只有一个统一的数据模型。对于更复杂的应用程序，您不想将整个域模型公开给客户端，因此从域模型到DTO的映射是必需的。拥有一个单独的视图模型来复制来自DTO的数据几乎是没有意义的。

但是，此概念过时而不是简单错误的原因是某些（主要是较旧的）框架/技术需要它，因为它们的域和视图模型不是POJOS，而是直接与框架绑定。

最值得注意的是，EJB 3标准之前的J2EE中的Entity Bean不是POJO，而是由应用服务器构造的代理对象-根本不可能将它们发送给客户端，因此您没有选择拥有单独的DTO层-这是强制性的。

尽管DTO并不是一种过时的模式，但通常会不必要地应用它，这可能会使它显得过时。

Java Enterprise社区中最被滥用的模式是DTO。DTO被明确定义为分配问题的解决方案。DTO旨在成为一种粗粒度的数据容器，可以在流程（层）之间有效地传输数据。〜亚当·比恩

例如，假设您有一个JSF ManagedBean。一个常见的问题是，bean是应该直接持有对JPA实体的引用，还是应该维护对某些中间对象的引用，该对象随后将转换为Entity。我听说过这个称为DTO的中间对象，但是如果您的ManagedBeans和Entities在同一个JVM中运行，那么使用DTO模式几乎没有好处。

考虑Bean验证注释。您的JPA实体可能使用@NotNull和@Size验证进行注释。如果您使用的是DTO，则需要在DTO中重复这些验证，以便使用远程接口的客户端无需发送消息即可发现其基本验证失败。想象一下在DTO和实体之间复制Bean验证批注的所有额外工作，但是如果您的视图和实体在同一JVM中运行，则无需进行这项额外工作：只需使用实体。

IAmTheDude到企业应用程序体系结构模式目录的链接提供了DTO的简要说明，下面是我发现的更多参考：

• 如何处理J2EE和设计模式
• 如何在JSF + Spring + Hibernate中使用DTO
• 数据传输对象的优缺点

绝对不！最近，我吸取了关于更好地使用DTO而不是使用您的业务对象（可能绑定到ORM映射器）的经验教训。

但是，仅在适合使用它们时才使用它们，而不仅仅是为了使用它们，因为它们在一些好的模式书中都有提及。
我想到的一个典型示例是当您向第三方公开某种界面时。在这种情况下，您希望保持交换对象相当稳定，通常可以使用DTO很好地实现它们。

我发现DTO尤其有用的一个地方是包含API响应的逻辑。通过这种模式，可以以可测试的方式轻松管理从对象到各种格式的不同类型的响应。在我目前的职位上使用此模式，我们能够开始测试API的响应格式，这很有价值，因为我们的堆栈在各种客户端（http / mobile）下变得更加同构。绝对不会过时。