本文摘抄自《.NET企业级应用架构设计》
业务逻辑层的模式的发展历史
历史上，事务脚本是第一个广泛应用的业务逻辑模式。
后来出现了基于表数据的表模块模式，仍然属于过程式模式，但是加入了一些面向对象思维。
在面向对象开发兴起之后，出现了基于对象的业务逻辑模式，最简单的对象模型就像是数据库表的数据模型，这里的对象就是数据库中的记录，并加了一些额外的方法，这种模式通常叫做活动记录模式。
随着业务逻辑的复杂性越大，软件的抽象程度越高，这时就应该从领域着眼，创建一个领域驱动的对象模型，这种模式通常叫做领域模型。
事务脚本概念
业务逻辑层是一系列过程的集合，每个集合都用来处理来自于表现层的一个请求。业务逻辑层被看做是一系列的相关的操作，系统执行的每个步骤都会被分割成更小的步骤，每个步骤都用一个操作表示，叫做事务。在这个上下文中，事务是一个不可分割的逻辑操作，但这个事务与数据库中的事务没有关系，这个模式叫做事务脚本。
我的想法
事实上，平时采用的事物脚本模式是过程式编程，真正的面向对象编程是领域模型，而我一直认为将业务逻辑分层，创建几个类就是面向对象编程，这真是一个莫大的讽刺啊。
事务脚本模式概述
事务脚本模式鼓励你放弃所有的面向对象设计，将业务组件直接映射到需要的用户操作上。该模式的关注点在于用于通过表现层所能执行的操作，并为每个操作编写一个专门的方法。这就是事务脚本。不过数据访问层通常被封装到另一些组件中，并不属于脚本的一部分。
事务脚本的优缺点
事务脚本就是一个简单的过程式模型，简单是事务脚本最值得一提的优势，对于逻辑不多，时间紧迫且依赖于强大的IDE的项目，事务脚本是其理想的选择。简单既是事务脚本的最大优势，同时也成为了它最大的劣势。事务脚本有造成代码重复的潜质，你会很容易的得到一系列完成类似任务的事务，最终应用程序变成了一团混乱的子程序组合。当然这时，重构闪亮登场。重构可以在很大程度上缓解事务脚本天生的劣势，不过重构也有其作用的范围。