摘要：在实际的企业开发中，不可能所有情况都是从头到尾的按状态流程来，会有很多意外，比如历史数据，故障重启后的遗留流程，所以这种可以任意调节状态的才是我们需要的状态机。
1、伪持久化和中间段的状态机
我们设想一个业务场景，就比如订单吧，我们一般的设计都会把订单状态存到订单表里面，其他的业务信息也都有表保存，而状态机的主要作用其实是规范整个订单业务流程的状态和事件，所以状态机要不要保存真的不重要，我们只需要从订单表里面把状态取出来，知道当前是什么状态，然后伴随着业务继续流浪到下一个状态节点就好了（流浪远方，流~浪~~）。
我们先实现一个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 {
@Override
public void write(StateMachineContext context, Order contextObj) throws Exception {
//这里不做任何持久化工作
}
@Override
public StateMachineContext read(Order contextObj) throws Exception {
StateMachineContext result = new DefaultStateMachineContext(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 orderPersister() {
return new DefaultStateMachinePersister(orderStateMachinePersist);
}
}
现在问题来了，不持久化的持久化类是为啥呢，主要就是为了取一个任何状态节点的状态机，方便继续往下执行，请看controller
@RestController
@RequestMapping("/statemachine")
public class StateMachineController {
@Resource(name="orderPersister")
private StateMachinePersister persister;
@RequestMapping("/testOrderRestore")
public void testOrderRestore(String id) throws Exception {
StateMachine 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指定状态的老司机状态机了，在这里，持久化不是本意，让状态机能够随时抓换到任意状态节点才是目的。在实际的企业开发中，不可能所有情况都是从头到尾的按状态流程来，会有很多意外，比如历史数据，故障重启后的遗留流程......，所以这种可以任意调节状态的才是我们需要的状态机。
2、废话时间
这篇文章内容比较少，所以决定说点废话，凑点字数。从上面可以看到，状态机的本身数据其实没啥价值，有价值的业务数据比如订单其实都存库表，状态值一般也是伴随订单一起保存就行了。那么状态机最核心的价值在哪呢？在第一章的时候其实就讲过了，spring statemachine框架的作用在于提供一个软件项目业务切入的视角，我们的关注点不在于具体的业务数据，而是状态流程，这个作为主线，我们必须要清楚，但是企业开发是很复杂的，情况丛生，比如我们一直举例的流程，都是一条直线的流程：
简单的令人发指，实际的情况显然比这个复杂，会有分支选择，会有回到上一个状态的情况。下一章我们来弄一个复杂的状态机流程图来描述一下，试一下spring statemachine 在企业真实环境下的表现力。
源代码地址
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/75269.html
