java DTO 模式是否已弃用？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/11237946/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is DTO pattern deprecated or not?
提问by Thihara
In a complete Java EE application that's clustered is the DTO pattern still a valid option? The application in question uses EJBs Hibernate and Struts with Spring etc. Is there anything wrong with transferring domain objects in such a scenario?
在一个完整的集群 Java EE 应用程序中，DTO 模式仍然是一个有效的选择吗？有问题的应用程序使用 EJBs Hibernate 和 Struts with Spring 等。在这种情况下传输域对象有什么问题吗？
EDIT: Just to clarify my question, with modern day resources and improvements in Java EE is there a reason not to just use domain objects? If there is not then isn't DTO pattern sort of fading out and shouldn't be used in new applications?
编辑：只是为了澄清我的问题，随着现代资源和 Java EE 的改进，是否有理由不只使用域对象？如果没有，那么 DTO 模式是否会逐渐淡出并且不应在新应用程序中使用？
回答by Luiggi Mendoza
Is not deprecated. It depends on the application architecture if the DTO pattern should be used or not. For example, when you develop Web Services (using JAX-WS or JAX-RS), you should send DTO's over your web methods so a C# or Python client application may consume it, and your web method should not return an object which class has Hibernate annotations, remember than in other languages the Entity won′t be created with those annotations or other business logic inside.
不被弃用。是否应使用 DTO 模式取决于应用程序架构。例如，当您开发 Web 服务（使用 JAX-WS 或 JAX-RS）时，您应该通过 Web 方法发送 DTO，以便 C# 或 Python 客户端应用程序可以使用它，并且您的 Web 方法不应该返回类具有的对象Hibernate 注释，请记住，与其他语言相比，实体不会使用这些注释或其他业务逻辑创建。
EDIT (Based in your comment): That depends on the software architecture. For example, I'm working on a SOA project and we use DTO's for the Services Layer and the Presentation Layer. More deeper inside, we even use DTO's to handle database communication inside the services, we use only SP's to communicate with DB, so no Hibernate or any other ORM tools can work there, we could use Spring DAOand that framework uses DTO's too. You can find lots of DTO pattern in many applications nowadays.
编辑（基于您的评论）：这取决于软件架构。例如，我正在处理一个 SOA 项目，我们将 DTO 用于服务层和表示层。更深入的内部，我们甚至使用 DTO 来处理服务内部的数据库通信，我们只使用 SP 与 DB 进行通信，因此没有 Hibernate 或任何其他 ORM 工具可以在那里工作，我们可以使用Spring DAO，该框架也使用 DTO。如今，您可以在许多应用程序中找到许多 DTO 模式。
More info that would be great for this question:
更多信息对这个问题很有帮助：
- Difference between DTO, VO, POJO, JavaBeans?(where basically, any DTO is a POJO).
- Core J2EE Patterns - Transfer Object
- DTO、VO、POJO、JavaBeans 的区别？（基本上，任何 DTO 都是 POJO）。
- 核心 J2EE 模式 - 传输对象
EDIT 2: Another source of information that will explain the main reason for using DTO's design, explained by Martin Fowler
编辑 2：另一个信息来源将解释使用 DTO 设计的主要原因，由Martin Fowler解释
Conclusion: DTO's are not an anti pattern. DTO's are meant to be used only when you need to pass data from one subsystem to another and they don't have a default or standar way to communicate.
结论：DTO 不是反模式。DTO 仅在您需要将数据从一个子系统传递到另一个子系统时使用，并且它们没有默认或标准的通信方式。
回答by Martin Mecera
It is a very useful pattern in Java EE.
这是 Java EE 中非常有用的模式。
I use a DTO to transfer related entity objects from EJB beans to the UI layer. The entity objects are fetched from DB in one transaction(see TransactionAttributeType.REQUIRED) and stored in the DTO object. The DTO is consumedin the UI layer.
我使用 DTO 将相关实体对象从 EJB bean 传输到 UI 层。实体对象在一个事务中从 DB中获取（请参阅TransactionAttributeType.REQUIRED）并存储在 DTO 对象中。DTO在 UI 层消耗。
回答by Yair Zaslavsky
A pattern is pure design. There is no "deprecation" of pattern, but less usage over time (or over-usage).
Personally, I don't see why not to use DTOs.
For example - at oVirtopen source project we have entities representing business logic entities in the domain of Virtualization.
These entities should be either annotated by Hibernate annotations (actually, they are today, as we started working on hibernate POCs) and serve as the DTOs , and then have clean from annotations objects that will mapped to them (let's say, using dozerframework) and used by client
(I don't like have at client side code with unnecessary annotations), or the entities should serve as the client objects (value objects) passed to the client and we should have other classes serve as the DTO entities
The minus in the above approach is that you might have 2 parallel class diagrams - one for DTOs and one for value objects (that are used by clients) - but , in many cases in design , there is a trade-off.
You must understand the advantages and disadvantages and pick what is best for you (In our case, since the client side is GWT, it will be easier for us to go for separation to two class hierarchies, one that is DTO/server side and can be also annotated with more server side only annotations, and the other sent to the GWT client code).
图案是纯粹的设计。模式没有“弃用”，但随着时间的推移使用量减少（或过度使用）。
就个人而言，我不明白为什么不使用 DTO。
例如 - 在oVirt开源项目中，我们有实体代表虚拟化领域中的业务逻辑实体。
这些实体要么被 Hibernate 注释注释（实际上，它们是今天，因为我们开始研究休眠 POC）并充当 DTO，然后从将映射到它们的注释对象中清除（假设，使用推土机框架）并由客户使用
（我不喜欢在客户端代码中有不必要的注释），或者实体应该作为传递给客户端的客户端对象（值对象），我们应该让其他类作为 DTO 实体
上述方法中的减号是您可能有 2 个并行的类图 - 一个用于 DTO，一个用于值对象（由客户端使用） - 但是，在设计中的许多情况下，存在权衡。
你必须了解优点和缺点并选择最适合你的（在我们的例子中，由于客户端是 GWT，我们更容易分离到两个类层次结构，一个是 DTO/服务器端并且可以也可以用更多的服务器端注解进行注解，其他的发送到 GWT 客户端代码）。
