AUTOUI 软件开发中界面的自动化技术可行性分析

 

前言

本文论证了动态生成UI和静态生成UI的关系。同时对UI部分可以形成框架进行了总结和论证。

第一部分 动态还是静态

大前提是：不能用手写去“画” 界面，就是说不能在代码级别纯手写每个控件的位置等等。这些一定要交给IDE。

 

因此存在的分歧主要是以下几点：

1. 画界面，生成xml或代码的metadata，再生成静态代码

2. 画界面，生成xml或代码的metadata，系统运行中动态解析xml/metadata自动生成界面。

无论哪种方式，必然存在了一个中间环节：xml/metadata。

如果是动态加载，那么相关的界面配置有可能存在在实体的metadata、或者相关的xml。如果界面的需求很复杂，例如A的时候隐藏字段a，B的时候隐藏字段b，这样必然得不偿失。

 

既然前期画界面是相同的；生成静态代码、或者动态解析生成基本上没有工作量，那么中间环节明显使用静态代码优势更大。

因此绝对使用静态生成方式！

 

本次分析再次体现了，技术仅仅是为了人服务，不要为了技术而技术。 

 

第二部分 界面的分类

界面主要包含三种。

1. 简单输入界面

主要用于创建原始数据，例如商家信息、门店信息等。

特点是：改变少、不依赖其他数据、企业日常运行中修改较少。

 

2. 查询界面

主要对各种数据进行查询，包括主从表查询等，难点在于查询条件的自动化配置。

 

3. 复杂输入界面

主要创建企业业务数据，例如订单、入货单、退货单等。

特点：经常改变、非常依赖其他原始数据、企业日常运行中涉及频繁。

 

可以看见，最难的是复杂输入界面。然而本人发现几点非常有趣的现象

A：第二种查询界面的查询条件就是第一种简单输入界面。

B：第三种复杂输入界面可以就是第一种、第二种界面复合而成

可见，只要层层递进，完全可是实现AUTOUI。

 

第三部分 界面开发的步骤

界面开发的步骤包括了：

1. 布局 layout

首先是画布局，而不是把一个个控件先拖到界面，再慢慢摆弄。

几乎超过80%的界面可以使用网格布局（grid layout），所以无论html、winform等等都支持了网格布局。

 

2. 控件与静态数据 component and static data

然后就是在布局上分配相关的控件，例如Textbox, ComboBox等。

然后再指定控件的明细信息，包括ID、依赖的静态数据等，例如Combobox的下拉框数据、gridview的显示结构数据等。这里的数据是静态数据，即在本界面运行过程中数据是有范围、不修改、固定的、非运行中加载的，例如性别等。

 

3. 界面级别输入验证 verification

设置输入验证。例如只能输入数字，数值范围在0~1等。 

 

4. 事件声明 event declaration

部署好了控件之后，分配不同控件的事件，例如button的click事件等（空事件体）。

 

5. 控件、窗体之间的数据关系 pageflow（我称这个技术为页面流） 

这部分是最复杂耗时的部分。包括

A: 界面中不同控件之间的数据联动；例如选择中国、然后得到中国的城市列表。

B: 查询某数据源，然后获得控件的数据；例如打开查询商家子界面，查询到商家编码后确认，返回到订单的商家编码字段。

C: 界面事件结束后，跳转到另外的界面；例如订单确认，跳转到管理界面。

 

6. 控件之间的依赖关系 stepflows （我称其为step by step 层进流技术）

例如必须先输入了商家名称，然后才能输入商品名称 这个是在pageflow基础上进一步限制了界面输入。

 

以上5点中，1、2、3、4都可以使用工具自动完成，因此完全可以实现AUTOUI，但是第五点必须硬编码。因此AUTOUI的极限就是做到了第四点，同时为第五点提供了统一的开发接口。

 

到了现在，我可以幻想一下一个AUTOUI应该的样子（VISION），工作量以100%来算。

1. 首先画布局，很简单的在canvas上直接所见所得。10% 

2. 在布局上配置控件，同时设置控件的ID、静态数据等。10%

3. 配置界面控件的输入验证，使用默认验证（非空、数字、正则表达式）。（如果实在验证太复杂，那么就留在AUTOUI完成后硬编码吧）15%

4. 配置控件需要的事件，例如button的click事件等。 5%

5. 在声明的事件基础上，根据一定的界面框架接口配置控件、窗体之间的页面流（PAGEFLOW）20%

6. 生成静态代码。

7. 打开静态代码，完善剩余的业务逻辑。 40%

 

然后我再对比一下一个技术落后的界面开发过程。

1、2一般使用了VS的IDE，拖控件、慢慢对位置、改控件的ID，这下子基本上就多出了3倍以上时间了。

3. 不同的代码使用了不同的验证，如果是winform，还要自己硬编码，一下子又3倍时间没有了。

4. 这个倒没什么。

5、6、7 剩下的就是在复杂的页面控件时间搞好关系，很多时候bug就产生了。

 

所以，AUTOUI是可行的。 

 

小结

本文主要分析了AUTOUI的可行性。顺便预告一下，一个基于本文AUTOUI的原型系统已经开发完成了。迟点会拿出来分享！