是否应该从数据访问层或接口返回原始的 Hibernate 注释 POJO？

Posted 2023-04-18

【中文标题】是否应该从数据访问层或接口返回原始的 Hibernate 注释 POJO？

【英文标题】：Should raw Hibernate annotated POJO's be returned from the Data Access Layer, or Interfaces instead?

【发布时间】：2011-12-12 05:52:35

【问题描述】：

我理解将数据层对象 (DAO) 分离到它们自己的层中，该层将数据访问逻辑和数据源细节从服务和业务层中抽象出来，如 DAO and Service layers (JPA/Hibernate + Spring) 和其他问题中所述。我有创建这些层的经验，但我一直使用原始 JDBC 或类似的与 DB 交互的较低级别的方式（例如 Spring 的 SimpleJDBC），并且是 Hibernate 的新手。

我的问题在于，在原始 JDBC 或您在数据访问层实际处理结果集（或围绕它的瘦包装器）的其他方式中，您粘贴数据的结果 POJO 非常干净并且知道对数据的来源一无所知，我从不担心将这些数据返回到服务层及其他层。但是，使用 Hibernate，您似乎在 POJO 注释中有很多 Hibernate / 数据结构特定逻辑（例如一对多映射、延迟加载首选项等）。从我的 DAO 到我的服务层返回它们（或它们的集合）我感到不舒服，并且很想让所有 POJO 实现我传回的接口。这是一种好的做法，还是过于复杂？

【参考方案1】：

注解的一个缺点是将一些框架知识与 Java 对象相结合。这就是您为没有单独的元数据定义而付出的代价。但是，POJO 仍然是 POJO，从实际的角度来看，我认为没有充分的理由仅仅因为注释而使设计复杂化。

让我们想一想，如果您使用 XML 映射，您还会有这个顾虑吗？最有可能 - 不是。所以支付罚款并继续前进；并且在不太可能的情况下，如果您要更改持久性框架 - 您将继续删除这些注释。在所有情况下，它们都不应该对 DAO 层之外的代码产生副作用。

只要我的 2 美分...

【讨论】：

权衡利弊后，我同意。对于只读数据访问，我喜欢接口的想法，但是从接口回到知道如何存储自己以通过反射或类似方式保存的 pojo 太痛苦了。

【参考方案2】：

两者 ;) 我很矛盾——我更喜欢接口，它只是更容易模拟、跨非 Hibernate 系统使用等，但在我的情况下，我通常需要提供带有数据类型的外部 API，所以这几乎总是有意义的。那，我会自动生成接口，所以我实际上不必做任何事情。

对于没有外部 API 要求的隔离系统，或者如果您从不需要 Hibernate 之外的类型，我不认为这真的有那么重要，尽管纯粹主义者会因为这样说而大吃一惊（并且他们可以说是正确的）。

【讨论】：

Dave，当使用接口并接受来自服务层的数据以由数据访问层持久化时，您在什么时候以及如何处理 POJO 的创建？你有从接口到 POJO 的工厂吗？

@Pete 取决于。应用程序内我经常只是传递 Hibernate/JPA 对象，因为它不值得做任何其他事情。当我这样做时，我会使用 Apache Commons 的 BeanUtils 之类的东西，其中包含反射属性复制方法；实例化对象的方法各不相同。