原始 Hibernate 带注释的 POJO 应该从数据访问层返回，还是从接口返回？
我理解将数据层对象（DAO）分离在自己的层中，该层从服务层和业务层中抽象出数据访问逻辑和数据源细节，如 DAO 和服务层（JPA/Hibernate + Spring） 以及其他问题。我有创建这些层的经验，但我总是使用原始 JDBC 或类似的较低级别的数据库接口方式（例如 Spring 的 SimpleJDBC），并且是 Hibernate 的新手。
我的问题是，在原始 JDBC 或其他方式中，您实际上在数据访问层处理结果集（或其周围的薄包装器），您粘贴数据的结果 POJO 非常干净，并且不知道在哪里数据来自哪里，我从不担心将它们返回到服务层及其他层。然而，对于 Hibernate，您似乎在 POJO 注释中拥有大量 Hibernate/数据结构特定逻辑（例如一对多映射、延迟加载首选项等）。我对从 DAO 和服务层返回它们（或它们的集合）感到不舒服，并且很想让所有 POJO 实现我传回的接口。这是好的做法还是过于复杂？
I understand separating the data layer objects (DAOs) in their own layer that abstracts the data access logic and data source specifics from service and business layers as outlined in DAO and Service layers (JPA/Hibernate + Spring) and other questions. I have experience creating these layers, but I've always used either raw JDBC or similar lower level ways of interfacing with the DB (such as Spring's SimpleJDBC), and am new to Hibernate.
My question comes in that in raw JDBC or other ways where you are actually dealing with a result set (or a thin wrapper around it) at the data access layer, the resulting POJOs where you stick your data are extremely clean and know nothing about where the data came from, and I've never worried about returning these to the service layer and beyond. However it appears that with Hibernate, you have a lot of your Hibernate / data structure specific logic right in the POJO annotations (things like 1 to many mappings, lazy loading preferences, etc). I feel uncomfortable returning them (or Collections of them) from my DAOs and up to my service layer and am tempted to have all the POJOs implement interfaces that I pass back instead. Is this good practice, or over complicating?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
注解的一个缺点是将一些框架知识与 Java 对象耦合在一起。这就是您因没有单独的元数据定义而付出的代价。不过，POJO 仍然是 POJO，从实际角度来看，我认为没有理由仅仅因为注释而使设计复杂化。
让我们想一下，如果您使用 XML 映射，您还会有这样的担忧吗？最有可能的是——不是。因此，支付罚款并继续前进；在不太可能的情况下，如果您要更改持久性框架 - 您将继续删除这些注释。在所有情况下，它们都不应该对 DAO 层之外的代码产生任何副作用。
只是我的2分钱...
Annotations have one drawback of coupling some framework knowledge with Java objects. That's the price you pay for not having separate metadata definitions. POJOs still remain POJOs, though, and from practical standpoint I see no good reason to complicate design just because of annotations.
Lets think, if you would use XML mappings, would you even have that concern? Most likely - not. So pay the penalty and move on; and in unlikely case if you will be changing your persistence framework - you will go ahead and remove those annotations. In all cases they should have no side effects on your code outside of your DAO layer.
Just my 2 cents...
两者；）我都很矛盾——我更喜欢接口，它更容易模拟，跨非 Hibernate 系统使用等等。但就我而言，我通常需要提供带有数据类型的外部 API，所以它几乎总是有道理。然后，我会自动生成接口，因此我实际上不必做任何事情。
对于没有外部 API 需求的隔离系统，或者如果您从不需要 Hibernate 之外的类型，我不相信它真的那么重要，尽管纯粹主义者会因为这样说而感到愤怒（而且他们是可以说是正确的）。
Both ;) I'm pretty ambivalent--I prefer interfaces, it's just easier to mock, use across non-Hibernate systems, etc. but in my case I've usually needed to provide an external API with datatypes, so it's almost always made sense. That, and I generate the interfaces automatically, so I don't have to actually do anything.
For isolated systems with no external API requirements, or if you never need the types outside of Hibernate, I'm not convinced it really matters all that much, although the purists will have my head on a pike for saying so (and they're arguably correct).