表单自定义功能看似非常方便，可以不用写代码即可完成表单的开发设计，表面上看的确是减少不少开发成本，但深入研究，发现是有不少误区的。

1、              对于整体成本来讲，当表单自定义功能能满足实际客户需求的60%时，会为另外的40%需求付出多少成本。现实中所见到的表单自定义工具一般至多能满足实际客户需求的50%。一般容易实现的仅布局、字段的增减、简单的脚本控制等，但有很多诸如复杂脚本控制、自动计算、特殊逻辑验证、主从关系，复杂基础数据选择（过滤、合并）、与其它功能模块的交互等等需求，自定义工具都不能实现。最终可能带来的代价是重做，甚至推翻整个系统架构重新实现，付出成本是预计成本的2-4倍以上均有可能；

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

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

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

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

6、              透过这些现象的分析，假如我们一定要去实现一个好的表单自定义工具，一定是有很多事件接口的、一定是要能支持调试的、布局一定要能有足够的细致、自定义过程中要有提供给业务人员的自动向导（比开发人员需要的向导更加傻瓜化）、一定能做到足够的优化或支持优化的实现、能支持缓存、调用程序集、从WebService获取信息、能对页面交互过程进行优化。。。。。。这些都实现后，会发现做的表单定义工具其实就是大软件公司研发的IDE开发环境，如：visual studio 开发环境，我们是否有这个能力呢？

表单自定义工具在软件投标过程中实现快速原型有帮助，但实际应用系统还是需要用大厂商提供的开发工具进行开发，假如一个表单自定义工具真那么容易实现的话，而且那么有用的话，为什么微软、IBM等公司不去做这样的工具呢？

欢迎访问:.net工作流平台