我有一个关于使用Hibernate注释和DAO模式的设计问题。DTO应该表示数据模型的实体。dao是定义这些dto上的操作的接口。DAO实现是实现DAO接口并实现这些接口定义的操作的类(例如使用Hibernate/MySQL)。我的问题是:在这种情况下如何使用Hibernate注释?如果我直接注释DTO，我将我的DTO与Hibernate框架耦合在一起，我认为这是一个不好的实践。
也许这是一个简单的问题，但这个问题很有趣。
谢谢
这是所谓的"独立性"与易用性的问题。您要么选择使用Hibernate，要么选择另一个JPA引擎，您确实需要在实体上有注释，并在类路径中有Hibernate jar来使用它们。或者您选择完全独立于JPA/Hibernate，但必须自己实现整个持久性。
我的观点是，牺牲JPA提供的易用性和生产力收益只是为了避免类路径中的一些jar是一个糟糕的选择。但YMMV。
当您使用来自javax的注释时。你的持久化包不是耦合你的代码与Hibernate(但是当你使用org。Hibernate注释，因为它们依赖于第三方库)。
请注意，注释只是元信息，不会影响您的设计(您不会强制类实现像接口那样的方法)，您只是为某些目的用附加信息注释它们。
只要注释属于标准化的java api (javax. xml)，带注释类的客户端就不会被迫将其代码与额外的依赖项耦合。
如果我对您的理解正确的话，DTO是Hibernate和数据库表之间的对象关系映射，如果是这样的话，我认为您最好对DTO对象进行注释。
来自维基百科:
因此，DTO是由实体创建并由表示层使用的对象(例如，JSP应该直接访问DTO而不是实体)。因此，您应该注释实体类而不是dto类，然后提供将实体转换为dto的代码。在传统的EJB (Enterprise JavaBeans)体系结构中，dto服务于双重目的:首先，它们解决EJB 3.0之前的实体bean不可序列化的问题;其次，它们隐式地定义了一个组装阶段，在此阶段中，视图将使用的所有数据在将控制权返回给表示层之前被提取并编组到dto中。[引文需要];使用dto的第三个原因可能是应用程序的某些层不应该能够访问底层数据访问对象，从而更改数据。