企业架构模式笔记--第九章(领域逻辑模式)

一：事务脚本
使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求。
在客户系统和服务器系统之间的每次交互都包含一定的逻辑。在某些情况下，它可能如显示数据库中的信息
一般的简单，也有可能设计计算，验证的步骤。
事务脚本将所有的逻辑组成单个过程，在过程中直接调用数据库，或者只通过一个简单的数据库封装器。

运行机制：

事务脚本组织成类的两种方式：

1.将数个事务脚本放在一个类中，每个类围绕一个主题将相关的事务脚本组织在一起。

2.每个事务脚本对应一个类。这样就需要用Command模式。这种情况下应该定义一个所有命令的父类，

在父类中声明事务脚本逻辑适合的方法。

使用时机：

适合用于只有少量逻辑的应用程序。

（弄了半天不知道怎么插入类图）

领域模型：

不知道怎么把类图弄进来，只能文字描述了。

合同类(Contact)：

RecognizedRevenue(data);

CalculateRecognitions;

产品类（Product）:

CalculateRecognitions(Contact)

计算策略(Recognition Strategy)：

这样就合并了行为和数据的领域的对象模型。

领域模型创建了一张由互联对象组成的网，其中的每个对象都代表某个有意义的个体，可能大到一个公司或者小到一张订单。

使用领域逻辑的一个常见问题是领域对象过于臃肿。当创建一个处理订单的交互界面是，会发现订单的部分行为是该交互中特有的。

如果将这些职责都放到订单对象中，则有可能使得订单类中充满这许多只在特定用例中用到的职责，从而是的订单类过于复杂。

这个时候就该考虑哪些职责是通用的，应当放在订单类中，哪些是特殊的，应该放在针对具体使用类中，如事务脚本或表现层本身。

使用时机：

何时使用领域模型完全取决于系统中行为的复杂程度。如果业务规则复杂多变，涉及效验，计算，衍生，就应该利用对象模型进行处理。

但是如果业务只有简单的判空和少量的计算，事务脚本会是更好的选择。

实现延迟加载的四种方法：

1.延迟初始化

每次访问属性域都要先检查该域是否为空。如果为空，在返回域值之前计算出这个域值。要实现这一点，必须确保这个域是子封装的。

用NULL来标记一个还没加载的域很有效。

2.虚代理

虚代理是这样一个对象，看起来应该在域中的一个对象，但是实际上他并不包含任何东西。只有当它的一个方法被调用的时候，它才从数据库加载恰东的对象。

3.值保持值

值保持是一个用来包装某个其它对象的对象。要想获得基对象，可以访问保持器得到它的值，但是只有第一次访问值保持器的时它才真正的从数据库读取数据。

缺点：

类需要知道它的存在，而且将丧失强数据类显示性。

4.重影

重影是部分状态下是真实的对象。当从数据库加载对象时，只包含其ID.当每次要访问对象的某个域时，它就会加载其完全状态。