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

成都創(chuàng)新互聯(lián)網(wǎng)絡(luò)公司擁有10余年的成都網(wǎng)站開發(fā)建設(shè)經(jīng)驗，數(shù)千家客戶的共同信賴。提供做網(wǎng)站、網(wǎng)站制作、網(wǎng)站開發(fā)、網(wǎng)站定制、買友情鏈接、建網(wǎng)站、網(wǎng)站搭建、成都響應式網(wǎng)站建設(shè)公司、網(wǎng)頁設(shè)計師打造企業(yè)風格，提供周到的售前咨詢和貼心的售后服務

設(shè)計粒度

"關(guān)于你分享的這個產(chǎn)品，我們晚上也討論了一下，之前也有人做過類似的，實踐中發(fā)現(xiàn)業(yè)務邏輯會很復雜，做出來的圖也很復雜，最終都成先烈了，這塊你實踐的過程有什么經(jīng)驗么"

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

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

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

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

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

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

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

接口設(shè)計問題

Context設(shè)計思路和如何封裝？ Context作為資源鏈，以往有系統(tǒng)將其設(shè)計為樹狀結(jié)構(gòu)，比如：

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

從下級節(jié)點往上級節(jié)點進行數(shù)據(jù)查找和操作，服務級Context（業(yè)務流程中使用）在流程完成后自動銷毀，無狀態(tài)。

建議：

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

應用系統(tǒng)是否可以根據(jù)實際情況實現(xiàn)自己的Context？因為現(xiàn)有的很多系統(tǒng)都已有自己的Context。

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

回答：

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

（3）服務請求數(shù)據(jù)使用什么方式實現(xiàn)自動綁定到Context中？

json數(shù)據(jù)（前端提交）→服務（解析json數(shù)據(jù)，數(shù)據(jù)轉(zhuǎn)換為java類型或?qū)ο螅?，這時如何實現(xiàn)不需要開發(fā)人員將轉(zhuǎn)換后的java類型或?qū)ο笫止ぶ饌€設(shè)置到Context中，而是由框架自動將這些數(shù)據(jù)賦值到Context中，開發(fā)人員通過Context提供的get方法和set方法操作數(shù)據(jù)，不需要關(guān)注Context內(nèi)部構(gòu)造。

建議：

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

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

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

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

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

與現(xiàn)有框架集成相關(guān)問題

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

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

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

建議：

可以通過spring的factory

目前是否有能夠繼續(xù)沿用dubbo這些框架的優(yōu)勢，并能夠?qū)Unit集成進來而無需編寫類似“八股文”代碼的方法？

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

演變成：

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

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

建議：

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

異常處理

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

unit內(nèi)部發(fā)生異常直接拋出去，所以如果某個unit會有異常，可以

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

• 在unit外部包裝一個decorator，ecorator里面進行異常處理?？梢愿鶕?jù)捕獲到的異常設(shè)置特定的字段，在后繼處理步驟中通過validator/locator做異常流程判斷和處理

• 不處理，異常拋出讓最外層調(diào)用方處理

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

見上面回答

能否支持補償機制，以方便流程執(zhí)行發(fā)生異常后進行后續(xù)處理？

見上面回答

數(shù)據(jù)庫事務

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

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

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

這個不是xunit的范圍

組件庫

特定行業(yè)組件擴展

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

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

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

發(fā)布策略

流程配置文件與程序代碼打包一起發(fā)布還是由配置中心統(tǒng)一發(fā)布？

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

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

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

加載策略

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

這個可以放到系統(tǒng)初始化的時候做一次即可， @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);
 	    }
 	}

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

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

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

factory的緩存留給用戶處理

組件設(shè)計相關(guān)問題

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

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

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

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

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

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

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

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

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

結(jié)構(gòu)不一致處理

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

回答：

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

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

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

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

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

感謝你的閱讀，相信你對“xunit常見問題有哪些”這一問題有一定的了解，快去動手實踐吧，如果想了解更多相關(guān)知識點，可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站！小編會繼續(xù)為大家?guī)砀玫奈恼拢?/p>
本文標題：xunit常見問題有哪些
新聞來源：http://weahome.cn/article/jhhedo.html