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

时间:2024-03-03 19:40:23

 

前言

本文论证了动态生成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的原型系统已经开发完成了。迟点会拿出来分享!