spring statemachine的企业可用级开发指南7-伪持久化和中间段状态机

一、伪持久化和中间段的状态机

    咱们设想一个业务场景，就好比订单吧，咱们通常的设计都会把订单状态存到订单表里面，其余的业务信息也都有表保存，而状态机的主要做用实际上是规范整个订单业务流程的状态和事件，因此状态机要不要保存真的不重要，咱们只须要从订单表里面把状态取出来，知道当前是什么状态，而后伴随着业务继续流浪到下一个状态节点就行了（流浪远方，流~浪~~）。

    咱们先实现一个StateMachinePersist，由于我不想真的持久化，因此就敷衍一下，持久化是什么，啥也不干。

import org.springframework.statemachine.StateMachineContext;
import org.springframework.statemachine.StateMachinePersist;
import org.springframework.statemachine.support.DefaultStateMachineContext;
import org.springframework.stereotype.Component;

@Component
public class OrderStateMachinePersist implements StateMachinePersist<OrderStates, OrderEvents, Order> {

	@Override
	public void write(StateMachineContext<OrderStates, OrderEvents> context, Order contextObj) throws Exception {
		//这里不作任何持久化工做
	}

	@Override
	public StateMachineContext<OrderStates, OrderEvents> read(Order contextObj) throws Exception {
		StateMachineContext<OrderStates, OrderEvents> result = new DefaultStateMachineContext<OrderStates, OrderEvents>(OrderStates.valueOf(contextObj.getState()), 
				null, null, null, null, "orderMachine");
		return result;
	}
}

而后在PersistConfig里面转换成StateMachinePersister

@Configuration
public class PersistConfig {
@Autowired
    private OrderStateMachinePersist orderStateMachinePersist;
@Bean(name="orderPersister")
    public StateMachinePersister<OrderStates, OrderEvents, Order> orderPersister() {
		return new DefaultStateMachinePersister<OrderStates, OrderEvents, Order>(orderStateMachinePersist);
	}
}

如今问题来了，不持久化的持久化类是为啥呢，主要就是为了取一个任何状态节点的状态机，方便继续往下执行，请看controller

@RestController
@RequestMapping("/statemachine")
public class StateMachineController {

    @Resource(name="orderPersister")
	private StateMachinePersister<OrderStates, OrderEvents, Order> persister;
    
    @RequestMapping("/testOrderRestore")
	public void testOrderRestore(String id) throws Exception {
		StateMachine<OrderStates, OrderEvents> stateMachine = orderStateMachineBuilder.build(beanFactory);
		//订单
		Order order = new Order();
		order.setId(id);
		order.setState(OrderStates.WAITING_FOR_RECEIVE.toString());
		//恢复
		persister.restore(stateMachine, order);
		//查看恢复后状态机的状态
		System.out.println("恢复后的状态：" + stateMachine.getState().getId());
	}
}

    看到没有，用builder建了一个新的状态机，用restore过了一手，就已是一个到达order指定状态的老司机状态机了，在这里，持久化不是本意，让状态机可以随时抓换到任意状态节点才是目的。在实际的企业开发中，不可能全部状况都是从头至尾的按状态流程来，会有不少意外，好比历史数据，故障重启后的遗留流程......，因此这种能够任意调节状态的才是咱们须要的状态机。

二、废话时间

    这篇文章内容比较少，因此决定说点废话，凑点字数。从上面能够看到，状态机的自己数据其实没啥价值，有价值的业务数据好比订单其实都存库表，状态值通常也是伴随订单一块儿保存就好了。那么状态机最核心的价值在哪呢？在第一章的时候其实就讲过了，spring statemachine框架的做用在于提供一个软件项目业务切入的视角，咱们的关注点不在于具体的业务数据，而是状态流程，这个做为主线，咱们必需要清楚，可是企业开发是很复杂的，状况丛生，好比咱们一直举例的流程，都是一条直线的流程：

简单的使人发指，实际的状况显然比这个复杂，会有分支选择，会有回到上一个状态的状况。下一章咱们来弄一个复杂的状态机流程图来描述一下，试一下spring statemachine 在企业真实环境下的表现力。

源代码地址