业务逻辑架构模式(事务脚本，表模块，活动记录，领域模型)
其实各种架构模式并不是凭空出现的，是你写代码到达一定功底的时候自然出现的结果。走的弯路多了，就会主动去思考该如何将代码组织的更好，更符合业务需求与架构标准。
Fowler的《企业应用架构模式》 (Patterns of Enterprise Application Architecture)就是这样一本书，里面详细叙述了企业级开发中常用的架构模式。对于业务逻辑层，常见的有四种：
注：
1.我在这里画了两层：UI与BL，其实如果更极端一些，事务脚本的CRUD，表模式的XXXManage与活动记录的XXXHandler与UI层是可以合并的。
2.表模式的XXXManage与活动记录的XXXHandler是同意词，两种不同的表达方式而以。
先来看事务脚本，这是一种最面向过程的组织方式，上层UI需要什么操作，下层就对应的写出处理方式。一个方式从UI直接操作到DB，好处是上手快，方便书写，坏处嘛，复用性不够，针对复杂逻辑适应性极差
再来看表模式与活动记录。这其实是两种换汤不换药的方式。比事务脚本进步的方面在于将数据库的表对象单独独立了出来，一个类对应一张数据库表。独立的方式有所区别：表模式是一个DataTable对应一张表， 然后附上其CRUD，活动记录是一个Model实体类对应一张数据库表，然后附上其CRUD。这种方式对于单表操作，简单业务逻辑可能比较方便，但涉及到复杂业务，多表关联的时候，由于单表对应的类处理不了，多数情况下仍然需要重新建立一个类，其命名类似于XXXManage,XXXHandler的方式，来专门处理这类复杂逻辑，多表操作的问题，其方法一般与UML的用例相关。一旦业务足够复杂，项目规模足够大，这种方式仍然会引发复用性不够，针对复杂逻辑适应性极差等问题。
以上三种方式有个相同点，就是始终以数据为中心。数据库的表结构，在程序逻辑中占有非常重要的位置，业务逻辑的处理，始终围绕着处理表数据来展开，业务代码编写人员，始终要比较明白数据库的设计方式。 一个类的状态部分(属性)与行为部分(方法)始终分离，还谈不上真正的面向对象编程。
最后来看领域模型，这种方式是解决大业务量，复杂逻辑的解决方式。在这里完全抛弃首先建库的思想，紧紧围绕客户需求来进行分析，提炼业务主体，明确交互方式，构建出一个个有血有肉的对象。最后按照客户需求或程序需要将数据或状态保存到数据库中。
有个比较形象的比喻：在面向过程的处理当中，程序员就是上帝，你掌管理一切的生老病死，从页面的展示到业务的处理到数据的存储。在对向对象的处理当中，你只是调度者，你只负责在合适的时间用合适的对象去处理合适的业务。
