表单设计器功能设计.docx

表单自定义设计器

设计思路

表单自定义功能的误区

1、关于本钱：表单自定义一般简洁实现的仅布局、字段的增减、简洁的脚本掌握等，但有很多诸如简单脚本掌握、自动计算、特别规律验证、主从关系，简单根底数据选择〔过滤、合并〕、与其它功能模块的交互等等需求，自定义工具都不能很轻易地解决，最终可能带来的代价是重做，甚至推翻整个系统架构重实现，付出本钱是估量本钱的2-4倍以上均有可能。建议承受对此类简单需求通过关联创立人定义的SQL语句来实现。

2、表单自定义功能实现的方式一般是数据库表中预制了很多字段或者是一个表中的记录存储为ID、字段名、值、字段类型，而且值的类型往往是字符型，这些做法给数据的查询统计及SQL优化带来的是格外大的性能损失和阻力，业务系统数据量不大的时候看不出，一旦数据业务表大到肯定程度的时候，性能瓶颈就会消灭。我们知道需要工作流的业务系统都是大量用户和大规模业务数据的。对于表单自定义做法，性能瓶颈是肯定要考虑的；

3、??表单自定义往往实现的是一个数据实体的增、删、改，但对于一个系统来讲一个表单仅仅是一个功能点而已，这个功能点对于整个系统来讲远不是那么单纯的，有可能一个数据实体的资料分别在多个表单里进展更和维护，自定义规律往往是处理不了它们之间的冲突，还有查询和统计分析，这些是需要关联很多根底数据、关联其它业务数据。自定义表单功能本身也只是从功能特性的角度去动身，对于系统简单的实体关系、业务模式、设计模式的支持几乎为零，一个高质量系统需要的因素根本实现不了；

4、?企业使用表单自定义工具的时候往往已经有了很多的系统，比方HR、CRM甚至ERP系统，很多关联数据会是来自于这些系统的数据。表单自定义工具往往无法供给高牢靠性的集成方案，即使能集成也是牵强的，后续会付出很多手工同步、统计口径不全都等代价，为企业整体的信息化效果大打折扣；

5、?另外从实际的使用状况而言，实现一个表单自定义功能的目标往往是为了便利用户实现自己的业务规律，但实际上很少客户会自己去自定义这些表单。而开发人员都会热忠于实现一个表单自定义工具，但不会情愿长期去做表单的定制工作。对于团队的治理者来说用程序员的工资去做表单配置工作也是不划算的；

6、?假设我们肯定要去实现一个好的表单自定义工具，肯定是有很多大事接口的、肯定是要能支持调试的、布局肯定要能有足够的细致、自定义过程中要有供给应业务人员的自动向导〔比开发人员需要的向导更加傻瓜化〕、肯定能做到足够的优化或支持优化的实现、能支持缓存、调用程序集、从WebService猎取信息、能对页面交互过程进展优化。。。。这些都实现后，会觉察做的表单定义工具其实就是大软件公司研发的IDE开发环境，如：visualstudio开发环境。

鉴于此，我认为公司在此问题上应当保证有足够的人员投入以及开发周期，否则确定会欲速则不达。

系统设计思路

设计的系统初步适用于网上OA系统的自定义表单模块的快速开发，需要结合工作流系统功能，并实现数据导入、导出以及打印功能；同时可以用于公司在软件投标过程中实现快速原型。成熟后可以用于信息治理系统方面的软件开发工程等。

通过表单的定义自动创立/修改自定义数据表，简单数据字段的执行通过设计器的有关表单控件供给用户定义的相关SQL语句来实现。包括几局部：表单定义治理局部、表单呈现/提交局部、表单数据查看/治理局部。

表单定义治理：表单根本信息治理〔表单名称、描述〕、表单存储表字段治理、表单布局设计、表单数据验证定义、表单字段关联/子表单治理、表单字段编辑框行为治理。

表单存储表字段定义：定义表单中用到的数据项，包括字段名、字段类型、长度、默认值、编辑框类型、是否允许为空、是否自增长字段、分组名称、是否在列表中显示等信息。编辑框类型一般有：文本框、文本域、复选框、单项选择框、列表框、时间日期选择、文件上传框等；这里定义的是表单主表字段，留意每张表单仅针对一张表，否则操作多张表的SQL不简洁处理，涉及到主从表的状况可用子表单来处理。

对字段的相关要求还包括：

涉及到字段的权限级别掌握

涉及到字段的自定义下拉列表掌握

涉及到字段的默认值掌握

涉及到字段的多层关联的数据引用掌握,初步实现单层关联应用

需要考虑自定义字段的值参与系统原来的业务规律运算如何设置的问题

初步到达代码级的字段业务规律掌握

虚拟字段的存在,就是表单中并不存在,而只需要从其它地方引用显示的字段

表单布局设计：这一步很关键也是较难实现，简洁的做法是做一个表单模板，那么表单中的数据项说明、编辑框、数据验证就都可以用内部变量来代替，系统可供给自动生成

表单的功能，用户也可以自己手工修改，固然需要供给一个表单设计器，这样使用起来就更便利了。

表单数据验证定义：定义需要验证字段的规章，验证