我在使用Hibernate的两个数据库项目设计之间犹豫不决。
设计＃1。
（1）创建通用数据提供者接口，包括一组DAO接口和通用数据容器类。它隐藏了底层实现。数据提供程序实现可以访问数据库中的数据，XML文件，服务或其他内容。数据提供者的用户不知道它。
（2）使用Hibernate创建数据库库。该库实现了（1）中的数据提供者接口。
设计＃1的坏处是，为了隐藏实现细节，我需要创建两组数据容器类。一般数据提供者接口中的一个 - 让我们称之为DPI-Objects，另一个用于数据库库，专门用于Hibernate中的实体/属性映射 - 让我们称之为H-Objects。在DAO实现中，我需要从数据库中读取数据以创建H-Objects（通过Hibernate），然后将H-Objects转换为DPI-Objects。
设计＃2。
不要创建通用数据提供程序接口。将H-Objects直接暴露给使用数据库lib的组件。因此，数据库库的用户需要了解Hibernate。
我更喜欢设计＃1，但我不想创建两组数据容器类。这是从使用基于数据库的数据提供程序的用户隐藏H-Objects和其他Hibernate实现细节的正确方法吗？
设计＃2有任何缺点吗？我不会在新的未来实现其他数据提供程序，所以我应该忘记数据提供程序接口并使用Design＃2吗？
您如何看待这个？谢谢你的时间！
答案 0 :(得分：1)
Hibernate Domain对象是简单的POJO，因此您不必创建单独的DPI对象，H-Object本身可以直接使用。在DAO中，您可以控制它们是来自休眠还是其他任何东西。
答案 1 :(得分：0)
我推荐设计＃2。只需构造域对象，让hibernate照顾它们。不要编写持久化的单独类。
Hibernate试图隐藏大部分持久性业务。您可能需要向实体添加一些小注释以帮助它。但当然不要单独上课。
您可能需要一些非常小的DAO类。例如，如果您有一个Person实体，那么拥有一个保存一个人的PersonDAO对象是相当普遍的做法。话虽如此，DAO中的代码将非常简单，因此对于一个非常小的项目，它可能不值得。对于大型项目，可能值得将持久性代码与业务逻辑分开，以防您以后想要使用不同的持久性技术。
答案 2 :(得分：0)
我强烈建议您阅读Spring in Action, 3rd edition的第4章“点击数据库”，即使您未在应用程序中使用Spring。虽然我的第二个建议是使用Spring :-)
DAO模式是在DAO实现中保持数据库和ORM逻辑隔离的好方法，您只需要一组实体对象。你可以在没有Spring的情况下实现这一目标，只需要更多的工作来管理会话和事务。
如果我理解你的帖子，那么它就是设计1和设计2之间的中间层.H-Objects（Hibernates加载和持久化的实体）根本不需要任何特定于Hibernate的代码。这使得它们完全可以被用作DPI对象。
我曾经和过去的人争论过，他们抱怨使用JPA或Hibernate Annotations通过DAO接口公开Hibernate细节。我个人采取更务实的观点，因为注释只是元数据，并且不直接影响实体类的操作。
如果您确实认为注释过多，那么您可以上学并使用Hibernate Mappings代替。那么你的H-Objects是100％免费的Hibernate： - ）