11

在集群的完整 Java EE 应用程序中，DTO 模式仍然是一个有效的选项吗？有问题的应用程序使用 EJBs Hibernate 和 Struts with Spring 等。在这种情况下传输域对象有什么问题吗？

编辑：只是为了澄清我的问题，随着现代资源和 Java EE 的改进，是否有理由不只使用域对象？如果没有，那么 DTO 模式是否会逐渐淡出，不应该在新应用程序中使用？

4

3 回答 3

22

不被弃用。是否应该使用 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 仅在您需要将数据从一个子系统传递到另一个子系统并且它们没有默认或标准的通信方式时使用。

于 2012-06-28T06:02:10.627 回答
2

它是 Java EE 中非常有用的模式。

我使用 DTO 将相关实体对象从 EJB bean 传输到 UI 层。实体对象在一个事务中从 DB 中获取（请参阅TransactionAttributeType.REQUIRED）并存储在 DTO 对象中。DTO在 UI 层中使用。

于 2012-06-28T06:58:57.500 回答
1

图案是纯粹的设计。模式没有“弃用”，但随着时间的推移（或过度使用）使用量减少。
就个人而言，我不明白为什么不使用 DTO。
例如 - 在oVirt开源项目中，我们有代表虚拟化领域中业务逻辑实体的实体。
这些实体应该由 Hibernate 注释进行注释（实际上，它们在今天，因为我们开始研究休眠 POC）并用作 DTO，然后从将映射到它们的注释对象中清除（假设使用推土机框架）并被客户使用
（我不喜欢客户端代码带有不必要的注释），或者实体应该作为传递给客户端的客户端对象（值对象），我们应该让其他类作为 DTO 实体

上述方法中的减号是您可能有 2 个并行类图——一个用于 DTO，一个用于值对象（由客户使用）——但是，在设计中的许多情况下，需要进行权衡。
您必须了解优缺点并选择最适合您的（在我们的案例中，由于客户端是 GWT，因此我们更容易分离到两个类层次结构，一个是 DTO/服务器端并且可以也可以用更多的服务器端注释进行注释，而其他的发送到 GWT 客户端代码）。

于 2012-06-28T04:23:54.027 回答