本h觉得写得很有道理Q值得学习?strong>
转自【IT168知识库?/strong>
表单自定义功能看似非常方便,可以不用写代码即可完成表单的开发设计,表面上看的确是减不开发成本,但深入研IӞ发现是有不少误区的?/span>
1?span> 对于整体成本来讲Q当表单自定义功能能满实际客户需求的60%Ӟ会ؓ另外?/span>40%需求付出多成本。现实中所见到的表单自定义工具一般至多能满实际客户需求的50%。一般容易实现的仅布局、字D늚增减、简单的脚本控制{,但有很多诸如复杂脚本控制、自动计、特D逻辑验证、主从关p,复杂基础数据选择Q过滤、合qӞ、与其它功能模块的交互等{需求,自定义工具都不能实现。最l可能带来的代h是重做,甚至推翻整个pȝ架构重新实现Q付出成本是预计成本?/span>2-4倍以上均有可能;
2?span> 表单自定义功能实现的方式一般是数据库表中预制了很多字段或者是一个表中的记录存储?/span> ID、字D名、倹{字D늱型,而且值的cd往往是字W型Q这些做法给数据的查询统计及SQL优化带来的是非常大的性能损失和阻力,业务pȝ数据量不大的时候看不出Q一旦数据业务表大到一定程度的时候,性能瓉׃出现。我们知道需要工作流的业务系l都是大量用户和大规模业务数据的。对于表单自定义做法Q性能瓉是一定要考虑的;
3?span> 表单自定义往往实现的是一个数据实体的增、删、改Q但对于一个系l来讲一个表单仅仅是一个功能点而已Q这个功能点对于整个pȝ来讲q不是那么单U的Q有可能一个数据实体的资料分别在多个表单里q行更新和维护,自定义逻辑往往是处理不了它们之间的冲突Q还有查询和l计分析Q这些是需要关联很多基数据、关联其它业务数据。自定义表单功能本n也只是从功能Ҏ的角度d发,对于pȝ复杂的实体关pR业务模式、设计模式的支持几乎为零Q一个高质量pȝ需要的因素基本实现不了Q?/span>
4?span> 我们企业使用表单自定义工L时候往往已经有了很多的系l,比如HR?/span>CRM甚至ERPpȝQ我们很多关联数据会是来自于q些pȝ的数据。表单自定义工具往往无法提供高可靠性的集成ҎQ即使能集成也是勉强的,后箋会付出很多手工同步、统计口径不一致等代hQؓ企业整体的信息化效果大打折扣Q?/span>
5?span> 另外从实际的使用情况而言Q我们实C个表单自定义功能的目标往往是ؓ了方便用户实现自q业务逻辑Q但实际上很客户会自己去自定义q些表单。而开发h员都会热忠于实现一个表单自定义工具Q但不会愿意长期d表单的定制工作,从开发h员的成长角度来说是不利的。对于团队的理者来说用E序员的工资d表单配置工作也是不划的Q?/span>
6?span> 透过q些现象的分析,假如我们一定要dC个好的表单自定义工具Q一定是有很多事件接口的、一定是要能支持调试的、布局一定要能有_的细致、自定义q程中要有提供给业务人员的自动向|比开发h员需要的向导更加ȝ化)、一定能做到_的优化或支持优化的实现、能支持~存、调用程序集、从WebService获取信息、能寚w面交互过E进行优化。。。。。。这些都实现后,会发现做的表单定义工具其实就是大软g公司研发?/span>IDE开发环境,如:visual studio开发环境,我们是否有这个能力呢Q?/span>
表单自定义工具在软g投标q程中实现快速原型有帮助Q但实际应用pȝq是需要用大厂商提供的开发工兯行开发,假如一个表单自定义工具真那么容易实现的话,而且那么有用的话Qؓ什么微软?/span>IBM{公怸dq样的工具呢Q?/span>