企业应用架构模式之事务脚本（Transaction Script）
闻之不若见之，
见之不若知之，
知之不若行之。
01
案例图中实现行为全在 OrderServiceImpl 类中，这也就是使用事务脚本时，脚本通常位于服务类，也就是 OrderServiceImpl 类。数据对象 Order 是纯数据容器，没有任何行为。
下面我们来看一个案例，该案例是将所有关于 Order 相关的操作都在 OrderServiceImpl 中实现。
public class OrderController {
// save
public String save(){
String json = “”;
return json;
}
// settlement
public String settlement(){
String json = “”;
return json;
}
// xxx();
// xxxx();
// xxxxx();
}
接口 OrderService
public interface OrderService {
// save
public void save(Order order);
// settlement
public void settlement(Order order);
// getOrders
public List getOrders();
// xxx();
// xxxx();
// xxxxx();
}
实现 OrderServiceImpl
public class OrderServiceImpl implements OrderService{
@Override
public void save(Order order) {
// TODO Auto-generated method stub
// 实现保存相关的业务
}
@Override
public void settlement(Order order) {
// TODO Auto-generated method stub
// 实现结算相关的业务
}
@Override
public ListgetOrders() {
// TODO Auto-generated method stub
// 实现获取订单列表的业务
return new ArrayList();
}
// xxx();
// xxxx();
// xxxxx();
}
类 Order
public class Order implements java.io.Serializable{
private static final long serialVersionUID = 1L;
private int no;
private double money;
private int id;
public int getNo() {
return no;
}
public void setNo(int no) {
this.no = no;
}
public double getMoney() {
return money;
}
public void setMoney(double money) {
this.money = money;
}
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public Order(int no, double money, int id) {
super();
this.no = no;
this.money = money;
this.id = id;
}
public Order() {
super();
}
}
02
事务脚本（Transaction Script）是不是很熟悉，很简单。没错，事务脚本胜在简单。对于只有少量逻辑的应用程序来说，使用这一模式非常自然，无论在性能上还是理解上都不会带来太大的开销。
但是，当业务逻辑越来越复杂时，使用这一模式就会越来越难以保持良好的设计。它特有的问题是事务之间的冗余代码。比如，我们系统中有挂单结算与直接结算功能，通过两个接口实现该业务会发现两个方法的内部会存在很多重复性代码。
因此，使用事务脚本方式的时候会发现需要频繁的提取子程序，也就是公共方法，但在实际提取过程中仍会出现很多重复性代码，随着系统功能的增多，逻辑变得复杂，代码的维护成本则会逐渐提升。所以，事务脚本的方法在针对简单逻辑的系统是可以提升开发速度。但是，对于复杂的业务领域则需要领域模型（微服务构建系统的方式，下一篇来讲该方式）。
03
以上就是事务脚本方式，读完后自己在想一个问题，在编程系统的时候能不能把每个子系统、子模块采用该方式来进行编程。个人的想法是假如各个子系统、子模块的业务不复杂，且之间的联系较少或者说没有，可以这样操作。（个人说的也不全对，因为事务脚本的方式与领域模型两者很难给出分界点。）相反，则不建议这样操作，虽然研发速度会快。但是，仍会存在子系统、子模块不易于维护，不易于理解等等问题，后期涉及到各个子系统间通信则会更加繁琐。
那能不能先使用事务脚本后，后面再升级成领域模型呢？答案肯定是不行的，因为从面向过程到面向对象转，这个过程就很难，而且还得保证系统的可行性。因此，早期选择正确的决策使用哪种模式构建系统是最好的方法。
那听完这么多是不是在构建系统的时候都不使用事务脚本了，明明用的Java面向对象语言，还得用面向过程的方式开发，逼着自己非得要使用面向对象的方式来开发。
有一句话是“杀鸡焉用牛刀”，我们不要盲目排斥事务脚本，应具体问题具体分析，如果是一个简单的问题，事务脚本这一简单方法不仅可以帮助你提升研发速度，还可以是系统运行的很好，何乐而不为呢。相反，业务领域复杂则需考虑领域模型的方式。
-END-
一切即心，心即一切