如何在 Hibernate 中使用面向对象编程？答案

【问题标题】：How to use object oriented programming with Hibernate?如何在 Hibernate 中使用面向对象编程？
【发布时间】：2011-07-25 20:55:46
【问题描述】：

在使用诸如 Hibernate 之类的 ORM 工具时，我发现将所有业务逻辑保留在我的业务对象之外并将其保留在服务层中是有利的。服务层创建业务对象 POJO、操作它们并使用 DAO 保存它们。但这不是从 Java 的面向对象的本质上倒退了一步吗？

我的堆栈包括用于 DI、事务和持久性的带有 Hibernate 的 Spring。我的 DAO 被注入到我的服务层，而不是任何 POJO。

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

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

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

UsageEvent:

UsageEvent 发生在抄表员记录您的用电量时
查找客户的ServiceAgreement
在此类事件和特定时间段的服务协议中可以找到适当的PostingRules。规则和费率会随时间而变化，因此任何给定类型的事件都存在多个 PostingRules。
UsageEvent 和 PostingRules 确定需要执行哪些操作，例如创建一个或多个 AccountingEntry 对象。
创建一个AccountingEntry 以使用包含在PostingRule 中的逻辑来计费。这可能像rate * usage 一样简单，但可能要复杂得多，具体取决于一天中的时间、承诺水平（大企业可能会获得折扣）、低收入家庭等。
会创建额外的AccountingEntrys 来支付税款、提供信用等。

InstallationEvent:

InstallationEvent 发生在技术人员激活建筑物的电源时。
找到服务协议和PostingRules
已创建适当的AccountingEntrys
使用的逻辑和规则与UsageEvent 中的很多不同

关键是AccountingEvents 和PostingRules 有很多不同的类型，每一个都知道针对特定情况该做什么。这些对象很容易使用接口互换。我可以通过简单地发出命令someAccountingEvent.process() 来解决所有问题。

当我必须在服务层中创建和保存实体时，我不清楚恢复这种优雅的最佳方式。我不想将我的 DAO 注入到我的 POJO 中，这会给它们添加额外的依赖项，并可能使它们变得更重的对象。但是我如何在可以注入 DAO 的服务层中最好地建模这样的东西呢？

【问题讨论】：

我已经广泛使用了hibernate和ibatis。他的书是哪一年写的，他必须处理 TB 的数据吗？

标签： java oop hibernate spring orm

【解决方案1】：

您可能在谈论所谓的“Anaemic domain model”。我之前回答了一个关于该主题的问题，该问题指向一篇关于如何将服务注入到 Hibernate 检索的模型实例的博客文章。

Spring and the Anaemic Domain Model

参考的博文是Domain Driven Design with Spring and Hibernate

【讨论】：

谢谢！我不知道该怎么称呼它，所以感谢您将我指向贫血域模型和 James Blewitt 的帖子。很棒的资源！
酷，显然我已经在工作中使用了 9 年的贫血模型，但没有意识到这一点。话又说回来，从第一天开始，我就感觉到过度使用单例模式（即用于事务类）只是回到过程编程的一个漏洞。

【解决方案2】：

有效的问题，我不知道解决方案。但是有一个想法：面向对象的设计不是目标，它是达到目的的一种手段。如果在你的架构中拥有一个贫乏的领域模型是最容易的，那么也许你应该使用它；逆着你的框架流动通常会使事情变得更加困难。也就是说，尽可能争取优雅、更面向对象的解决方案总是健康的。在这种情况下，在阅读了James Blewitt's blog 关于该主题的内容后，可能会有一些可行的新方法。

【讨论】：