我有一个关于使用Hibernate注释和DAO模式的设计问题。 DTO应该表示数据模型的实体。 DAO是定义这些DTO操作的接口。 DAO实现是实现DAO接口的类，并实现由这些接口定义的操作（例如使用Hibernate/MySQL）。 我的问题是：如何在这种情况下使用Hibernate注释？如果我直接注释DTO，我将DTO与Hibernate框架结合起来，这是我认为不好的做法。Hibernate注释和DTOs
也许这是一个简单的问题，但问题很有趣。
谢谢
这是一个问题或假设“独立”与易用性。要么选择使用Hibernate或其他JPA引擎，而且确实需要在实体上注释并在类路径中使用hibernate jar来使用它们。或者您选择完全独立于JPA/Hibernate，但您必须自己实现整个持久性。
我的观点是，牺牲JPA提供的易用性和工作效率只是为了避免类路径中的某些jar是不好的选择。但是YMMV。
如果我正确理解你，DTO是Hibernate和你的数据库表之间的对象关系映射，如果是这种情况，我相信你最好有你的DTO对象注释。
当您使用从javax.persistence包注释你不与Hibernate连接你的代码（但是你会使用org.hibernate作为注解的时候，因为它们依赖于第三方库）。
请注意，注释只是元信息不会影响您的设计（您不强制类来实现像接口一样的方法），只是为了某些目的使用附加信息注释它们。
只要注释属于标准化java api（本例中为javax.persistence），注释类的客户端就不会被迫将其代码与其他依赖项耦合在一起。
是的，但如果我使用javax.persistence包，我将代码耦合到JPA，并且有不使用JPA和Hibernate的DAO实现。我的想法是让DTO完全独立于特定的实现。你怎么看？ –
如果完全解耦任何代码（甚至是JPA）是您的首要任务，请使用hibernate XML映射。他们比较冗长，不太舒服（至少对我来说），但是符合你的要求。但请记住，注释在这里只是为了简单起见，所以你应该仔细考虑你的jpa耦合类是否会出现在非jpa项目中。 – Xorty
好的，我明白我需要考虑我的DTO的未来。如果我们用来坚持它们的唯一方法是JPA/Hibernate，则可以使用注释。否则，在Hibernate特定项目中使用XML映射会使映射配置更容易。 –
维基百科：
在传统的EJB（企业JavaBeans）架构，DTO的双重用途：首先，他们解决的是实体bean预EJB的问题3.0不能序列;其次，它们隐含地定义了一个汇编阶段，在该阶段中，在将控制权返回到表示层之前，将视图所使用的所有数据提取并编入DTO中。使用DTO的第三个原因可能是应用程序的某些层不能访问底层的数据访问对象，从而更改数据。
因此DTO是由实体创建并由表示层使用的对象（JSP，例如应该直接访问DTO-s而不是实体）。所以，你不应该注释DTO-s而是你的实体类，然后提供代码来将实体转换为DTO-s。
所以在你的情况下，你有两个Hibernate实体和DTO，都由类表示。当你想修改模型会发生什么？你需要在DTOs层面和实体层面上工作两次？ –
没错;请注意，在维基百科文章中引用的“传统EJB（Enterprise JavaBeans）体系结构”的情况下，无论何时更改实体EJB，您还需要更改相应的DTO。 –
我在想一个项目可以专用于未注释的DTO和DAO接口。另外还有一个专门用Hibernate的XML映射文件来实现DAO的项目。所以，DAO接口和DTO完全独立于特定的实现。在这种情况下，您认为使用Hibernate的XML映射文件是最佳实践吗？ –
Hibernate不使用DTO。它使用实体。一旦你从Hibernate会话中获得一个实体，它就会保持连接到会话，并且你应用到实体的所有更改都会自动在数据库中持久化，而不需要调用任何DAO.update（）方法。从一个实体到另一个实体的所有关联都会通过导航到对象图形而自动加载。您可能会将这些实体分离出来（从而使它们成为DTO），但是这会让JPA非常有用，从而失去了很大一部分内容。 –
我从你的评论中了解到，DAO模式和Hibernate是“不兼容的”。因为我们可以通过Hibernate的方法更新实体，所以在这种情况下我们不需要使用DAO？ –