3.2.2透明与自动持久化

你的应用服务器的CMP引擎实现了自动的持久化。它负责管理单调的JDBC Resultset和PreparedStatement。当然，Hibernate也能完成这样的功能，并且它可以做的更多。但是Hibernate通过透明的持久化完成了这些功能。 我们使用透明来表示业务模型和持久化逻辑的完全隔离。 我们的Item类，在代码级别和Hibernate API是完全隔离的。并且： 你的持久化类不需要继承或者实现任何Hibernate的基类或者接口，也不需要任何特别的类是实现属性和联系。因此，透明的持久化会提高代码的可读性，关于这一点你很快就会看到。 持久化类可以在持久化环境外被重用，例如，你可以在单元测试或者用户UI中使用它们。可测试性也是胖领域模型的一个基本要求。 在透明持久化的系统中，对象并不关心底层的数据存储，它们甚至不需要知道自己被持久化了。持久化由一些负责持久化的接口来完成----在hibernate中，使用Session和Query接口。 透明的持久化在一定程度上提供了可携带性：由于不需要使用特殊的接口，持久化类在一定程度上减弱了和持久方案的依赖。我们的业务逻辑可以在其他的应用环境中得到重用。我们也可以很轻松的采用其他的透明持久化机制。 通过这样的透明持久层的定义，你可以看出这些特定的持久层是透明的，因为它减弱了持久层代码对于特定抽象接口的依赖。暴露给业务逻辑的只是普通的Java类。而一些自动化持久层并不是透明持久化，因为它们依赖了特定的接口或者编程模型。 我们认为透明性应该是必须的。事实上，透明持久化应该是ORM解决方案的最主要目标。然而，非自动持久化层都是透明的，而自动持久化当然也包括hibernate，在持久化类上强行加入了一些需求。 现在你应该理解为什么持久化机制或多或少影响你的领域模型，同时透明和自动化也是必要的需求。EJB并不是透明的，我们还需要使用这种机制么？我们是否需要一种特殊的编程模型？从理论上来说，不。从实践上说，你需要采用那些已经被广泛接受的编程模型。我们将在下面来讨论这样的编程模型以及其在Hibernate中的使用。