浅谈事务脚本

请大家访问我的独立博客http://yanyaner.com/

 

你也许听说过现在的web项目开发，在业务层几乎都是采用事务脚本来组织、暴露业务逻辑，那么，大家为什么都喜欢这么做呢？下面说说我的一些肤浅认识。

有 人说所有的管理类型项目归根结底都是CRUD操作，仔细想想也确实如此，但再深入思考一下，既然是数据库的CRUD操作来实现业务，那么一定会出现数据库 事务，由于大多数业务操作并不是由一两条简单的sql操作完成，一次业务操作中的N多条sql操作应该是一个元子性操作，要么全部成功，要么失败，这样才 是一个完整的业务。何谓事务脚本（应该是MF先提出来的，大家可以去看看企业应用架构模式一书中相关章节），事务指的是完成一次业务操作的数据库事务，脚 本指的是数据库sql脚本，也就是以过程化的方式实现业务逻辑，并完成业务状态数据的持久化（图懒得去画了，顺手截了张pojo in action 中的事务脚本示例图）。

 

 

 

 

 

 

 

 

 

 

我 们可以看到，上图中域对象的行为已经没有了，所有的行为抽取出来放到了业务层中，用一个一个的事务脚本方法来实现业务逻辑封装，在实现过程中一般采用过程 化的实现代码；领域对象中的行为抽取出来后，域对象中就仅剩下状态信息，成为了所谓的哑数据对象（失血对象，这样的对象比较安全，可以各层间通传）。很多 刚学完OO思想的人就会有疑问，不是提倡面向对象的方式来开发，而在事务脚本模式中怎么又使用过程式的方式来实现业务逻辑呢？原因如下：

a、由于原来的领域对象中没有了对象职责，这样就避免了为正确分配职责而苦恼的过程（你是否还记得OOAD中为了正确分配职责而画的时序图），使得设计过程变得简单。

b、事务脚本对象一般以用例或模块从逻辑上来确定粒度，而事务脚本方法将直接依据界面原型进行设计，是个人都会做这件事（老大说的哈），设计难度降低，设计过程简单（几种常见界面原型的事务脚本方式设计我会在其它文章中单独讲解）。

c、减少了领域对象之间的职责交互，使系统变得简单，调用者只和业务层对象交互就可实现界面逻辑（这点应该是符合迪米特法则的，和门面模式有共通之处）。

正是由于这些原因，使得系统开发对从业人员的门槛大大降低，也就间接降低了项目开发的风险，项目后期的可维护性也得到了一定的增强，这也就是你所看到了现状：95%以上的web项目开发采用事务脚本模式的原因。

最后说一点，任何事物都有两面性，以事务脚本方式实现业务逻辑也有显示的不足之处，那就是实现复杂的业务逻辑会使代码的可读性降低，不利于后期维护，当然，我们可以采用合理抽取子方法或采用贫血领域对象的方式来降低事务脚本带来的负面影响。

事务脚本在项目实现中，我们一般会用采用AOP方式，把事务管理代码动态注入到业务方法的前后，使得程序员把主要精力用在核心业务逻辑实现上，这样就会提高项目的开发效率，这也是我认为spring最有用处的一个地方之一。

 

 

pojo in action有事务脚本的代码实例与讲解，这本书的第二章也进行了全面的总结，这一章节是这本书的精华所在，建议有兴趣的去读一下，以前csdn上有这个 章节的试读版，很可惜现在已经找不到了，这本书值得初、中级水平者买一本仔细阅读，书中的代码实例有利于理解一些抽象的架构概念。

本文首发http://yanyaner.com/【刘江华的博客】，转载请保留。