最佳实践——实体本身内部的 Hibernate 持久化代码？
在 Google 的 RequestFactory 教程中，他们建议将我的持久性逻辑（在我的例子中为 Hibernate）放入实体类中。然后他们提出问题：“如果您不想在实体本身中实现持久性代码怎么办？”并继续解释另一种方法。
我的问题：将持久性逻辑放在实体类中，还是将所有持久性逻辑保留在单独的类中，哪个更好？
任何信息表示赞赏，谢谢。
-tjw
In Google's RequestFactory tutorials, they recommend putting my persistence logic (in my case, Hibernate) inside the Entity classes. Then they pose the question: "What if you don't want to implement persistence code in an entity itself?" and proceed to explain an alternate method.
My question: which is better, putting persistence logic inside the Entity class, or keeping all persistence logic in a separate class?
Any info is appreciated, thanks.
-tjw
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
将持久性代码放在实体本身中是一种活动记录模式方法，而将所有持久性逻辑保留在单独的类中是存储库模式方法。您可以使用关键字
repository pattern vs activerecord来搜索有关您的问题的更多信息。例如，活动记录模式因其在没有数据库的情况下的可测试性受到批评，您可以参考此了解更多信息。
对我来说，我更喜欢存储库模式，因为它是可测试的，并且我不喜欢将持久性代码和领域业务逻辑混合在一个类中，这违反了对关注点分离的强调。
Putting the persistence code in an entity itself is an Active Record Pattern approach while keeping all persistence logic in a separate class is the Repository Pattern approach. You can use the keyword
repository pattern vs activerecordto search more information about your questions.For example ,active record pattern has a criticism about its testability without a database , you can refer to this for more info .
For me , I prefer the Repository Pattern more as it is testable and I don't like persistence codes and domian business logic are mixed in one class which violates the emphasis on separation of concerns.