对于订单的状态，一开始用几种描述的方式固定下来，代码实现中，有人喜欢枚举，有人喜欢字符串，这都无所谓了，罗马路条条。只是这个流程是相对固定的，与一些业务系统中，十几个转折或是几十个流程节点那样，那种貌似大多使用的都是工作流吧，存在变更，还要容易变更。

　　先定义个简单的订单类及用到的枚举值，这些信息应该是很熟悉且常见的。

 Order

　　对于枚举值而言，我这貌似没太大含义，但是有些场景下可能会用的到，暂时先搞上

 OrderState

　　对于买卖双方，各自应有各自的页面，但是为了操作简便，将合并在一起，重心放在流程的变更上，利用Razor语法快速突进，直接将后台数据在页面上展示出来。

　　

 　　对于各条数据，有单独的状态，按照之前状态图中的那种方式，依据每一个状态前后的变更操作，设计相应的方法，比如待配送阶段的订单，完成发货配送后，那么相应的订单变成待收货，此时需要一个完成发货的一个方法，如下，简单方式配置下，先对当前要操作的订单做个状态判定，防止某些操作，其次更改订单状态，后直接跳回订单页，方便看到数据状态的变更。

public IActionResult CompleteSend(long id) {     var order = orderList.Where(o => o.OrderId == id).First();     if (order.OrderState != OrderState.OrderPendingSend)     {         throw new Exception("状态错误");     }      order.SetOrderState(OrderState.OrderPendingSign);//待签收    return RedirectToAction("Index"); }

　　按照一系列预先规划的操作，挨个编写，最终直接运行后可以看下变更效果。

　　

　　这种方式下，就是简单，思路清晰，操作起来顺手，通过人肉编排完成任务，但是一旦流程节点增多，甚至出现了交叉变更的情形，代码中简单情形的if/else已经不能满足时，就有点头痛了。

 

二、采用Stateless简化流程

　　在采用stateless简化一下上面这个流程设计，也作为对stateless的一次掌握，看下简化后的流程设计能否带来什么意想不到的事情。stateless采用行为触发方式推动流程进行，比如说a状态要变到b状态，要经过一个行为，不管是买家点击，卖家点击，定时任务，其它行为触发后的联动触发等，都是以行为进行驱动的，

　　因此，按照刚开始那张图中设计好的一些状态变更操作，封装成行为触发的枚举。

    /// <summary>    /// 针对订单的操作     /// </summary>    public enum OrderTrigger     {         /// <summary>        /// 跳转         /// </summary>        Jump,          /// <summary>        /// 取消         /// </summary>        Cancel,          /// <summary>        /// 支付         /// </summary>        Payment,          /// <summary>        /// 配送         /// </summary>        Send,          /// <summary>        /// 签订         /// </summary>        Sign,          /// <summary>