国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

spring statemachine的企業可用級開發指南8-復雜狀態機的實現

jzzlee / 1310人閱讀

摘要:講講復雜流程的需求除了上面文章里面提到的一根筋狀態機流程,實際的企業應用中狀態機的流程會更加復雜,而我們最常用到的就是。當然,里面還有很多其他的東西,大部分是處理復雜狀態機流程的,以后有機會我們再展開講。

1、講講復雜流程的需求
除了上面文章里面提到的一根筋狀態機流程,實際的企業應用中狀態機的流程會更加復雜,而我們最常用到的就是choice。它類似于java的if語句,作為條件判斷的分支而存在,讓我們先看一張圖:

這張圖表現的是一個表單(form)的整個狀態流程:

創建初始的空白表單( BLANK_FORM)
填寫(WRITE)表單,成為填充完表單(FULL_FORM)
檢查(CHEKC)表單
如果是表單名(formName)不為null,表單成為待提交表單(CONFIRM_FROM)
提交(SUBMIT)表單,成為成功提交表單(SUCCESS_FORM)

檢查(CHECK)表單
如果表單名為null,表單成為待處理表單(DEAL_FORM),修改formName
處理(DEAL)表單
如果表單名還是null或者里面有個“壞”字,表單狀態變成廢單(FAILED_FORM)
如果表單名稱沒問題,表單狀態變成填充完表單狀態(FULL_FORM),重新走流程

大家不要在意這個例子的幼稚,畢竟它還是能用簡單的方式體現出流程的復雜性(這話多么的辯證統一)。它有判斷分支(還有兩個),還有流程的循環,還有分支判斷后的直接失敗和分支判斷后的后續環節,后面我們會在代碼中告訴大家這里面需要注意的東西。

2、代碼實現
先上狀態機的四件套:States,Events,Builder和EventConfig(spring statemachine還是蠻簡單的,來來回回就這幾樣東西)

public enum ComplexFormStates {

BLANK_FORM, // 空白表單
FULL_FORM, // 填寫完表單
CHECK_CHOICE,//表單校驗判斷
DEAL_CHOICE,//表單處理校驗
DEAL_FORM,//待處理表單
CONFIRM_FORM, // 校驗完表單
SUCCESS_FORM,// 成功表單
FAILED_FORM//失敗表單

}
注意一點,choice判斷分支本身也是一種狀態,要聲明出來,這里是CHECK_CHOICE和DEAL_CHOICE

public enum ComplexFormEvents {

WRITE, // 填寫
CHECK,//校驗
DEAL,//處理
SUBMIT // 提交

}
同樣的分支事件也要聲明,這里是CHECK和DEAL。

大頭是MachineBuilder,這個代碼就比較多,大家最好對照著上面這張圖來看,會比較清晰

/**

復雜訂單狀態機構建器

*/
@Component
public class ComplexFormStateMachineBuilder {

private final static String MACHINEID = "complexFormMachine";

 /**
  * 構建狀態機
  * 
 * @param beanFactory
 * @return
 * @throws Exception
 */
public StateMachine build(BeanFactory beanFactory) throws Exception {
     StateMachineBuilder.Builder builder = StateMachineBuilder.builder();
     
     System.out.println("構建復雜表單狀態機");
     
     builder.configureConfiguration()
             .withConfiguration()
             .machineId(MACHINEID)
             .beanFactory(beanFactory);
     
     builder.configureStates()
                 .withStates()
                 .initial(ComplexFormStates.BLANK_FORM)
                 .choice(ComplexFormStates.CHECK_CHOICE)
                 .choice(ComplexFormStates.DEAL_CHOICE)
                 .states(EnumSet.allOf(ComplexFormStates.class));
                 
     builder.configureTransitions()
                .withExternal()
                    .source(ComplexFormStates.BLANK_FORM).target(ComplexFormStates.FULL_FORM)
                    .event(ComplexFormEvents.WRITE)
                    .and()
                .withExternal()
                    .source(ComplexFormStates.FULL_FORM).target(ComplexFormStates.CHECK_CHOICE)
                    .event(ComplexFormEvents.CHECK)
                    .and()
                .withChoice()
                    .source(ComplexFormStates.CHECK_CHOICE)
                    .first(ComplexFormStates.CONFIRM_FORM, new ComplexFormCheckChoiceGuard())
                    .last(ComplexFormStates.DEAL_FORM)
                    .and()
                .withExternal()
                    .source(ComplexFormStates.CONFIRM_FORM).target(ComplexFormStates.SUCCESS_FORM)
                    .event(ComplexFormEvents.SUBMIT)
                    .and()
                .withExternal()
                    .source(ComplexFormStates.DEAL_FORM).target(ComplexFormStates.DEAL_CHOICE)
                    .event(ComplexFormEvents.DEAL)
                    .and()
                .withChoice()
                    .source(ComplexFormStates.DEAL_CHOICE)
                    .first(ComplexFormStates.FULL_FORM, new ComplexFormDealChoiceGuard())
                    .last(ComplexFormStates.FAILED_FORM);
     return builder.build();
 }

}
這里面出現了幾個新東西,要說一下:

在configureStates時,要把每個分支都要寫上去,我之前寫了ComplexFormStates.CHECK_CHOICE,忘了寫DEAL_CHOICE,后面的choice就不執行,搞得我找了很久,大家要注意(是的,我犯的就是這種簡單弱智的錯誤,我還找了很久)
在我們熟悉的withExternal之后,我們迎來了為choice專門準備的withChoice()和跟隨它的first(),last()。這兩個代表的就是分支判斷時TRUE和FALSE的狀態流程去處,這里面涉及到的一個問題就是,TRUE和FALSE的判斷條件是什么呢,根據啥來判斷呢?
Guard就承擔了這個判斷的功能,看名字似乎不像。它在spring statemachine本來是用來保護這個狀態跳轉過程的,所以用guard,但在choice里面,它就是作為判斷代碼而存在的,代碼如下:
public class ComplexFormCheckChoiceGuard implements Guard {

@Override
public boolean evaluate(StateContext context) {
    boolean returnValue = false;
    Form form = context.getMessage().getHeaders().get("form", Form.class);
    if (form.formName == null) {
        returnValue = false;
    } else {
        returnValue = true;
    }
    return returnValue;
}

}
它只implements一個方法evaluate(),返回boolean類型,所以很適合做這個判斷的功能。另外一個DEAL_CHOICE的gurad代碼是這樣的

public class ComplexFormDealChoiceGuard implements Guard {

@Override
public boolean evaluate(StateContext context) {
    System.out.println("ComplexFormDealChoiceGuard!!!!!!!!!!!!!");
    boolean returnValue = false;
    Form form = context.getMessage().getHeaders().get("form", Form.class);
    
    if ((form.formName == null)||(form.formName.indexOf("壞") > -1)) {
        returnValue = false;
    } else {
        returnValue = true;
    }
    
    System.out.println(form.toString()+" is "+returnValue);
    return returnValue;
}

}
還有四件套的最后一個EventConfig:

@WithStateMachine(id="complexFormMachine")
public class ComplexFormEventConfig {
private Logger logger = LoggerFactory.getLogger(getClass());

/**
 * 當前狀態BLANK_FORM
 */
@OnTransition(target = "BLANK_FORM")
public void create() {
    logger.info("---空白復雜表單---");
}

@OnTransition(source = "BLANK_FORM", target = "FULL_FORM")
public void write(Message message) {
    System.out.println("傳遞的參數:" + message.getHeaders().get("form"));
    logger.info("---填寫完復雜表單---");
}

@OnTransition(source = "FULL_FORM", target = "CHECK_CHOICE")
public void check(Message message) {
    System.out.println("傳遞的參數:" + message.getHeaders().get("form").toString());
    logger.info("---校驗復雜表單---");
}

//不會執行

@OnTransition(source = "CHECK_CHOICE", target = "CONFIRM_FORM")
public void check2confirm(Message message) {
    System.out.println("傳遞的參數:" + message.getHeaders().get("form").toString());
    logger.info("---校驗表單到待提交表單(choice true)---");
}

//不會執行

@OnTransition(source = "CHECK_CHOICE", target = "DEAL_FORM")
public void check2deal(Message message) {
    System.out.println("傳遞的參數:" + message.getHeaders().get("form").toString());
    logger.info("---校驗表單到待提交表單(choice false)---");
}

@OnTransition(source = "DEAL_FORM", target = "DEAL_CHOICE")
public void deal(Message message) {
    System.out.println("傳遞的參數:" + message.getHeaders().get("form").toString());
    logger.info("---處理復雜表單---");
}

//不會執行
@OnTransition(source = "DEAL_CHOICE", target = "FAILED_FORM")
public void deal2fail(Message message) {
    System.out.println("傳遞的參數:" + message.getHeaders().get("form").toString());
    logger.info("---處理復雜表單失敗(choice false)---");
}

//不會執行
@OnTransition(source = "DEAL_CHOICE", target = "FULL_FORM")
public void deal2full(Message message) {
    System.out.println("傳遞的參數:" + message.getHeaders().get("form").toString());
    logger.info("---處理復雜表單到重新填寫表單(choice true)---");
}



/**
 * CONFIRM_FORM->SUCCESS_FORM 執行的動作
 */
@OnTransition(source = "CONFIRM_FORM", target = "SUCCESS_FORM")
public void submit(Message message) {
    System.out.println("傳遞的參數:" + message.getHeaders().get("form").toString());
    logger.info("---表單提交成功---");
}

}
這邊的代碼沒有任何特別的地方,唯一需要需要注意的是我標注的不會執行的這幾個方法。因為在choice判斷的時候,從一個狀態轉變到另外一個狀態時,是不會在eventConfig觸發方法的,比如這個方法:

//不會執行

@OnTransition(source = "CHECK_CHOICE", target = "CONFIRM_FORM")
public void check2confirm(Message message) {
    System.out.println("傳遞的參數:" + message.getHeaders().get("form").toString());
    logger.info("---校驗表單到待提交表單(choice true)---");
}

我定義了如果用戶從CHECK_CHOICE狀態如果判斷后變成CONFIRM_FORM,執行check2confirm方法,但可惜,狀態的確變化了,但這個方法不會執行,只有在做判斷的時候會執行ComplexFormCheckChoiceGuard的evaluate()。這就有個問題,在實際運行中,我們的確會需要在choice做出判斷狀態改變的時候要做些業務處理,比如表單check成功后需要通知后續人員來處理什么的,這該怎么辦呢?

簡單除暴第一招,直接在gurad里面處理。這種方法其實沒有任何問題,因為既然判斷的業務代碼在這里面,我們把判斷完成后需要做的事也在這里寫完不就行了。但是,本著無關的業務能解耦就解耦的原則,我們還有一個辦法
漂亮解耦第二招,寫個action。下面介紹下這個action。
action,看這個名字就知道是要搞事情的,之前我們把業務代碼都是寫到eventConfig的方法里面,但其實可以不怎么干,我們完全可以在每個狀態變化的時候獨立寫一個action,這樣的話就能做到業務的互不打擾。不如下面這段:

.withChoice()

                    .source(ComplexFormStates.CHECK_CHOICE)
                    .first(ComplexFormStates.CONFIRM_FORM, new ComplexFormCheckChoiceGuard(),new ComplexFormChoiceAction())
                    .last(ComplexFormStates.DEAL_FORM,new ComplexFormChoiceAction())
                    .and()

這是builder里面的代碼片段,我們直接把action插入進來,在狀態變化的時候就能在action里面處理了,下面是這個action

的代碼:

public class ComplexFormChoiceAction implements Action {

@Override
public void execute(StateContext context) {
    System.out.println("into ComplexFormChoiceAction");
    Form form = context.getMessage().getHeaders().get("form", Form.class);
    System.out.println(form);
    System.out.println(context.getStateMachine().getState());
}

}
這里面只有一個execute的方法,簡單明了,我們需要的參數通過context傳遞,其實還是message,這樣的話,不同業務用不同的action就行了,我們再回頭看builder里面插入action的地方:

.first(ComplexFormStates.CONFIRM_FORM, new ComplexFormCheckChoiceGuard(),new ComplexFormChoiceAction(),new ComplexFormChoiceAction())
action可以多個插入,也就是有多少多帶帶的業務需要在這里面處理都行,其實回過頭來,不止在withChoice()里面可以,之前的withExternal()也是可以的,看代碼:

.withExternal()

                    .source(ComplexFormStates.FULL_FORM).target(ComplexFormStates.CHECK_CHOICE)
                    .event(ComplexFormEvents.CHECK)
                    .action(new ComplexFormChoiceAction(),new ComplexFormChoiceAction())
                    .guard(new ComplexFormCheckChoiceGuard())
                    .and()

action可以插入多個,但guard在這里恢復了本來的作用,保護狀態變化,所以只能插入一個。

3、在controller里面看結果
最后,我們還是需要看下運行的結果,我準備了三個流程:

check成功,成為SUCCESS_FORM
check失敗,deal成功,回到FULL_FORM
check失敗,deal失敗,成為FAILED_FORM
對應的是form1,form2和form3,看代碼:

@Autowired

private ComplexFormStateMachineBuilder complexFormStateMachineBuilder;

......
@RequestMapping("/testComplexFormState")

public void testComplexFormState() throws Exception {

    StateMachine stateMachine = complexFormStateMachineBuilder.build(beanFactory);
    System.out.println(stateMachine.getId());
    
    Form form1 = new Form();
    form1.setId("111");
    form1.setFormName(null);
    
    Form form2 = new Form();
    form2.setId("222");
    form2.setFormName("好的表單");
    
    Form form3 = new Form();
    form3.setId("333");
    form3.setFormName(null);

    // 創建流程
    System.out.println("-------------------form1------------------");
    
    stateMachine.start();
    Message message = MessageBuilder.withPayload(ComplexFormEvents.WRITE).setHeader("form", form1).build();
    stateMachine.sendEvent(message);
    System.out.println("當前狀態:" + stateMachine.getState().getId());
    message = MessageBuilder.withPayload(ComplexFormEvents.CHECK).setHeader("form", form1).build();
    stateMachine.sendEvent(message);
    System.out.println("當前狀態:" + stateMachine.getState().getId());
    message = MessageBuilder.withPayload(ComplexFormEvents.DEAL).setHeader("form", form1).build();
    stateMachine.sendEvent(message);
    System.out.println("當前狀態:" + stateMachine.getState().getId());
    message = MessageBuilder.withPayload(ComplexFormEvents.SUBMIT).setHeader("form", form1).build();
    stateMachine.sendEvent(message);
    System.out.println("最終狀態:" + stateMachine.getState().getId());
    
    System.out.println("-------------------form2------------------");
    stateMachine = complexFormStateMachineBuilder.build(beanFactory);
    stateMachine.start();
    message = MessageBuilder.withPayload(ComplexFormEvents.WRITE).setHeader("form", form2).build();
    stateMachine.sendEvent(message);
    System.out.println("當前狀態:" + stateMachine.getState().getId());
    message = MessageBuilder.withPayload(ComplexFormEvents.CHECK).setHeader("form", form2).build();
    stateMachine.sendEvent(message);
    System.out.println("當前狀態:" + stateMachine.getState().getId());
    message = MessageBuilder.withPayload(ComplexFormEvents.DEAL).setHeader("form", form2).build();
    stateMachine.sendEvent(message);
    System.out.println("當前狀態:" + stateMachine.getState().getId());
    message = MessageBuilder.withPayload(ComplexFormEvents.SUBMIT).setHeader("form", form2).build();
    stateMachine.sendEvent(message);
    System.out.println("最終狀態:" + stateMachine.getState().getId());
    
    System.out.println("-------------------form3------------------");
    stateMachine = complexFormStateMachineBuilder.build(beanFactory);
    stateMachine.start();
    message = MessageBuilder.withPayload(ComplexFormEvents.WRITE).setHeader("form", form3).build();
    stateMachine.sendEvent(message);
    System.out.println("當前狀態:" + stateMachine.getState().getId());
    message = MessageBuilder.withPayload(ComplexFormEvents.CHECK).setHeader("form", form3).build();
    stateMachine.sendEvent(message);
    System.out.println("當前狀態:" + stateMachine.getState().getId());
    form3.setFormName("好的表單");
    message = MessageBuilder.withPayload(ComplexFormEvents.DEAL).setHeader("form", form3).build();
    stateMachine.sendEvent(message);
    System.out.println("當前狀態:" + stateMachine.getState().getId());
    message = MessageBuilder.withPayload(ComplexFormEvents.SUBMIT).setHeader("form", form3).build();
    stateMachine.sendEvent(message);
    message = MessageBuilder.withPayload(ComplexFormEvents.CHECK).setHeader("form", form3).build();
    stateMachine.sendEvent(message);
    System.out.println("當前狀態:" + stateMachine.getState().getId());
    message = MessageBuilder.withPayload(ComplexFormEvents.SUBMIT).setHeader("form", form3).build();
    stateMachine.sendEvent(message);
    System.out.println("最終狀態:" + stateMachine.getState().getId());
}

......
看console的結果就知道正確與否

構建復雜表單狀態機
complexFormMachine
-------------------form1------------------
2019-05-13 18:07:19.364 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---空白復雜表單---
2019-05-13 18:07:19.368 INFO 6188 --- [nio-9991-exec-1] o.s.s.support.LifecycleObjectSupport : started org.springframework.statemachine.support.DefaultStateMachineExecutor@16603576
2019-05-13 18:07:19.369 INFO 6188 --- [nio-9991-exec-1] o.s.s.support.LifecycleObjectSupport : started CONFIRM_FORM BLANK_FORM FAILED_FORM FULL_FORM SUCCESS_FORM DEAL_FORM DEAL_CHOICE CHECK_CHOICE / BLANK_FORM / uuid=2aa87c74-dd28-4790-9722-d04657eaf046 / id=complexFormMachine
傳遞的參數:Form [id=111, formName=null]
2019-05-13 18:07:19.381 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---填寫完復雜表單---
當前狀態:FULL_FORM
傳遞的參數:Form [id=111, formName=null]
2019-05-13 18:07:19.386 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---校驗復雜表單---
ComplexFormCheckChoiceGuard!!!!!!!!!!!!!
Form [id=111, formName=null] is false
into ComplexFormChoiceAction
Form [id=111, formName=null]
ObjectState [getIds()=[FULL_FORM], getClass()=class org.springframework.statemachine.state.ObjectState, hashCode()=381700599, toString()=AbstractState [id=FULL_FORM, pseudoState=null, deferred=[], entryActions=[], exitActions=[], stateActions=[], regions=[], submachine=null]]
當前狀態:DEAL_FORM
傳遞的參數:Form [id=111, formName=null]
2019-05-13 18:07:19.389 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---處理復雜表單---
ComplexFormDealChoiceGuard!!!!!!!!!!!!!
Form [id=111, formName=null] is false
into ComplexFormChoiceAction
Form [id=111, formName=null]
ObjectState [getIds()=[DEAL_FORM], getClass()=class org.springframework.statemachine.state.ObjectState, hashCode()=980487842, toString()=AbstractState [id=DEAL_FORM, pseudoState=null, deferred=[], entryActions=[], exitActions=[], stateActions=[], regions=[], submachine=null]]
當前狀態:FAILED_FORM
最終狀態:FAILED_FORM
-------------------form2------------------
構建復雜表單狀態機
2019-05-13 18:07:19.394 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---空白復雜表單---
2019-05-13 18:07:19.394 INFO 6188 --- [nio-9991-exec-1] o.s.s.support.LifecycleObjectSupport : started org.springframework.statemachine.support.DefaultStateMachineExecutor@51adbaad
2019-05-13 18:07:19.394 INFO 6188 --- [nio-9991-exec-1] o.s.s.support.LifecycleObjectSupport : started CONFIRM_FORM BLANK_FORM FAILED_FORM FULL_FORM SUCCESS_FORM DEAL_FORM DEAL_CHOICE CHECK_CHOICE / BLANK_FORM / uuid=fa133ea8-bf48-437e-ae35-dc7aa616a23c / id=complexFormMachine
傳遞的參數:Form [id=222, formName=好的表單]
2019-05-13 18:07:19.395 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---填寫完復雜表單---
當前狀態:FULL_FORM
傳遞的參數:Form [id=222, formName=好的表單]
2019-05-13 18:07:19.396 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---校驗復雜表單---
ComplexFormCheckChoiceGuard!!!!!!!!!!!!!
Form [id=222, formName=好的表單] is true
into ComplexFormChoiceAction
Form [id=222, formName=好的表單]
ObjectState [getIds()=[FULL_FORM], getClass()=class org.springframework.statemachine.state.ObjectState, hashCode()=249611509, toString()=AbstractState [id=FULL_FORM, pseudoState=null, deferred=[], entryActions=[], exitActions=[], stateActions=[], regions=[], submachine=null]]
當前狀態:CONFIRM_FORM
當前狀態:CONFIRM_FORM
傳遞的參數:Form [id=222, formName=好的表單]
2019-05-13 18:07:19.399 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---表單提交成功---
最終狀態:SUCCESS_FORM
-------------------form3------------------
構建復雜表單狀態機
2019-05-13 18:07:19.404 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---空白復雜表單---
2019-05-13 18:07:19.405 INFO 6188 --- [nio-9991-exec-1] o.s.s.support.LifecycleObjectSupport : started org.springframework.statemachine.support.DefaultStateMachineExecutor@6f12d1a
2019-05-13 18:07:19.406 INFO 6188 --- [nio-9991-exec-1] o.s.s.support.LifecycleObjectSupport : started CONFIRM_FORM BLANK_FORM FAILED_FORM FULL_FORM SUCCESS_FORM DEAL_FORM DEAL_CHOICE CHECK_CHOICE / BLANK_FORM / uuid=03e8c891-eedc-4922-811c-ab375a1e70ae / id=complexFormMachine
傳遞的參數:Form [id=333, formName=null]
2019-05-13 18:07:19.409 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---填寫完復雜表單---
當前狀態:FULL_FORM
傳遞的參數:Form [id=333, formName=null]
2019-05-13 18:07:19.410 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---校驗復雜表單---
ComplexFormCheckChoiceGuard!!!!!!!!!!!!!
Form [id=333, formName=null] is false
into ComplexFormChoiceAction
Form [id=333, formName=null]
ObjectState [getIds()=[FULL_FORM], getClass()=class org.springframework.statemachine.state.ObjectState, hashCode()=608638875, toString()=AbstractState [id=FULL_FORM, pseudoState=null, deferred=[], entryActions=[], exitActions=[], stateActions=[], regions=[], submachine=null]]
當前狀態:DEAL_FORM
傳遞的參數:Form [id=333, formName=好的表單]
2019-05-13 18:07:19.412 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---處理復雜表單---
ComplexFormDealChoiceGuard!!!!!!!!!!!!!
Form [id=333, formName=好的表單] is true
into ComplexFormChoiceAction
Form [id=333, formName=好的表單]
ObjectState [getIds()=[DEAL_FORM], getClass()=class org.springframework.statemachine.state.ObjectState, hashCode()=1203626264, toString()=AbstractState [id=DEAL_FORM, pseudoState=null, deferred=[], entryActions=[], exitActions=[], stateActions=[], regions=[], submachine=null]]
當前狀態:FULL_FORM
傳遞的參數:Form [id=333, formName=好的表單]
2019-05-13 18:07:19.413 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---校驗復雜表單---
ComplexFormCheckChoiceGuard!!!!!!!!!!!!!
Form [id=333, formName=好的表單] is true
into ComplexFormChoiceAction
Form [id=333, formName=好的表單]
ObjectState [getIds()=[FULL_FORM], getClass()=class org.springframework.statemachine.state.ObjectState, hashCode()=608638875, toString()=AbstractState [id=FULL_FORM, pseudoState=null, deferred=[], entryActions=[], exitActions=[], stateActions=[], regions=[], submachine=null]]
當前狀態:CONFIRM_FORM
傳遞的參數:Form [id=333, formName=好的表單]
2019-05-13 18:07:19.415 INFO 6188 --- [nio-9991-exec-1] tConfig$$EnhancerBySpringCGLIB$$37df7571 : ---表單提交成功---
最終狀態:SUCCESS_FORM
大家可以跑一下,對照狀態機的流程圖,看下結果。

4、繼續廢話
其實spring statemachine寫到這里,基本上已經可以上手去做企業開發了。當然,spring statemachine里面還有很多其他的東西,大部分是處理復雜狀態機流程的,以后有機會我們再展開講。

源代碼地址

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/75298.html

相關文章

  • spring statemachine企業可用開發指南7-偽持久化和中間段狀態

    摘要:在實際的企業開發中,不可能所有情況都是從頭到尾的按狀態流程來,會有很多意外,比如歷史數據,故障重啟后的遺留流程,所以這種可以任意調節狀態的才是我們需要的狀態機。 1、偽持久化和中間段的狀態機我們設想一個業務場景,就比如訂單吧,我們一般的設計都會把訂單狀態存到訂單表里面,其他的業務信息也都有表保存,而狀態機的主要作用其實是規范整個訂單業務流程的狀態和事件,所以狀態機要不要保存真的不重要,...

    shiyang6017 評論0 收藏0
  • spring statemachine企業可用開發指南1-說些廢話

    摘要:讓我們先看下狀態機的概念。下面是狀態機模型中的個要素,即現態條件動作次態。因為訂單和審批公文都有很多的流程,每個流程都會產生狀態的變化,而且流程是這種業務的主軸,其他都是圍繞這個流程和狀態變化來考慮的,所以看起來蠻適合用狀態機來做。 1、背景在我打算學習spring statemachine的時候,我幾乎看過了所有網上的中文教程,基本上都處于淺嘗輒止的階段,有幾篇講的比較深入的,都只是...

    BakerJ 評論0 收藏0
  • spring statemachine企業可用開發指南3-多個狀態機共存

    摘要:雖然多個狀態機的問題解決了,但是對于實際的企業應用而言,還是有問題。這個問題就用到了狀態機的持久化,我們下一章就談談持久化問題。 1、多個狀態機的搞法在實際的企業應用中,基本不可能只有一個狀態機流程在跑,比如訂單,肯定是很多個訂單在運行,每個訂單都有自己的訂單狀態機流程,但上一章的例子,大家可以試一下,當執行到一個狀態時,再次刷新頁面,不會有任何日志出現,當一個狀態流程執行到某個狀態,...

    zhongmeizhi 評論0 收藏0
  • spring statemachine企業可用開發指南2-先跑起來

    摘要:先來一個,它的主要作用就告訴狀態機的初始狀態應該啥樣,然后把整個狀態流程都用代碼配置出來。繼承了類,表明身份,我就是來配置狀態機的初始狀態,并描繪一下狀態流程的全過程。 上一篇說了很多廢話,這一篇就不嘮叨,先跑起來 1、來個spring boot去start.spring.io新建一個springboot的項目,雖然我對spirngboot也有不少的牢騷,但作為demo的開始,還是一個...

    lvzishen 評論0 收藏0
  • spring statemachine企業可用開發指南4-多種狀態機共存

    摘要:目前為止,多個狀態機和多種狀態機都可以在里面實現了,下一章我們來解決下狀態機和實際業務間的數據傳輸問題,畢竟我們不是為了讓狀態機自個獨自玩耍,和業務數據互通有無才是企業開發的正道。 在上一章的例子中,我們實現了多個狀態機并存執行,不同的訂單有各自的狀態機運行,但只有一種狀態機,這顯然不能滿足實際業務的要求,比如我就遇到了訂單流程和公文審批流程在同一個項目的情況,所以我們這一章講怎么讓多...

    boredream 評論0 收藏0

發表評論

0條評論

jzzlee

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<