前言:企业应用架构分为三个基本组织层次:表现层、领域层、数据源层。其中领域层,又成为业务逻辑层。领域层可以分为三种主要的模式:事务脚本、领域模型、表模块。
名称的由来:在java界设计模式界,把过程式的代码,叫做脚本。因为大多数情况下,每一个数据库事务对应一段代码脚本,所以使用“事务脚本“来描述该模式。
事务脚本(Traction Script)优点是简单。对于只有少量逻辑的应用程序来说最适合。
缺点是当业务逻辑越来越复杂时,会造成事务之间的冗余代码。任何公共代码都可能存在多个副本。
谨慎提取公共子程序可以避免很多问题,但更复杂的业务逻辑则需要建立领域模型设计模式(见另一篇还没写的文章)。
虽然面向对象很强大,但也不要忽略事务脚本。简单的基于事务脚本的解决方案可以加快开发速度,而且运行速度也很快。
运行机制:
使用事务脚本时,领域逻辑主要通过系统所执行的事务来组织。这样做的好处是无需关心其他事务的内部实现。
我们要尽可能分离事务脚本,将它们放置在,与表现层和数据源层类不同的类中。把事务脚本组织成类,优点在于,允许以对象的方式来操作脚本类的实例。虽然,在采用事务脚本模式的领域层很少有这种需求,但仍然值得这么做。
组织成类的方法的第一种方法,是将数个事务脚本放在一个类中,每个类围绕一个主题将事务脚本组织在一起。
另一种方法是,一个事务脚本对应一个类。使用命令模式(通用设计模式中的Command Pattern,将来我会专门讨论这种通用设计模式),定义一个所有命令的父类,在父类中声明事务脚本逻辑的执行方法。
下一篇文章会以代码形式来继续讲解领域逻辑层次中的事务脚本模式。