xunit常見問題有哪些

這篇文章的內容主要圍繞xunit常見問題有哪些進行講述，文章內容清晰易懂，條理清晰，非常適合新手學習，值得大家去閱讀。感興趣的朋友可以跟隨小編一起閱讀吧。希望大家通過這篇文章有所收獲！

設計粒度

"關于你分享的這個產品，我們晚上也討論了一下，之前也有人做過類似的，實踐中發現業務邏輯會很復雜，做出來的圖也很復雜，最終都成先烈了，這塊你實踐的過程有什么經驗么"

這個問題是使用上粒度沒掌握好造成的。

一般來說，每個圖對應系統一個服務的api，每個API對應一些步驟。只要把圖畫到知道每個步驟做什么事情即可。每個步驟的代碼最好不要超過50行，指的是純代碼

每個步驟明確做一件事情。內部除了非常相關的邏輯，否則不要再做分支判斷

我的推薦是： 圖的長度不要超過5個節點，高度不要超過5個節點，基本上保證一個屏幕放大后可以顯示的下

如果一個系統/子系統確實復雜，步驟繁多，那么請用主圖，子圖結合的做法在兩個抽象層面上描述系統

這個工具設計的很人性化，基本上很快就能上手，其實實際用用就知道怎樣是合適的粒度了。并不需要特別的規范。因為大家通過這個工具review代碼的時候，很快就會對粒度，代碼長度形成共識。

把一個系統做出來不難。但把系統做得很棒很難。一個很棒的系統其表現出來的模型圖也一定是非常美觀的。而達到這種美觀所需要做的代碼重構，功能合并，拆分等等就需要并且值得投入功夫去打磨。而我的工具為這種打磨提供了最好的平臺

接口設計問題

Context設計思路和如何封裝？ Context作為資源鏈，以往有系統將其設計為樹狀結構，比如：

RootContext（根）
      |-------ChannelContext（渠道）
                   |-----------SessionContext（會話）
                                   |-------Context（服務）

從下級節點往上級節點進行數據查找和操作，服務級Context（業務流程中使用）在流程完成后自動銷毀，無狀態。

建議：

復雜系統用這個思路是可以的。簡單系統可以不用這么多層次，只要夠用就行，提供Converter的目的就是為了通過轉換接口將數據盡可能的封裝/隔離起來，這樣無關的unit就無法看到所有的信息

應用系統是否可以根據實際情況實現自己的Context？因為現有的很多系統都已有自己的Context。

Context作為數據容器，管理和承載著業務流程處理過程中使用到的數據。工具集中提供了Context接口的定義： public interface Context { } 以及MapContext的具體實現，應用系統是否可以根據實際情況實現自己的Context？因為現有的很多系統都已有自己的Context。

回答：

這個當然可以，之所以只定義個空接口正是為了能夠適應所有的情況

（3）服務請求數據使用什么方式實現自動綁定到Context中？

json數據（前端提交）→服務（解析json數據，數據轉換為java類型或對象），這時如何實現不需要開發人員將轉換后的java類型或對象手工逐個設置到Context中，而是由框架自動將這些數據賦值到Context中，開發人員通過Context提供的get方法和set方法操作數據，不需要關注Context內部構造。

建議：

一般都是由特定的接入平臺提供數據綁定，比如用Jerssy，可以直接把請求綁定到特定Context的實現上，具體如何實現要看你平臺提供什么樣的能力。由于這塊不是xunit的范圍，因此缺省沒提供，我后面打算提供些基于web容器的范例

目前，已經使用xUnit進行開發的公司，面對以上問題，使用的解決辦法或思路是哪些？

我知道的一家互聯網醫療企業使用的就是基于容器的請求到context的映射。容器先把請求的字段映射到context的特定字段，系統在獲得初始的context后，通過后繼處理提供session或者app級別的其他必要信息，具體代碼示例，我現在一時找不到

xUnit是否考慮從數據模型層面，將針對Context的配置通過可視化界面完成，如：Context的數據定義等？

這個不是xunit的核心功能，可以做個小工具

與現有框架集成相關問題

現有dubbo, spring cloud等框架或平臺，使用比較普遍。xUnit將原來在這些服務中編碼實現的業務流程組裝圖形化后，如何將xUnit流程整合到這些框架中？

例子中給出的方式如： XunitFactory f = XunitFactory.load("new_xross_unit.xunit"); Processor p = f.getProcessor("chain1"); TextContext ctx = new TextContext("xUnitTest"); p.process(ctx);

個服務都需要編寫這段固定格式的代碼執行業務流程嗎？還是有其他的方式？

建議：

可以通過spring的factory <bean id="facctory" class="com.xross.tools.xunit" factory-method="load"> <constructor-arg name="targetClass" type="Class" value="xunit model path" /> </bean>

目前是否有能夠繼續沿用dubbo這些框架的優勢，并能夠將xUnit集成進來而無需編寫類似“八股文”代碼的方法？

例如，dubbo服務端對外暴露的FacadeService（具體業務處理流程實現）在將其內部實現的業務流程通過xUnit組裝后，其內部代碼已經被抽離并封裝成功能單一的組件供復用，這樣就造成FacadeService內除了以上執行業務流程的固定代碼外已無其它有效代碼。即代碼由 public void addBannerinfo(para1, para2, ……) throws ServiceException { //業務流程實現 ……. }

演變成：

public void addBannerinfo(para1, para2, ......) throws ServiceException {
 //執行業務流程
   XunitFactory f = XunitFactory.load("new_xross_unit.xunit");
   Processor p = f.getProcessor("chain1");
   TextContext ctx = new TextContext("xUnitTest");
   p.process(ctx);
}

但如果不實現FacadeService，并進行相關dubbo服務端配置，該服務將無法自動注冊到服務中心，這樣將無法繼續使用原有平臺服務自動注冊和發現，服務治理等特性。 目前是否有能夠繼續沿用這些框架的優勢，并能夠將xUnit集成進來而無需編寫類似“八股文”代碼的方法？

建議：

你之所以會有這樣的問題是由于你通過xunit把所有的流程都在一個大流程里面管理起來了。你完全可以還是在原來的服務粒度上提供注冊。你可以為原來的每個服務提供一個單獨的流程。這樣還是會有多個FacadeService以進行配置和注冊。而且你完全可以做個通用的FacadeService實現，用參數化的方式來避免定義多個類

異常處理

X-Series工具集的異常處理機制是？

unit內部發生異常直接拋出去，所以如果某個unit會有異常，可以

• 本單元自己處理異常，捕獲異常后在context里面放置異常信息或者flag

• 在unit外部包裝一個decorator，ecorator里面進行異常處理。可以根據捕獲到的異常設置特定的字段，在后繼處理步驟中通過validator/locator做異常流程判斷和處理

• 不處理，異常拋出讓最外層調用方處理

流程處理過程中，拋出的異常是由工具集統一處理還是原樣拋出，由外部執行流程者處理？

見上面回答

能否支持補償機制，以方便流程執行發生異常后進行后續處理？

見上面回答

數據庫事務

同一個流程中，若多個組件（如：DB組件1,DB組件2）間存在多個數據庫操作，例如：在流程執行到DB組件2時發生了異常，為了保證數據的一致性，工具集在這方面有哪些考慮或支持的手段來保證DB組件1和DB組件2同時執行成功或失敗？是DB組件1根據工具集的預先配置（如：獨立事務）執行回滾呢？還是采用全局事務配置在流程正常執行結束后進行統一提交？

這個不是xunit的范圍，需要如何處理，可以看你們的需求。可以把流程包在事物里面。我有個research項目是關于數據庫無鎖操作的，應該可以解決這個問題，目前還沒正式開始編碼

xUnit是否考慮在配置上支持數據庫事務控制（通過根據業務系統實際情況擴展一些獨立的數據庫操作組件）？還是由開發人員僅通過從應用開發層面進行控制？

這個不是xunit的范圍

組件庫

特定行業組件擴展

X-Series提供了一個與平臺、業務無關的輕量級工具集，很好的解決了一些在以往開發中遇到的問題。例如使用現有的Processor組件，通過配置具體業務實現類就能實現流程開發。但這個靈活的支持卻有可能會造成巨大的困擾，控制不好會產生大量的Processor組件實現類而無法管控。同時，很多公司在一些業務領域已深耕多年，都有比較多的技術實現積累和沉淀。一旦將xUnit應用到具體行業進行開發，如果各公司能夠根據自身情況，在現有xUnit基礎上封裝針對具體行業的可復用組件，如[用戶組件庫示意圖]

將能有效的降低開發人員開發門檻和開發成本，并控制代碼質量。 開發過程中，普通開發人員只需了解各組件的功能和使用方法，通過直接拖拽組件，簡單配置一些和業務相關的屬性，絕大部分情況下不再需要普通開發人員去指定甚至自己編寫具體實現類（在特定組件封裝時已配置）。 其實，在大中型系統中，讓普通開發人員去了解應用中有哪些具體類實現了什么功能，這是一件無法落實到位的事，也不可能。最終會造成不同的開發人員對同一功能，各自編寫自己的實現代碼，造成維護上的困難。即使原應用已有相關實現類供復用，但因為開發人員不了解而造成重復開發。 （1）那么，框架管理層面的人員如何對自身行業常用組件進行定制和擴展？ （2）實現組件的基本流程包括哪些，是否有Demo？ （3）進行組件擴展需要哪些技能？必須熟練掌握Eclipse插件開發（有較高門檻）嗎？是否能在插件開發方面提供一些建議和學習資料?

建議： 你這個問題太復雜了，1，2我都無法回答，因為這和具體的領域相關。關于3，目前插件開發如果做到像xunit這樣的，門檻老實說很高，我花了很長時間才把這個東西做好。如果只是像你這個截圖一樣的功能，應該還比較簡單

發布策略

流程配置文件與程序代碼打包一起發布還是由配置中心統一發布？

都可以，如果發布自動化程度高，可以打包，如果整體代碼過于龐大，建議配置放到配置中心

是否支持在線更新/替換而無需重啟服務？

支持的，攜程就是這么做的 # 若支持配置中心統一發布，是否能與攜程開源的配置管理中心Apolo整合？ 可以的 # 在線更新過程中是否會影響正在進行的流程？ 更新操作是重新生成flow，替換掉原來的，老的context的處理還是繼續走完，新的context請求去新創建的flow

加載策略

每次執行流程前，XunitFactory.load("new_xross_unit.xunit");方法使用什么樣的加載機制？

這個可以放到系統初始化的時候做一次即可， @WebServlet("/PeoplePortal") public class XunitPeoplePortal extends HttpServlet { private static final long serialVersionUID = 1L; private PeopleDao dao; private Processor demo;

/**
 * @see Servlet#init(ServletConfig)
 */
public void init(ServletConfig config) throws ServletException {
	try {
		demo = XunitFactory.load("dal_demo.xunit").getProcessor("main");
	} catch (Exception e) {
		throw new ServletException(e);
	}
}

/**
 	 * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse
 	 *      response)
 	 */
 	protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
 		WebContext context = new WebContext(request, response, dao);
 		try {
 			demo.process(context);
 		} catch (Exception e) {
 			throw new ServletException(e);
 	    }
 	}

每次都需要實時解析流程配置文件嗎？

不需要 # 還是命中后再讀取時就可緩存中加載？ 內部沒緩存，只要調用load，就會重新完整的讀取一次

如果支持緩存加載，后續配置文件更新時如何重置緩存？直接使緩存失效？

factory的緩存留給用戶處理

組件設計相關問題

開始和結束組件如何定位？在一個流程中，開始和結束組件是否是必須要配置的組件？

如果是xunit，則不用，只是為了遵循這些圖的慣例而提供顯示上面的開始結束節點。如果是狀態機，用戶可以在開始結束節點提供觸發器

adapter組件，如何理解“將某種unit的行為轉換為另一種”？

比如你手頭只有processor的class而沒有代碼，或者你懶得寫，而你需要的步驟是converter，你可以通過adapter提供converter的行為，內部調用之前的processor，并做你需要的額外處理

屬性自動識別：如何理解“任何組件只要定義了PROP_KEY開頭的靜態String常量，則在通過編輯器打開后，其定義的常量的內容可以被編輯器識別和顯示為該組件可配置的屬性。這些屬性會通過UnitPropertiesAware接口在組件被創建時設置進去。”？

你定義一個processor，里面定義個PROP_KEY_abc = “abc”，在xunit編輯器里面如果將這個class綁定到某個processor，在屬性欄里面就會有abc這個屬性，這只是一個定義什么屬性可以設置的契約

在每個組件中，如果需要獲取屬性的值，是否都需要各自獨立實現UnitPropertiesAware接口的setUnitProperties(Map<String, String> arg0)方法？如：

@Override
public void setUnitProperties(Map<String, String> arg0) {
	testValue = Double.parseDouble(arg0.get(PROP_KEY_TESTFILED));
}

目前是這樣，所以如果不實現這個接口，即使定義了屬性也不會起作用，后面可能考慮用反射的方式處理

結構不一致處理

“如果Chain的行為模式是Converter，而Chain中包含Processor，則Processor的輸入Context會當作Convert的結果傳遞到下一個單元。” “如果Chain的行為模式是Processor，而Chain中包含Converter，則Converter的convert方法會被調用，但是轉化的輸出Context則會被丟棄。最開始輸入的Context會傳遞到下一個單元。” 這兩點該如何理解？

回答：

這就是內部缺省的對processor和converter的adapter實現方式。如果chain是converter，而里面有processor，按照converterchain的定義，里面每個unit都應該是converter，而當前這個確是processor，按照正常處理，應該把這個processor用一個adapter包裝起來，包裝為converter，但由于這個是普遍的現象，因此就通過這種方式做通用處理。把processor看作是一個輸入和輸出都是同一個類型的context的converter。另外一個類似處理

xUnit的Default實現，作為Processor和Converter時顯示特定信息需要指定showMessage屬性。運行時直接顯示給定的內容，顯示應用級別屬性需要指定showApplicationProperties屬性。屬性名之間","隔開。這兩個屬性在實際應用中該如何理解和使用？

Default實現只是為了方便大家在不寫代碼的情況下，快速構建和運行系統的原型，通過顯示提供的字符串的形式，讓用戶對系統進行調整并讓系統表現出真實的互動

X-Series工具集是否有發展成為開發平臺（除Xeda外）的計劃？或者，除流程定義外，提供一些其它方面的支持，如：（1）數據定義：（2）數據報文：（3）數據字典（4）核心配置文件可視化管理

這些都有現成的很好的工具支持。所以我就不做了。我提供工具的原則是僅提供大家的盲點或者都沒有的功能。

感謝你的閱讀，相信你對“xunit常見問題有哪些”這一問題有一定的了解，快去動手實踐吧，如果想了解更多相關知識點，可以關注億速云網站！小編會繼續為大家帶來更好的文章！