事务脚本模式概述
事务脚本模式鼓励你放弃所有的面向对象设计，将业务组件直接映射到需要的用户操作上。该模式的关注点在于用户通过表现层所能执行的操作，并为每个操作编写一个专门的方法。这个方法就叫做一个事务脚本。

“事务”一词在这里通指一个需要执行的业务流程。“脚本”表示我们会逻辑上将一系列系统操作（即脚本）与每个用户操作关联。

1，何时使用事务脚本
事务脚本非常易于理解和解释。每个必需的用户操作都在一个物理事务中开始，直至结束。不过数据访问通常被封装在另一些组件中，并不属于脚本的一部分。

事务脚本并没有使用到面向对象设计的概念。通过事务脚本给出的模型中的逻辑均是使用IF、WHILE和FOR等语言元素表述的。向现有用户操作中添加新功能就意味着添加一个新分支或在现有代码中的某处添加一个新的子程序。

事务脚本适合应用于那些业务逻辑非常简明直白，且最好不大可能改变的简单场景中。

对于基于现有后台的Web门户来说，事务脚本是个非常不错的选择。这样，页面中的交互元素即可触发一个服务操作。每个服务器操作都会进行一些数据验证，执行一些简单计算，随后将数据转发给后台系统。

其实，对于此类简单需求，甚至没有必要花费时间在准备领域模型上。

2，事务脚本的优势
事务脚本是一个简单的过程式模型，它以逻辑事务集合的形式来表现应用程序的逻辑。简单是事务脚本最值得一提的优势，它没有开始时的额外代价，且可以和快速应用程序开发环境良好的配合。

对于逻辑不多，时间紧迫且依赖于强大的集成开发环境的项目，事务脚本是其理想的选择。

使用过程式方法并不意味着需要编写大段，不可拆分的代码。一个高层次的事务可以被拆分成更简单，可重用的子程序或层。最常见的一个层就是持久层，其中你会发现一些小的，用来处理数据访问以及相关杂务的组件。此类层能够提供某程度的重用性。

3，事务脚本的劣优
简单即是事务脚本的最大优势，同时也成为了它最大的劣势。实现事务脚本模式非常简单，只要创建一个或几个容器类，并暴露出逻辑相关的方法即可。每个方法都实现一个特定的事务脚本，并可能与一些辅助数据对象交互，以便执行数据验证，数据重组，计算，物理数据访问等各种操作。

注意到除了潜意识中的常识之外，没有其他的东西阻止你将数据访问代码在内的所有操作统统塞到一个脚本中。类似地，需要依赖常识对脚本进行分组。

通常来讲，事务脚本有造成代码重复的潜质。你会很容易得到一系列完成类似任务的事务，最终的应用程序变成了一团混乱的子程序组合。即便不是意大利面条代码，也不会变的太漂亮，类似通心粉代码。代码看起来仍旧乱成一团，不过至少还能在其中到一些有条理的部分。

代码重复和意大利面代码可以通过抽取类似代码方法来重构，这也正是重构中经常执行的任务。重构可以在很大程度上缓解事务脚本天生的劣势，不过重构也有基作用范围.

随着需求的不断增长，你会发现代码越来越难以重构。原因有两个，首先，你已经落后于进度表，因此不会花时间去完成那些已经做过的事情，即使它意味着更好的代码。第二，即使你能有规律重构代码，随着业务逻辑的增长，重构所花费的时间也会越来越长。

这样恶性循环下去，修改乱成一团的子程序从测试角度来会成为高风险的事情。不要忘记软件回归测试。你可能会发现某个新功能使软件无法正常工作，或是大大降低了执行效率。你有很多问题需要修复，因此若没有足够完善的回归测试，那么绝不可能实现修复。