xunit常見(jiàn)問(wèn)題有哪些

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

設(shè)計(jì)粒度

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

這個(gè)問(wèn)題是使用上粒度沒(méi)掌握好造成的。

一般來(lái)說(shuō)，每個(gè)圖對(duì)應(yīng)系統(tǒng)一個(gè)服務(wù)的api，每個(gè)API對(duì)應(yīng)一些步驟。只要把圖畫到知道每個(gè)步驟做什么事情即可。每個(gè)步驟的代碼最好不要超過(guò)50行，指的是純代碼

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

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

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

這個(gè)工具設(shè)計(jì)的很人性化，基本上很快就能上手，其實(shí)實(shí)際用用就知道怎樣是合適的粒度了。并不需要特別的規(guī)范。因?yàn)榇蠹彝ㄟ^(guò)這個(gè)工具review代碼的時(shí)候，很快就會(huì)對(duì)粒度，代碼長(zhǎng)度形成共識(shí)。

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

接口設(shè)計(jì)問(wèn)題

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

RootContext（根）
      |-------ChannelContext（渠道）
                   |-----------SessionContext（會(huì)話）
                                   |-------Context（服務(wù)）

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

建議：

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

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

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

回答：

這個(gè)當(dāng)然可以，之所以只定義個(gè)空接口正是為了能夠適應(yīng)所有的情況

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

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

建議：

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

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

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

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

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

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

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

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

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

建議：

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

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

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

演變成：

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

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

建議：

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

異常處理

X-Series工具集的異常處理機(jī)制是？

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

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

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

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

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

見(jiàn)上面回答

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

見(jiàn)上面回答

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

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

這個(gè)不是xunit的范圍，需要如何處理，可以看你們的需求?？梢园蚜鞒贪谑挛锢锩?。我有個(gè)research項(xiàng)目是關(guān)于數(shù)據(jù)庫(kù)無(wú)鎖操作的，應(yīng)該可以解決這個(gè)問(wèn)題，目前還沒(méi)正式開始編碼

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

這個(gè)不是xunit的范圍

組件庫(kù)

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

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

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

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

發(fā)布策略

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

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

是否支持在線更新/替換而無(wú)需重啟服務(wù)？

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

加載策略

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

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

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

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

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

factory的緩存留給用戶處理

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

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

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

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

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

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

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

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

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

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

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

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

回答：

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

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

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

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

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

感謝你的閱讀，相信你對(duì)“xunit常見(jiàn)問(wèn)題有哪些”這一問(wèn)題有一定的了解，快去動(dòng)手實(shí)踐吧，如果想了解更多相關(guān)知識(shí)點(diǎn)，可以關(guān)注億速云網(wǎng)站！小編會(huì)繼續(xù)為大家?guī)?lái)更好的文章！