最近以来的困惑—业务逻辑层的架构设计
上次写过一篇文章《是什么阻碍了我对OO的运用！》，对自己在工作中没有运用oo去思考胡言乱语的几句。最近还是一直在困惑。昨天看了几篇博客才解除困惑。
首先明白了软件架构中是分为几种类型的。而这几种类型的分类主要是针对业务逻辑层的设计方式不同而进行区分（暂不思考优缺点）：
1.Transction Script： 将业务理解成一个个过程，每个过程实现一个功能，具体到程序中就是一个业务过程对应着一个方法。可以看出这种是一个纯粹面向业务过程的设计方法。 采用这种设计方法可以由数据访问层也可以没有数据访问层。有数据访问层的就是petshop的那种经典的三层加一个Model用于各层之间的数据传递。如果没有Dal层，则可以直接在业务逻辑层中嵌套SQL语句或者存储过程。
2.Table Module：也叫表模块模式，表模块就是就是将数据库中的某个表上的所有可能的操作都写在一个类文件中，这个类文件中定义了该数据库表对应的所有的业务方法。表模块类是一个容器，它内部包含了类的数据信息和相应的行为。表模块是映射数据库表的关系，因此表模块对应的是数据集合，那么无法将数据库表中的某个行记录进行区分，只能通过集合中的键或者索引来访问行记录的信息。简单的说就是这时的类有两中特征：1.包含着其对应表的所有操作的业务方法，2.其并没有实现类的属性字段和数据库的表字段的一样映射，而是包含着一个对应着整个数据表的字段，如一个datatable。
3.Active Record: Active Record（以下简称AR）是一种面向对象的业务逻辑组织方式。AR适用于在业务较简单的情况下，应用面向对象思想进行设计。它的基本思想就是将领域中每个实体抽象出一个业务类（BO），然后，将这个实体的数据和行为封装成类的属性和方法。特别的，将CRUD功能也封装进BO中。也就是说，AR中的BO同时具备业务方法和持久化功能。其本身具有ORM的特性，其内部要处理关系实体间的关联问题。
第二，DM的组织内部对象多，关系复杂，而这种关系不再只是那种简单的一对一、一对多的关系，而是领域中的各种依赖和关联的抽象，关系类型多，非常复杂。
第三，DM需要业务部分“持久化无知”。所谓持久化无知，指业务部分只需执行业务功能，而不必关系持久化。在使用DM时，必须设计一套ORM机制（注意这里用到了“机制”一词，而不是“框架”或“库”），使得在业务系统运行时，自动在必要的时候执行数据持久化操作。
第四，DM往往需要Services Layer的配合。因为DM内部仅有一个个业务对象，它们互相调用，并没有提供一个友好的接口与UI交互，所以在使用DM时，往往在其上对各种UI需要的服务进行封装（回顾一下Facade模式），形成一个Services Layer，以方便与UI交互。
总结：直到现在为止，自己碰到的是第一种类型的设计理念，即Transaction Script。这种本来就是面向过程的设计，在这里面纠结着进行oo设计显然不是合理的。当然也不是在这种设计理念下就不能进行某些oo的运用。
本文参考：http://www.cnblogs.com/leoo2sk/archive/2009/10/31/1593740.html
http://www.cnblogs.com/hegezhou_hot/archive/2010/10/01/1840642.html
