xunit常见问题有哪些

这篇文章的内容主要围绕xunit常见问题有哪些进行讲述，文章内容清晰易懂，条理清晰，非常适合新手学习，值得大家去阅读。感兴趣的朋友可以跟随小编一起阅读吧。希望大家通过这篇文章有所收获！

成都创新互联网络公司拥有10余年的成都网站开发建设经验，数千家客户的共同信赖。提供做网站、网站制作、网站开发、网站定制、买友情链接、建网站、网站搭建、成都响应式网站建设公司、网页设计师打造企业风格，提供周到的售前咨询和贴心的售后服务

设计粒度

"关于你分享的这个产品，我们晚上也讨论了一下，之前也有人做过类似的，实践中发现业务逻辑会很复杂，做出来的图也很复杂，最终都成先烈了，这块你实践的过程有什么经验么"

这个问题是使用上粒度没掌握好造成的。

一般来说，每个图对应系统一个服务的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

目前是否有能够继续沿用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 arg0)方法？如：

@Override
public void setUnitProperties(Map 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常见问题有哪些”这一问题有一定的了解，快去动手实践吧，如果想了解更多相关知识点，可以关注创新互联网站！小编会继续为大家带来更好的文章！