一：事务脚本
使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求。
在客户系统和服务器系统之间的每次交互都包含一定的逻辑。在某些情况下，它可能如显示数据库中的信息
一般的简单，也有可能设计计算，验证的步骤。
事务脚本将所有的逻辑组成单个过程，在过程中直接调用数据库，或者只通过一个简单的数据库封装器。
运行机制：
事务脚本组织成类的两种方式：
1.将数个事务脚本放在一个类中，每个类围绕一个主题将相关的事务脚本组织在一起。
2.每个事务脚本对应一个类。这样就需要用Command模式。这种情况下应该定义一个所有命令的父类，
在父类中声明事务脚本逻辑适合的方法。
使用时机：
适合用于只有少量逻辑的应用程序。
（弄了半天不知道怎么插入类图）
领域模型：
不知道怎么把类图弄进来，只能文字描述了。
合同类(Contact)：
RecognizedRevenue(data);
CalculateRecognitions;
产品类（Product）:
CalculateRecognitions(Contact)
计算策略(Recognition Strategy)：
这样就合并了行为和数据的领域的对象模型。
领域模型创建了一张由互联对象组成的网，其中的每个对象都代表某个有意义的个体，可能大到一个公司或者小到一张订单。
使用领域逻辑的一个常见问题是领域对象过于臃肿。当创建一个处理订单的交互界面是，会发现订单的部分行为是该交互中特有的。
如果将这些职责都放到订单对象中，则有可能使得订单类中充满这许多只在特定用例中用到的职责，从而是的订单类过于复杂。
这个时候就该考虑哪些职责是通用的，应当放在订单类中，哪些是特殊的，应该放在针对具体使用类中，如事务脚本或表现层本身。
使用时机：
何时使用领域模型完全取决于系统中行为的复杂程度。如果业务规则复杂多变，涉及效验，计算，衍生，就应该利用对象模型进行处理。
但是如果业务只有简单的判空和少量的计算，事务脚本会是更好的选择。
实现延迟加载的四种方法：
1.延迟初始化
每次访问属性域都要先检查该域是否为空。如果为空，在返回域值之前计算出这个域值。要实现这一点，必须确保这个域是子封装的。
用NULL来标记一个还没加载的域很有效。
2.虚代理
虚代理是这样一个对象，看起来应该在域中的一个对象，但是实际上他并不包含任何东西。只有当它的一个方法被调用的时候，它才从数据库加载恰东的对象。
3.值保持值
值保持是一个用来包装某个其它对象的对象。要想获得基对象，可以访问保持器得到它的值，但是只有第一次访问值保持器的时它才真正的从数据库读取数据。
缺点：
类需要知道它的存在，而且将丧失强数据类显示性。
4.重影
重影是部分状态下是真实的对象。当从数据库加载对象时，只包含其ID.当每次要访问对象的某个域时，它就会加载其完全状态。