我想了解当您已经拥有 POJO 对象（作为实体）时创建 DTO 对象有什么好处。
在我的项目中我有：
如果我查看 DTO 对象类（让我们称之为 MyObjDTO）和相同的类，但 POJO 方面（让我们称之为 MyObjPOJO），除了 MyObjPOJO 作为注释之外没有任何区别，因为它是一个 @Entity。
所以事实上，我在我的项目中得到了 2 个类，它们看起来相同（相同的属性，相同的方法），但用于不同的 puprose。
IMO，在这种情况下，DTO 类是无用的，并且会增加应用程序的复杂性，因为我对 DTO 类所做的所有操作都可以用 POJO 类来完成，而且，对于单一类型的对象，我必须维护至少 2 个类（DTO 和POJO），例如，如果我添加一个属性，我必须在两个类中添加该属性。
我不是专家，我对自己的想法提出疑问；你怎么看待这件事 ？
这个答案是在堆栈交换上可以找到的内容的复制品。恕我直言，OP应该因为发布在错误的论坛而被关闭。目前它也吸引了固执己见的答案，尽管不一定如此，并且与 java 没有任何特定的联系。
DTO 是一种模式，它独立于实现（POJO/POCO）。DTO 表示，由于对任何远程接口的每次调用都很昂贵，因此对每个调用的响应应该带来尽可能多的数据。因此，如果需要多个请求来为某一特定任务带来数据，则可以将要带来的数据合并在一个 DTO 中，这样只有一个请求就可以带来所有所需的数据。企业应用程序架构模式目录有更多详细信息。
DTO 是一个基本概念，并未过时。
有点过时的是，DTO 根本不包含逻辑，仅用于传输数据，并在传输到客户端之前从域对象“映射”，并在将数据传递到显示层之前映射到视图模型。在简单的应用中，领域对象往往可以直接作为DTO复用，直接传递到显示层，这样就只有一个统一的数据模型。对于更复杂的应用程序，您不希望将整个域模型公开给客户端，因此需要从域模型到 DTO 的映射。拥有一个单独的视图模型来复制 DTO 中的数据几乎没有任何意义。
然而，这个概念之所以过时而不是完全错误，是因为一些（主要是较旧的）框架/技术需要它，因为它们的域和视图模型不是 POJOS，而是直接与框架绑定。
最值得注意的是，EJB 3 标准之前的 J2EE 中的实体 Bean 不是 POJO，而是由应用服务器构造的代理对象 - 根本不可能将它们发送到客户端，因此您别无选择，拥有一个单独的 DTO 层- 这是强制性的。
尽管 DTO 并不是一种过时的模式，但它经常被不必要地应用，这可能会使其显得过时。
来自 Java 大师 Adam Bien：
Java Enterprise 社区中最常被误用的模式是 DTO。DTO 被明确定义为分布式问题的解决方案。DTO 是一个粗粒度的数据容器，可以在进程（层）之间有效地传输数据。〜亚当·比恩
来自马丁·福勒：
DTO 被称为数据传输对象，因为它们的全部目的是在昂贵的远程调用中传输数据。它们是实现远程接口性能所需的粗粒度接口的一部分。您不仅在本地上下文中不需要它们，而且它们实际上是有害的，因为粗粒度的 API 更难以使用，而且您必须完成将数据从域或数据源层移动到 DTO 的所有工作。〜马丁·福勒
下面是一个常见但不正确使用 DTO 模式的 Java EE 特定示例。如果您不熟悉 Java EE，您只需要了解 MVC 模式：“JSF ManagedBean”是视图使用的类，“JPA Entity”是 MVC 模式中的模型。
举例来说，假设您有一个 JSF ManagedBean。一个常见的问题是 bean 是否应该直接保存对 JPA 实体的引用，或者应该维护对稍后转换为实体的某个中间对象的引用。我听说这个中间对象被称为 DTO，但是如果您的 ManagedBean 和实体在同一个 JVM 中运行，那么使用 DTO 模式几乎没有什么好处。
此外，考虑 Bean Validation 注释（同样，如果您不熟悉 Java EE，请知道 Bean Validation 是用于验证数据的 API）。您的 JPA 实体可能带有 @NotNull 和 @Size 验证注释。如果您使用 DTO，则需要在 DTO 中重复这些验证，以便使用远程接口的客户端不需要发送消息来发现他们未通过基本验证。想象一下在 DTO 和实体之间复制 Bean Validation 注释的所有额外工作，但如果您的视图和实体在同一个 JVM 中运行，则无需承担这项额外工作：只需使用实体即可。
企业应用程序架构模式目录提供了 DTO 的简明解释，以下是我发现的更多有启发性的参考资料：
| 归档时间： |
|
| 查看次数： |
6446 次 |
| 最近记录： |