我理解将数据层对象（DAO）分离在自己的层中，该层从服务层和业务层中抽象出数据访问逻辑和数据源细节，如中所述DAO 和服务层（JPA/Hibernate + Spring）以及其他问题。我有创建这些层的经验，但我总是使用原始 JDBC 或类似的较低级别的数据库接口方式（例如 Spring 的 SimpleJDBC），并且是 Hibernate 的新手。
我的问题是，在原始 JDBC 或其他方式中，您实际上在数据访问层处理结果集（或其周围的薄包装器），您粘贴数据的结果 POJO 非常干净，并且对位置一无所知数据来自哪里，我从不担心将它们返回到服务层及其他层。然而，对于 Hibernate，您似乎在 POJO 注释中拥有大量 Hibernate/数据结构特定逻辑（例如一对多映射、延迟加载首选项等）。我对从 DAO 和服务层返回它们（或它们的集合）感到不舒服，并试图让所有 POJO 实现我传回的接口。这是好的做法还是过于复杂？
注解的一个缺点是将一些框架知识与 Java 对象耦合在一起。这就是您因没有单独的元数据定义而付出的代价。不过，POJO 仍然是 POJO，从实际角度来看，我认为没有理由仅仅因为注释而使设计复杂化。
让我们想一下，如果您使用 XML 映射，您还会有这样的担忧吗？最有可能的是——不是。因此，支付罚款并继续前进；在不太可能的情况下，如果您要更改持久性框架 - 您将继续删除这些注释。在所有情况下，它们都不应该对 DAO 层之外的代码产生任何副作用。
只是我的2分钱...
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
