如何使用Hibernate进行面向对象编程？

Question

在使用Hibernate等ORM工具时,我发现将所有业务逻辑从业务对象中排除,而不是将其保存在服务层中是有利的.服务层创建业务对象POJO,操作它们,并使用DAO来保存它们.但是,这不是从Java的面向对象性质向后退一步吗？

我的堆栈包括用于DI,事务和持久性的Spring with Hibernate.我的DAO被注入我的服务层,而不是注入任何POJO.

最近我读了Martin Fowler 关于建立灵活会计系统的会计模式文档.我相信它是在Spring/Hibernate/DI/ORM热潮之前编写的.它描述了包含业务逻辑的对象.这些对象以优雅的方式使用继承和组合.

通过将逻辑放入类中,可以将其划分为仅与一个特定场景相关的整齐单元.在我的服务层中,我最终拥有许多不同的方法,每种方法都处理不同的场景.但它远非面向对象.

在Martin Fowler的会计模式文档中,他描述了一个基类AccountingEvent.这个类可能有子类,如UsageEvent和InstallationEvent.

UsageEvent:

UsageEvent 当仪表读卡器记录您的用电量时发生
顾客ServiceAgreement被抬起头来
PostingRule对于此类事件以及此特定时间段,在服务协议中找到适当的s.规则和费率可以随时间变化,因此PostingRule对于任何给定类型的事件都存在多个s.
在UsageEvent与PostingRule■确定哪些行动需要采取的地方,比如创建一个或多个AccountingEntry对象.
AccountingEntry创建一个用于计算包含在中的逻辑的用法PostingRule.这可能很简单rate * usage,但可能会更复杂,基于一天中的时间,承诺水平(大企业可能获得折扣),低收入家庭等.
AccountingEntry创建额外的s来计税,提供信用等.

InstallationEvent:

关键在于有许多不同类型的AccountingEvents和PostingRules,每种类型都知道如何针对特定情况做什么.这些对象可以使用接口轻松互换.我只需发出命令即可完成所有操作someAccountingEvent.process().

当我必须在服务层中创建和保存实体时,我不清楚如何获得一些优雅的最佳方法.我不想将我的DAO注入到我的POJO中,这会为它们添加额外的依赖关系,并可能使它们成为更重的重量对象.但是,如何在我可以注入DAO的服务层中最好地建模这样的东西？

Answer 1

您可能正在谈论所谓的“贫血领域模型”。我之前回答过有关该主题的问题，该问题指向一篇关于如何将服务注入 Hibernate 检索的模型实例的博客文章。