domain logic approaches

1、domain logic approaches

Transaction Script(事务脚本模式),是一种最简单和最容易接受的处理业务的方法。这种模式是采用面向过程的方式来组织业务逻辑。通常情况下，系统的一个流程会被实现为一个方法，然后所有的方法被组织在一起，放在一个类中。

设计思想：取数据-》逻辑-》数据展示。 存数据-》逻辑-》保存数据。

优点

• 简单，对大多数开发者都可用理解

• 一个事务的处理，不会影响到其他的事务

  缺点

  业务逻辑复杂时，系统每增加一个业务流程，代码就会增加一个或几个方法，最后业务类中存在大量相似的代码（重用性不强，难以维护）

  案例

  人事管理系统中的请假流程
• 判断员工提交的数据是否合法
• 检查提交请求的员工是否还有剩余假期
• 批准假期，并记录下来

 

2、domain model

　　如果说事务脚本是 面向过程 的，那么领域模型就是 面向对象 的。面向对象的一个很重要的点就是：“把事情交给最适合的类去做”，即：“你得在一个个领域类之间跳转，才能找出他们如何交互”，Martin Flower 说这是面向对象中最难的部分，这具有误导的成份。确切地说，我们作为程序员如果已经掌握了 OOD 和 OOP 中技术手段，那么如何寻找类之间的关系，可能就成了最难的部分。但在实际的情况中，即便我们不是程序员，也总能描述一件事情（即寻求关系），所以，找 对象之间的关系 还真的并不是程序员最关系的部分，从技术层面来讲，寻找类之间的关系因为与具体的编码技巧无关，所以它现在对于程序员的我们来说，应该是最简单的部分，技术手段才是这里面的最难部分。

3、table module

　　表模块（Table Module)，它是处理某一数据库（其实只能是关系型数据库）中表与视图所有行的业务逻辑的一个实例。因为表模块其实就一个数据集合（如：ado的RecordSet,ado.net的DataSet中的DataTable或类型化DataSet等之类），它可以看成是一个数据容器，因为他用一个类(如Product)表示数据库中对应表所有数据及行为，我们知道面向对象模型与关系模型存在差异，通常一个类与一个实体在概念上相对应，也就是一个类对应一个表，一个类的实例，即对象对应表中某一行记录。类与表都是抽象的，集合的概念，像关系数据库中表就一个二维（行、列）的集合，而表模块用一个类直接表示表中所有数据及行为，所以这个类可以不需要实例化，它就相当于一个表(如.net 的DataTable)，这样所有业务操作都直接用表模块方式进行，从这一概念上来说，它也可以看成是业务逻辑的一种实现方式，其实大家肯定可以得出，这种方式在本质上还是采用事务脚本方式来实现业务逻辑，只是事务脚本方式，经常要求处理一个业务逻辑（如：查找指定ID的Product）就需要用SQL语句从数据库中获取数据，而这种方式先把数据库的所有行加载到表模块(如：DataTable)中，之后处理所有业务都直接与表模块有关(如：查找指定ID的行，CRUD之类的操作),这正是表模块与事务脚本的细微区别之后