J2EE集成层模式--业务领域存储
问题：

    需要将持久化逻辑从对象模型中分离出去。

    很多系统都拥有复杂的对象模型，他们需要复杂的持久化策略。由于EJB2容器管理的持久化CMP增加了容器管理关联CMR的特性，用CMP作为复杂对象模型的持久化策略具有更高的可行性。但是有些开发者不使用entity bean，甚至直接在web容器运行应用程序，他们更细化将持久化逻辑从对象模型中分离出来。

    用业务对象模式实现的对象模型可以使用继承，并且可以拥有多层的依赖关系。“透明持久化”的概念极富吸引力，随着对象模型在J2EE应用程序中的地位日益显要，这个概念也变得很流行。如果决定不用entity bean来实现持久化对象模型，就必须选择一种持久化策略。

约束：

     --需要避免在业务对象中放入持久化细节

   --不想使用entity bean

   --应用系统可能需要在web 容器上运行

   --对象模型使用了继承，或者具有复杂的关联

解决方案：

    使用业务领域存储模式实现透明于对象模型的持久化。与J2EE提供的容器管理持久化和bean 管理持久化（将持久化代码放在对象模型中）不同,业务领域存储的持久化机制是与对象模型分离的。

设计手记：EJB持久化  VS  透明持久化

使用entity bean作为持久化机制和透明持久化机制，两者之间有一个关键的区别：entity bean 给对象模型增加了限制，譬如不能继承、需要对ejb编程以支持持久化。透明持久化则保证持久化代码独立于对象模型之外，因此减少了对后者的局限。

   可以用两张方式实现业务领域存储：自己编写一个持久化框架，或者使用现成的持久化产品。持久化产品通常会基于JAVA数据对象JDO规范或者某种专有的OR映射解决方案。

   在实现业务领域存储之前，

效果：

--创建自己的持久化框架是一件复杂的工作

实现业务领域存储模式和透明持久化所需的所有特性并非易事，这不仅是因为持久化问题本身的复杂性，更因为本模式框架诸多参与者之间存在复杂的交互。因此除非其余所有选择尽皆不可行，否则不应该考虑自己来实现OR框架。

--多层对象树的加载和存储需要优化技术

--业务对象可能存在及其复杂的多层体系和关联。在对彼此相关的业务对象进行持久化操作时，可能只想持久化多层体系中被修改了的那些对象。同样，在加载业务对象多层体系中时，也会希望提供各种级别的懒加载方案：一开始只加载其中最常见的部分，在确实需要时在加载其余的部分。

--增进对持久化框架的理解

如果使用第三方持久化框架，对业务领域存储模式的理解将极大的帮助理解该框架。对比业务领域存储模式的介绍，可以很快理解该框架的是如何实现透明持久化的。

--小规模的对象模型可能不需要完整的持久化框架

如果对象模型非常的小，并且只需要对其进行简单的持久化操作，使用基于业务领域存储模式的持久化框架就有点大材小用。在这种情况下，一个基于数据访问对象模式的简单框架就足够了。

--提高可持久化对象模型的可测试性

业务领域存储将持久化逻辑与持久性的业务对象相分离，从而极大的提升了系统的可测试性，因为在测试对象模型时不必使用真是的持久化机制。由于持久化机制是透明的，可以在完成对业务对象模型和业务逻辑模型的测试之后在切换到真实的持久化机制。

--分离业务对象模型和持久化逻辑

业务领域存储模式提供了透明的持久化机制，因此业务对象不必包含任何与持久化操作相关的代码。这样，开发者就不必分心实现业务对象中错综复杂的持久化逻辑。