事务脚本
事务脚本比较好理解，简单来说，就是将大多是事务，以过程的形式封装起来，然后在其他层（表现层）被调用，实现一定功能（输入、查询、更新数据库）。组织事务脚本需要通过合理的方法将其模块化，例如对于数据库连接等操作，可以独立出来，成为公用的过程。
事务脚本可以通过一定的方法组织成类。事务脚本的优势在于简单有效。例如，对于一个留言本，使用Add、GetDetail等方法即可封装数据库操作，Web界面则直接调用其即可。

将数个事务脚本放在一个类中，每个类围绕一个主题将相关的事务脚本组织在一起。(最常用)每一个事务脚本对应一个类，此时需使用命令(Command)模式。

使用时机

　　事务脚本胜在简单。对于只有少量逻辑的应用程序来说，使用这一模式非常自然，无论在性能上还是理解上都不会带来太大开销。

　　当业务逻辑越来越复杂时，该模式就会越来越难以保持良好的设计。它特有的问题是事务之间的冗余代码。

领域模型
领域模型是一张对象（数据、业务规则、实体等）连接成的网。
对于简单领域模型，一般来说，一个数据库表对应一个对象；复杂领域模型则由很多细粒度对象组成，通过继承、策略和其他设计模式，模拟复杂的领域逻辑。复杂领域模型需要使用数据映射器。

合并了行为和数据的领域的对象模型。在应用程序中使用领域模型需要建立一个完整的由对象组成的层，来对目标业务领域建模。 你会发现其中有的对象模拟业务活动中的数据，有的对象捕捉业务使用的规则。数据和处理一般整合在一起，从而使得数据和数据之上的操作紧密聚合。

　　面向对象的领域模型通常看起来与数据库模型类似，但仍有许多不同之处。领域模型混合数据和处理过程，拥有多值和复杂的的关联网，并且使用继承。

　　领域模型衍生出两种风格。简单领域模型看起来与数据库设计很类似，这种设计中几乎每一个数据库表都与一个领域对象对应。而复杂领域模型则与数据库 设计不同，它使用继承、策略和其他设计模式，是一张由互联的细粒度对象组成的复杂网络，复杂的领域模型更适合于复杂的逻辑，但它于数据库的映射比较 困难。

使用时机

　　何时使用这一模型完全取决于系统中的行为复杂程度。如果你的业务规则复杂多变，涉及检验、计算、衍生，你就应该利用对象模型进行处理， 反之，如果你只有一些简单的判空值和少量的求和计算，事务脚本是一个更佳的选择。

　　影响选择的因素之一是开发小组灵活运用领域对象的程度。学会如何使用领域模型是极为重要的，故而出现了许多”理论体系迁移?方面的文章，它们都是关于 对象使用的。要熟悉领域模型需要实践和训练，但是一旦掌握了它，我发现处理解决最简单的问题外，很少会有人再使用事务脚本。

　　使用领域模型时，你可能会考虑设立一个服务层，以便给领域模型一个更清晰的API。

表模块
表模块可以简单看作通过一系列的类来模拟业务，但操作的对象是封装了的一个数据集（所谓实体对象），前一点和领域模型相同，后者则简化了与数据库的连接，不需要数据映射器。因此，表模块一般是对于数据库的一个表使用一个表模块。

使用时机

　　最常使用这一模式的场合是在Microsoft的COM设计方案中。在COM(及.net)中，记录集是应用程序的主要数据仓库。ADO 库提供了良好的机制，可供你以记录集的方式来 存取关系数据库中的数据。