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