企业级自定义表单引擎解决方案（一）总体介绍

　　大家回想一下，有多少软件公司，多少项目，多少初中级程序员在做着CRUD方面的一些重复而繁杂的工作呢？对于公司项目来说，可能60-70%的成本都花费在CRUD方面的开发管理上，对于程序员职业生涯来说，可能也有60-70%的工作也是在做着一些CRUD方面的工作，无可否认，作者也是。
　　如果这些CRUD相关的工作全部省去，对于企业来说，意味着什么呢？自定义表单引擎，就是帮助企业做这样的事情！对于项目开发的核心三驾马车，进度、质量、成本，自定义表单可能都是质的飞跃。
　　对于进度来说，需求明确的情况下，原来开发一个中等复杂的表单，从数据库到后端再到前端，完整开发完成，可能需要几天的时间，如果这些工作全部由自定义表单通过配置自动完成，可能就十多分钟就能完成，项目进度将会大幅度的提前；对于质量来说，传统的CRUD方面的工作工作量大且繁琐，程序员工作年限及能力水平不一，测试能力不一，进度要求不一，管理者能力不一，影响因素非常多，质量往往是不好控制的，但如果这部分工作全部自定义表单完成，只要保证自定义表单配置生成的功能是经过反复验证过的，那这些影响的因素就可以多数排除，大部分质量就能够完全可控；对于成本来说，如果大大减少CRUD的开发管理，对于公司项目来说，可能节约半数的成本；这，自定义表单对于企业来说，将是战略意义上的武器。
　　可能大家接触比较多的是代码自动生成工具，前端后端可能都有。根据规则，从文件或者数据库读取配置信息，生成前端或者后端静态代码，拷贝到项目中，开发人员在做适当的修剪，再加入业务逻辑，编译发布，但，这就是自定义表单么？对企业来说，有多大的用处呢？我也用过一些，但作用真没有想象的那么大，也不是那么方便，这些代码往往是没有生命的，仅仅是把一些繁琐的代码做了简化，往往只是简化了我们码农复制粘贴再批量替换的作用。
　　代码生成工具，不是自定义表单。自定义表单，是有生命力的，他是由非常多的数据建模以及规则引擎串联起来的，数据库、后端、前端，全是运行时根据规则自行计算、执行或者渲染的。接下来作者将写一系列文档，介绍自定义表单的设计、开发供感兴趣的同行学习交流，由于现在做的工作与自定义表单没有任何关系，生活也不允许自己放下一切专门来做这个东西，只能在空余时间来完成，大概半年多的时间，一直持续反复循环做着技术预研、数据建模、定义规则、验证模型、验证规则，现在前端和后端基本能够融合在一起形成一个整体，参考基础原型为K2自定义表单产品功能。
　　目前整体框架及核心代码已经完成，代码将不断的整理完善，未实现的功能也会陆续的完成，后续会在头条和博客园同步持续更新文章。使用说明后端git切换到dev版本 后端VS打开项目文件 > 03_formCK.Sprite.FormCK.Sprite.Form.sln 设置CK.Framework.HttpApi.Host为启动项目，直接运行项目，数据库连接信息已经在配置文件appsettings.json里面，可用其他数据库连接工具直接打开（外网公共的数据库资源，请不要乱操作数据库，定时还原） 前端运行前，确定VUE_APP_Form_URL变量是否与后端启动的端口一致 yarn install yarn serve 或者 npm run serve（如果第一次运行报错，退出之后再次运行即可） 如果不需要运行后端，请将VUE_APP_Form_URL参数改为http://47.108.141.193:8031 站点由之前的SSO改为密码Token认证，后端项目认证直接接入47.108.141.193:8031认证服务器 认证服务、基础数据、流程引擎、消息中心、Job管理等都是调用的47.108.141.193部署的站点，自定义表单部分运行的代码直接调用本地启动项目。 自定义表单将所有表单定义信息都存储到本地缓存的，部署的开源站点和本地的站点都是连接的同一个数据库，但采用了Redis的发布订阅功能，只要在任何地方改变了表单定义信息，其他地方都会自动刷新本地站点的内存中的表单定义信息。
　　本地使用示例
　　wike文档地址：https://gitee.com/kuangqifu/sprite/wikis/pages
　　后端开源地址：https://gitee.com/kuangqifu/sprite
　　前端开源地址：https://gitee.com/kuangqifu/spritefronts
　　体验地址：http://47.108.141.193:8031 （首次加载可能有点慢，用的阿里云最差的服务器）
　　自定义表单文章地址：https://www.cnblogs.com/spritekuang/
　　流程引擎文章地址：https://www.cnblogs.com/spritekuang/p/14970992.html