在一个完整的集群化 Java EE 应用程序中，DTO 模式仍然是一个有效的选项吗？有问题的应用程序使用 EJBs Hibernate 和 Struts with Spring 等。在这种情况下传输域对象有什么问题吗？
编辑：只是为了澄清我的问题，随着现代资源和 Java EE 的改进，是否有理由不只使用域对象？如果没有，那么 DTO 模式是否会逐渐淡出，不应该在新应用程序中使用？
【问题讨论】：
标签： java design-patterns jakarta-ee application-design
图案是纯粹的设计。模式没有“弃用”，但随着时间的推移（或过度使用）的使用减少。
就个人而言，我不明白为什么不使用 DTO。
例如 - 在oVirt 开源项目中，我们有代表虚拟化领域中业务逻辑实体的实体。
这些实体应该由 Hibernate 注释进行注释（实际上，它们在今天，因为我们开始研究休眠 POC）并用作 DTO，然后从将映射到它们的注释对象中清除（比如说，使用 dozer框架）并由客户端使用
（我不喜欢客户端代码带有不必要的注释），或者实体应该作为传递给客户端的客户端对象（值对象），我们应该让其他类作为 DTO 实体
上述方法的缺点是您可能有 2 个并行类图 - 一个用于 DTO，一个用于值对象（由客户使用） - 但是，在设计中的许多情况下，需要权衡取舍。
您必须了解优缺点并选择最适合您的（在我们的案例中，由于客户端是 GWT，因此我们更容易分离到两个类层次结构，一个是 DTO/服务器端并且可以也可以用更多的服务器端注释进行注释，而其他的发送到 GWT 客户端代码）。
【讨论】：
未弃用。是否应该使用 DTO 模式取决于应用程序架构。例如，当您开发 Web 服务（使用 JAX-WS 或 JAX-RS）时，您应该通过 Web 方法发送 DTO，以便 C# 或 Python 客户端应用程序可以使用它，并且您的 Web 方法不应返回类具有的对象休眠注解，请记住，与其他语言相比，实体不会使用这些注解或其他业务逻辑创建。
编辑（基于您的评论）：这取决于软件架构。例如，我正在处理一个 SOA 项目，我们将 DTO 用于服务层和表示层。更深入的内部，我们甚至使用 DTO 来处理服务内部的数据库通信，我们只使用 SP 与 DB 通信，所以没有 Hibernate 或任何其他 ORM 工具可以在那里工作，我们可以使用 Spring DAO 并且该框架也使用 DTO。现在，您可以在许多应用程序中找到很多 DTO 模式。
对这个问题有帮助的更多信息：
编辑 2：另一个信息来源，将解释使用 DTO 设计的主要原因，由 Martin Fowler 解释
结论：DTO 不是反模式。只有当您需要将数据从一个子系统传递到另一个子系统并且它们没有默认或标准的通信方式时，才需要使用 DTO。
【讨论】：
Serializable 接口，这只是他们遇到的问题的 J2EE 解决方案。
这是 Java EE 中非常有用的模式。
我使用 DTO 将相关实体对象从 EJB bean 传输到 UI 层。 在一个事务中（请参阅TransactionAttributeType.REQUIRED）从数据库中获取实体对象并存储在 DTO 对象中。 DTO 在 UI 层中使用。
【讨论】：