資訊專欄INFORMATION COLUMN
摘要：讓我們先看下狀態機的概念。下面是狀態機模型中的個要素，即現態條件動作次態。因為訂單和審批公文都有很多的流程，每個流程都會產生狀態的變化，而且流程是這種業務的主軸，其他都是圍繞這個流程和狀態變化來考慮的，所以看起來蠻適合用狀態機來做。
1、背景
在我打算學習spring statemachine的時候，我幾乎看過了所有網上的中文教程，基本上都處于淺嘗輒止的階段，有幾篇講的比較深入的，都只是堆代碼，具體用在什么地方，都語焉不詳，我打算把我一路摸索的過程記錄下來，方便大家能繼續前行。
2、spring statemachine是干啥用的
spirng statemachine是干啥用的，這個其實是個問題來的，但很多的教程的問題也在這，一上來就是告訴你有這么個玩意，然后就是開始怎么安裝，怎么運行，功能有哪些，特性列起來，但就不告訴你這個東西能干啥，所以我打算在把spring statemachine跑起來之前，先說下spring statemachin能干啥。讓我們先看下狀態機的概念。
有限狀態機（英語：finite-state machine，縮寫：FSM），簡稱狀態機，是表示有限個狀態以及在這些狀態之間的轉移和動作等行為的數學模型。應用FSM模型可以幫助對象生命周期的狀態的順序以及導致狀態變化的事件進行管理。將狀態和事件控制從不同的業務Service方法的if else中抽離出來。FSM的應用范圍很廣，對于有復雜狀態流，擴展性要求比較高的場景都可以使用該模型。下面是狀態機模型中的4個要素，即現態、條件、動作、次態。
現態：是指當前所處的狀態。
條件：又稱為“事件”。當一個條件被滿足，將會觸發一個動作，或者執行一次狀態的遷移。
動作：條件滿足后執行的動作。動作執行完畢后，可以遷移到新的狀態，也可以仍舊保持原狀態。動作不是必需的，當條件滿足后，也可以不執行任何動作，直接遷移到新狀態。
次態：條件滿足后要遷往的新狀態。“次態”是相對于“現態”而言的，“次態”一旦被激活，就轉變成新的“現態”了。
這是狀態機的定義，這個我不打算多說，因為概念性的東西，諸位請自行搜索，那么在實際應用中，狀態機會應用在什么地方呢？不知道大家怎么想，我在接觸到狀態機的時候，第一時間想到的就是訂單和審批公文，這是我在工作中實際遇到的場景，所以我學習spring statemachine的主要動力也是為了能處理這兩種情況。因為訂單和審批公文都有很多的流程，每個流程都會產生狀態的變化，而且流程是這種業務的主軸，其他都是圍繞這個流程和狀態變化來考慮的，所以看起來蠻適合用狀態機來做。
那是不是一定要用狀態機來做呢，這可不一定，因為在沒有狀態機之前的訂單流程大家也能實現，這世界缺了誰都正常運轉，所以狀態機不是必須的，在可以用狀態機解決這種流程和狀態變化的場景下，為什么要用，這是另外一個問題，因為可以用和決定用之間，還有個問題，那就是用這個有啥好處呢？
3、spring statemachine的好處
在做軟件項目的時候，我們會以各種各樣的角度看一個項目，比如OOP，萬物皆對象，一個訂單就是一個對象，所謂的狀態變化，無非就是訂單這個對象的變量在不停的變化，變化的過程就是對象的方法；再比如數據庫，萬物無非CRUD的組合，訂單不過就是增刪改查，數據庫原子操作的組合罷了。這些角度對嗎？可以說都對，因為用這些角度都有人做出了項目，但有些角度對項目的理解會比較方便，有些角度就比較費勁，比如訂單，如果是訂單的生成查看，用CRUD就是很適合，因為這個角度很契合；如果是訂單和商品的關系，訂單和其他業務的關聯，OOP的角度就很適合，因為用封裝、多態的視角比較容易看清楚這類業務和他們之間的邊界，方便劃分各自的功能。而狀態機的角度，就是以狀態變化和流程運轉為角度切入看問題，所以對于流程性為主軸的項目就很適合，所以是不是用spring statemachine，衡量的標準就是，這個項目的主軸，或者場景是不是一個流程性、狀態變化為主的項目，如果是，就可以考慮用spring statemachine了。
這個問題其實還沒回答完，上面說的其實是在什么情況下用spring statemachine，但還沒回答好處在哪里。要回答這個問題，要從軟件項目的一些特質說起。上面說了，軟件項目其實有很多的辦法完成，手段很多，完成的情況也各有優劣，那怎么判斷用什么辦法好呢，我覺得答案就是看項目主要解決的問題是什么。軟件項目既不是程序員練手的工具，也不是老板用來蒙錢的門面，它是用來解決問題的，所以能清晰的表達問題，解決問題的手段就是好的技術手段，所以，如果一種技術手段很清晰的表達了軟件項目的問題和解決方法，那么這就是這個技術最大的好處，而狀態機對于流程性、狀態變化的場景，它就是一個清晰的表達方式，這就是它的好處。
這樣說可能有些朋友會不以為然，一個技術框架的好處難道不是功能強大，使用方便，性能卓越這些東西嗎。我的理解是上面說的這幾點都很重要，但都是次一級的問題，能清晰的表達問題和解決問題的，才是核心的好處。在《人月神話》的《沒有銀彈》這篇文章里面就提到過軟件特性的根本困難和次要困難，而對問題的表達和解決其實就是對需求的準確描述和實現，這就是軟件開發的根本困難，所以能夠清晰表達這個的技術框架，就是解決根本困難的好工具，項目技術選型最重要的好處考量。至于功能、性能這些，都是次要問題，雖然spirng statemachine在次要問題上也并沒有什么缺陷。
好了，廢話時間結束，下一章，我們正式開始第一個例子，運行一個demo，請大家期待，因為這個例子真的沒啥用：）
源代碼地址
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/74948.html
摘要：在實際的企業開發中，不可能所有情況都是從頭到尾的按狀態流程來，會有很多意外，比如歷史數據，故障重啟后的遺留流程，所以這種可以任意調節狀態的才是我們需要的狀態機。 1、偽持久化和中間段的狀態機我們設想一個業務場景，就比如訂單吧，我們一般的設計都會把訂單狀態存到訂單表里面，其他的業務信息也都有表保存，而狀態機的主要作用其實是規范整個訂單業務流程的狀態和事件，所以狀態機要不要保存真的不重要，...
摘要：先來一個，它的主要作用就告訴狀態機的初始狀態應該啥樣，然后把整個狀態流程都用代碼配置出來。繼承了類，表明身份，我就是來配置狀態機的初始狀態，并描繪一下狀態流程的全過程。 上一篇說了很多廢話，這一篇就不嘮叨，先跑起來 1、來個spring boot去start.spring.io新建一個springboot的項目，雖然我對spirngboot也有不少的牢騷，但作為demo的開始，還是一個...
摘要：目前為止，我們都是從狀態流程的開始階段創建一個狀態機，然后一路走下去。然后就可以愉快的在里面看怎么用了發送事件持久化恢復狀態機后的狀態為執行完保存后，大家可以自己在客戶端查看以下，是不是有內容保存進去了。 目前為止，我們都是從狀態流程的開始階段創建一個狀態機，然后一路走下去。但在實際業務中，狀態機可能需要在某個環節停留，等待其他業務的觸發，然后再繼續下面的流程。比如訂單，可能在支付環節...
摘要：創建了后，狀態機就可以不只是傳一個，可以組合和數據內容一起發送給狀態機變化的處理類了。到這里為止，狀態機通過對象就和其他的業務代碼做到了數據連接。 在企業開發中，數據在不同的業務間傳輸是最常見的工作，所以雖然我們的主架構是用的狀態機，也就是從流程狀態的角度來看待這個項目，但在具體業務中，每個狀態的轉變中會牽涉到各類業務，這些業務有些需要收到狀態機變化的通知，需要把狀態值傳遞給業務類和業...
摘要：講講復雜流程的需求除了上面文章里面提到的一根筋狀態機流程，實際的企業應用中狀態機的流程會更加復雜，而我們最常用到的就是。當然，里面還有很多其他的東西，大部分是處理復雜狀態機流程的，以后有機會我們再展開講。 1、講講復雜流程的需求除了上面文章里面提到的一根筋狀態機流程，實際的企業應用中狀態機的流程會更加復雜，而我們最常用到的就是choice。它類似于java的if語句，作為條件判斷的分支...
閱讀 2496·2021-10-19 11:45
閱讀 2489·2021-09-30 09:56
閱讀 1442·2021-09-30 09:47
閱讀 602·2019-08-30 15:53
閱讀 1841·2019-08-30 15:44
閱讀 590·2019-08-30 12:52
閱讀 1093·2019-08-30 11:16
閱讀 1617·2019-08-29 16:36
