表单设计器功能设计.pdf

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
表单自定义设计器 1 设计思路 1.1 表单自定义功能的误区 1 、 关于成本:表单自定义一般容易实现的仅布局、字段的增减、简单的 脚本控制等, 但有很多诸如复杂脚本控制、 自动计算、特殊逻辑验证、 主从关系, 复杂基础数据选择(过滤、合并)、与其它功能模块的交互等等需求,自定义工 具都不能很轻易地解决, 最终可能带来的代价是重做, 甚至推翻整个系统架构重 新实现,付出成本是预计成本的 2-4 倍以上均有可能。建议采用对此类复杂需 求通过关联创建人定义的 SQL 语句来实现。 2 、 表单自定义功能实现的方式一般是数据库表中预制了很多字段或者是 一个表中的记录存储为 ID 、字段名、值、字段类型,而且值的类型往往是字符 型,这些做法给数据的查询统计及 SQL 优化带来的是非常大的性能损失和阻力, 业务系统数据量不大的时候看不出, 一旦数据业务表大到一定程度的时候, 性能 瓶颈就会出现。 我们知道需要工作流的业务系统都是大量用户和大规模业务数据 的。对于表单自定义做法,性能瓶颈是一定要考虑的; 3 、 表单自定义往往实现的是一个数据实体的增、删、改,但对于一个系 统来讲一个表单仅仅是一个功能点而已, 这个功能点对于整个系统来讲远不是那 么单纯的, 有可能一个数据实体的资料分别在多个表单里进行更新和维护, 自定 义逻辑往往是处理不了它们之间的冲突, 还有查询和统计分析, 这些是需要关联 很多基础数据、 关联其它业务数据。 自定义表单功能本身也只是从功能特性的角 度去出发, 对于系统复杂的实体关系、 业务模式、 设计模式的支持几乎为零, 一 个高质量系统需要的因素基本实现不了; 4 、 企业使用表单自定义工具的时候往往已经有了很多的系统,比如 HR 、 CRM 甚至 ERP 系统,很多关联数据会是来自于这些系统的数据。 表单自定义工 具往往无法提供高可靠性的集成方案, 即使能集成也是勉强的, 后续会付出很多 手工同步、统计口径不一致等代价,为企业整体的信息化效果大打折扣; 5 、 另外从实际的使用情况而言, 实现一个表单自定义功能的目标往往是为 了方便用户实现自己的业务逻辑,但实际上很少客户会自己去自定义这些表单。 而开发人员都会热忠于实现一个表单自定义工具, 但不会愿意长期去做表单的定 制工作。对于团队的管理者来说用程序员的工资去做表单配置工作也是不划算 的; 6 、 假如我们一定要去实现一个好的表单自定义工具, 一定是有很多事件接 口的、一定是要能支持调试的、 布局一定要能有足够的细致、 自定义过程中要有 提供给业务人员的自动向导 (比开发人员需要的向导更加傻瓜化) 、一定能做到 足够的优化或支持优化的实现、能支持缓存、调用程序集、从 WebService 获 取信息、能对页面交互过程进行优化。。。。。。这些都实现后,会发现做的表 单定义工具其实就是大软件公司研发的 IDE 开发环境,如: visual studio 开 发环境。 鉴于此,我认为公司在此问题上应该保证有足够的人员投入以及开发周期, 否则肯定会欲速则不达。 1.2 系统设计思路 设计的系统初步适用于网上 OA 系统的自定义表单模块的快速开发,

文档评论(0)

kxg2020 + 关注
实名认证
内容提供者

至若春和景明,波澜不惊,上下天光,一碧万顷,沙鸥翔集,锦鳞游泳,岸芷汀兰,郁郁青青。

1亿VIP精品文档

相关文档