.Net輕量狀態機Stateless的簡單應用

  對于大部分系統中流程的變更,是十分正常的事情,小到一個狀態的切換,大到整個系統都是圍繞業務流再走,復雜點的有工作流引擎,簡單點的幾個if/else收工,但是往往有那種,心有余而力不足的,比簡單復雜,比復雜簡單,最近,對業務流程的變更這一塊一直再琢磨,沒有找到一些讓我豁然開朗的資料,本次只能是講講我的設計過程,作為反面教材去對比的,同時借鑒staleless去簡化一下日常中的設計。

 

一、常用的流程變更

  采用狀態控制數據操作,通過操作變更狀態,通過switch、if/else去區分狀態,然后依據狀態做出不同的指示,從一個大家十分熟悉,但又及其簡單的例子著手,思路更加清晰。

  對于訂單的狀態,一開始用幾種描述的方式固定下來,代碼實現中,有人喜歡枚舉,有人喜歡字符串,這都無所謂了,羅馬路條條。只是這個流程是相對固定的,與一些業務系統中,十幾個轉折或是幾十個流程節點那樣,那種貌似大多使用的都是工作流吧,存在變更,還要容易變更。

  先定義個簡單的訂單類及用到的枚舉值,這些信息應該是很熟悉且常見的。

public class Order
    {
        public Order(long orderId, string orderName, string orderNo, double price)
        {
            OrderId = orderId;
            OrderName = orderName;
            OrderNo = orderNo;
            Price = price;
            CreateDate = DateTime.Now;
            InitOrderState();
        }

        /// <summary>
        /// 訂單Id
        /// </summary>
        public long OrderId { get; set; }

        /// <summary>
        /// 訂單名稱
        /// </summary>
        public string OrderName { get; set; }

        /// <summary>
        /// 訂單編號
        /// </summary>
        public string OrderNo { get; set; }

        /// <summary>
        /// 創建日期
        /// </summary>
        public DateTime CreateDate { get; set; }

        /// <summary>
        /// 訂單價格
        /// </summary>
        public double Price { get; set; }

        /// <summary>
        /// 訂單狀態
        /// </summary>
        public OrderState OrderState { get; private set; }

        /// <summary>
        /// 初始訂單狀態
        /// </summary>
        public void InitOrderState()
        {
            OrderState = OrderState.OrderCreated;
        }

        /// <summary>
        /// 設置訂單狀態
        /// </summary>
        /// <param name="orderState"></param>
        public void SetOrderState(OrderState orderState)
        {
            OrderState = orderState;
        }
    }
Order

  對于枚舉值而言,我這貌似沒太大含義,但是有些場景下可能會用的到,暫時先搞上

/// <summary>
    /// 訂單狀態
    /// </summary>
    public enum OrderState
    {
        /// <summary>
        /// 無效
        /// </summary>
        [Description("無效")]
        OrderInvalided = 0,

        /// <summary>
        /// 已創建
        /// </summary>
        [Description("已創建")]
        OrderCreated = 3,

        /// <summary>
        /// 待支付
        /// </summary>
        [Description("待支付")]
        OrderPendingPay = 6,

        /// <summary>
        /// 待配送
        /// </summary>
        [Description("待配送")]
        OrderPendingSend = 9,

        /// <summary>
        /// 待收貨
        /// </summary>
        [Description("待收貨")]
        OrderPendingSign = 12,

        /// <summary>
        /// 待退款
        /// </summary>
        [Description("待退款")]
        OrderPendingRefund = 15,

        /// <summary>
        /// 已完成
        /// </summary>
        [Description("已完成")]
        OrderCompleted = 18,
    }
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>
        /// 退款
        /// </summary>
        Refund,
    }

   按照預先的設計并利用stateless提供的相關方法完成流程的配置,采用集中式的配置方式,并且這部分配置工作,可以再度升級到使用數據庫存儲,而采用數據庫去動態配置。

//流程配置
orderStateMachine.Configure(OrderState.OrderCreated)
    .Permit(OrderTrigger.Jump, OrderState.OrderPendingPay)
    .Permit(OrderTrigger.Cancel, OrderState.OrderInvalided);

orderStateMachine.Configure(OrderState.OrderPendingPay)
    .Permit(OrderTrigger.Payment, OrderState.OrderPendingSend)
    .Permit(OrderTrigger.Cancel, OrderState.OrderInvalided);

orderStateMachine.Configure(OrderState.OrderPendingSend)
    .Permit(OrderTrigger.Send, OrderState.OrderPendingSign)
    .Permit(OrderTrigger.Cancel, OrderState.OrderPendingRefund);

orderStateMachine.Configure(OrderState.OrderPendingSign)
    .Permit(OrderTrigger.Sign, OrderState.OrderCompleted);

orderStateMachine.Configure(OrderState.OrderPendingRefund)
    .Permit(OrderTrigger.Refund, OrderState.OrderInvalided);

  對于原有控制器部分,只需考慮一個事情,便是,訂單狀態的改變,把對訂單的所有行為,對外抽象成一個動作,更新訂單狀態,而通過參數,來區分不同的行為

public IActionResult UpdateOrderState(long id, OrderTrigger orderTrigger)
{
    var order = orderList.Where(o => o.OrderId == id).First();

    var orderManager = new OrderManager(order);
    orderManager.TriggerOrderState(orderTrigger);

    return RedirectToAction("Index");
}

  對于頁面部分,改動量不是很大,只在于更新訂單狀態所用到的方法及參數的變更,按照這個設計思路,同樣可以得到如下的變更效果。

  

  并且,如果存在一些,行為配置錯誤,而在配置過程中沒有處理,將直接報錯提示,這方便了在一些復雜場景下,純粹依靠人肉把控狀態的變更方式。同時,拿到stateless的副產物狀態圖,到viz.js或是把viz.js集成到系統中,可以看到具體的配置效果。

  

 

 至此,對于使用狀態機去簡化常用方式的設計完成了,至于深入的更復雜的方式去研究,比如配置到數據庫中,頁面上配置,充分發揮這個輕量狀態機的能力,還得花個時間去琢磨。

 

 倉庫地址:https://gitee.com/530521314/Partner.TreasureChest/tree/master/StateMachine/src

2019-10-31,望技術有成后能回來看見自己的腳步
posted @ 2019-10-31 20:06  微笑刺客D  閱讀(...)  評論(... 編輯 收藏
11选5走势图