1.transaction script（事务脚本）
概述：
很多企业应用可以看成一系列的事务，每一个事务可以通过使用一个Transaction Script来处理。
用法：
使用Transaction Script，我们可以专注于处理好每一个事务，而不必考虑其他事务的影响，所作的就是得到输入，查询数据库，处理事务，保存结果。 Transaction Script可以有两种方法组织成类。一种是将同一领域的几个Transaction Script放在一个独立的类中；另一种是采用Command模式，将每一个Transaction Script组织成一个Command基类的子类；当然，也可以不要组织成类，而使用全局函数的方式，但是类的方式更易于隔离数据。
适用情况：
Transaction Script最大的优点和缺点，都是在于它的简单性。优点是代码的简单易懂，运行效率也不错；缺点是很可能出现代码重复，当然这个可以通过重构来减轻，更重要的是，随着企业事务复杂性的增加，Transaction Script就会变得力不从心。 Transaction Script下的开发有以下特征：对象类只包括数据，不包括任何事务相关的算法，往往就是数据库中表结构的类化；调用的Sql语句常常在Transaction Script核心函数中出现，当然这个是不好的设计，应该使用比如Table Data GateWay等模式，将Sql语句封装在wrapper中，来进行数据库交互，而核心函数直接访问wrapper的方法来进行事务处理。
2.domain model（域模型）
概述：
域模型是抽象系统，描述知识，影响或活动领域的选定方面（域[3]）。然后，该模型可用于解决与该域相关的问题。域模型表示与需要在软件中建模的域相关的有意义的现实世界概念。这些概念包括业务中涉及的数据以及业务与该数据相关的规则。
域模型通常使用域的词汇表，从而允许将模型的表示传达给非技术利益相关者。它不应该指任何技术实现，例如正在设计的数据库或软件组件。
用法：
域模型通常被实现为层内的对象模型，该层使用较低层的层来持久化并且将API“发布”到更高层的层以获得对模型的数据和行为的访问。
3.table module（）
概述：
Table Module是处理一个数据表或者数据视图所有行的业务逻辑的一个单独的实例。 一般的，Domain Model等传统面向对象模式都建立在对象/身份的基础之上，就是说比如一个员工类的实例就对应着一个特定的员工，这样我们可以执行员工操作，获取员工信息等。这些模式的不好之处在于很难和关系数据库形成好的接口，导致我们要作大量工作用于处理数据在业务层和数据库这两个表现完全不同的层次之间的传递。 Table Module则不然，它对于数据库中的每个表建立一个类的实例，用来操作该表中的数据。
用法：
Table Module模式使得我们可以打包数据和它们的行为，并同数据库保持很好的联系。它常常作为面向表的后台数据结构，而表状的数据一般的是Sql语句调用的RecordSet返回值。 Table Module即可以使类的单独实例，也可以是类的一组静态函数。采用实例的方式给我们更大的好处，便于通过一个存在的RecordSet来初始化，也很容易的通过继承等方式进行扩展。 Table Module模式可以通过厂模式来实现请求，另外的方法是通过Table Data Gateway，不好的是引入了Table Data Gateway类和机制，好的方面是我们可以只使用一个Table Module了，对于不同的数据源，采用不同的Table Data Gateway就可以了 Table Module使用方法是：首先通过Table Data Gateway把数据装成RecordSet，然后以其为参数创建Table Module，通过Table Module来处理业务逻辑，并把修改的结果传回数据库。中间的过程中，RecordSet数据一直在内存中，而不必返回数据库。 当然Table Module并不局限于表，表/视图/Sql查询结果等都可以应用此模式
适用情况：
Table Module基于面向表的数据，而且它一定是把数据结构放在整个代码的中心。面对一个复杂的业务逻辑，它不能提供足够的实例-to-实例的能力，在处理多态上也存在不足，这时我们还是应该采用Domain Model，Domain Model+Active Record也可以处理表状的数据。 Table Module在COM应用中比较常见，这是因为微软的ADO库提供了一个很好的机制，使用RecordSet来处理数据库的数据。