sprite自定义表单引擎介绍

• .net core研发的自定义表单引擎，采用强大的规则引擎将所有的业务串联起来的，和其他低代码平台是有本质的区别，很多低代码平台不管介绍得有多花哨，界面有多炫酷，本质上还是解决部分复制粘贴的问题。
• 这里的自定义表单引擎绝对不是仅仅解决复制粘贴的问题，目标是完全解放繁琐的CRUD工作。
• sprite自定义表单引擎设计的目的不是给最终客户使用的，而是用于给软件研发的企业降低企业成本，特别适用于项目比较多的公司以及有资源有想法的想要轻资产起步的初创公司或者个人，也特别适用于一些外包的项目，适用于各种ToB的项目，因为能够切实的省去软件研发的绝大部分成本。另外，ToC的项目不一定适合。
• 最佳实践：请结合体验网站和wiki文档实践操作。

文档说明

• 架构设计参考：https://www.cnblogs.com/spritekuang/p/14032899.html
• 表单应用案例：https://www.cnblogs.com/spritekuang/p/14970986.html
• 工作流自定义表单应用案例：https://www.cnblogs.com/spritekuang/p/14970992.html
• 后端开源地址：https://gitee.com/kuangqifu/sprite
• 前端开源地址：https://gitee.com/kuangqifu/spritefronts
• 体验地址，（首次加载可能有点慢，用的阿里云最差的服务器） ：http://47.108.141.193:8031 体验网站说明文档： https://gitee.com/kuangqifu/sprite/wikis/pages?sort_id=5747937&doc_id=2778937
• Wiki文档地址 ：https://gitee.com/kuangqifu/sprite/wikis/pages
• 自定义表单系列文章地址：https://www.cnblogs.com/spritekuang/
• 流程引擎文章地址（采用WWF开发，已过时，已改用Elsa实现）：https://www.cnblogs.com/spritekuang/category/834975.html
• QQ：523477776

体验网站技术清单

• 服务器采用阿里云1核2G，Linux8，Docker部署
• 后端采用的是Abp Vnext，net5，自定义表单部分采用自己封装的一套DDD开发框架，流程引擎采用Elsa
• 前端采用Vue2.X开发，前端框架及控件采用vue ant design实现，前端控件参考网站：https://2x.antdv.com/components/overview/
• 数据库采用Mysql
• 文件存储采用fasfdfs
• 缓存采用Redis+项目内存
• 消息队列采用Rabbitmq
• Job调度采用quartz
• Excel导入导出采用NOPI
• 流程跟踪图采用jsplumb

使用说明

后端

1. git切换到dev版本
2. 后端VS打开项目文件 > 03_form\CK.Sprite.Form\CK.Sprite.Form.sln
3. 设置CK.Framework.HttpApi.Host为启动项目，直接运行项目，数据库连接信息已经在配置文件appsettings.json里面，可用其他数据库连接工具直接打开（外网公共的数据库资源，请不要乱操作数据库，定时还原）

前端

1. 运行前，确定VUE_APP_Form_URL变量是否与后端启动的端口一致
2. yarn install
3. 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的发布订阅功能，只要在任何地方改变了表单定义信息，其他地方都会自动刷新本地站点的内存中的表单定义信息。

特殊说明

1. 自定义表单引擎前端部分也是非常重要且复杂的，不要用Angular来实现，限制太多。
2. 流程引擎最开始采用WWF开发，现在采用Elsa全部重新开发。Elsa代码用的是1.X版本，整体代码感觉有些乱，但核心流程流转部分设计的还是非常优秀，能够方便的满足审批流程的各种扩展需求，对Elsa的代码进行了优化，比市面上绝大多数流程引擎更加轻量且实现更强大功能，暂时不开源，流程引擎这块自己理解还是比较深刻，对这块感觉兴趣可私下交流。
3. 前端后端开源不仅仅是自定义表单部分，其他关于框架和组件的设计实现都可以运行到实际的项目中，比如轻量级的后端框架、Job管理、Excel导入导出、低代码的后端开发、低代码的前端设计等等。

心路历程

• 坐标成都。
• 搞技术这块来说，软件技术迭代更新太快了，要想在所有领域都达到一定的深度显然是不可能的，保持技术上的一个广度无可厚非，对于架构、框架、组建化的设计思想，永远都不会过时，另外，毕业工作一段时间之后，一定要总结自己的优势，向自己擅长的领域深入，那么这就是你的风口，站在风口，很容易起飞的。
• 对于个人来说，多数时间还是码农的身份，在互联网公司呆过，在外包公司呆过，运用别人写的流程引擎做过业务开发，在深圳某个公司带着几个人用WWF做过Winform版本和传统工作流引擎的研发，当时公司的项目有很多审批业务，对流程引擎依赖度特别高，自定义表单这块也想做，但有个先来后到，最后流程引擎做出来之后，由于其他原因，自己离职了，自定义表单这块就没往下推动了，辗转了好长时间，发掘很多公司多多少少都会涉及到流程审批的业务，自己个人还是想往这方面深入的发展，所以就回到了起点，从头再来，结果微软的.net core版本居然放弃了WWF，但推荐使用elsa，结果阅读了源码之后，发掘他在核心流程流转方便设计得非常优秀，对于各种自定义活动的扩展非常方便，功能也比较强大，Web流程设计器设计得也是很巧妙，但整体代码还是有些乱，对于持久化这块的设计做得不够好，我对这块做了一些优化，性能上应该会有一些提升。
• 对于自定义表单来说，研发出来后对于公司来说收益非常可观，长期来说，可以节约大量的人力成本，节约项目的研发周期，做得优秀的话，越到后期，项目质量也会更加稳定可靠，项目风险也会降低，但研发难度非常大，所以这块一直是没有勇气去启动研发，大约两年前，终于下定决心，开干！当时看了一些宣称低代码的项目，宣传做得非常得好，价格普遍都不低，拖拽的方式就可以完成一些表单的设计界面，而且有些界面做得也非常的漂亮，但，基本上还是停留在根据界面设计生成一些代码，这些和用T4等模板自动生成一些代码其实没有本质的区别，应该很多人多多少少都会用过一些，但这绝不是自定义表单的范围。做自定义表单建议一定要看一下K2的表单产品功能白皮书，对自定义表单是什么东西，解决什么问题，头脑里面才能有一个清晰的认识。
• 我开发这套自定义表单的时候，很多的的功能设计思想都是参照K2的表单产品功能来设计实现的，都不是凭空想象出来的，所有设想的东西还没有完全的实现，但是整体的架构和框架基本已经实现，常见的业务功能完全可以通过自定义表单实现，一些复杂的业务也可以通过插件扩展的方式接入到表单引擎中。
• 做自定义表单和工作流引擎的出发点还是仅仅是为了几个臭铜板，当时正好联系到我的大学同学，做QT的，应该说是QT界的大佬，互联网上写关于QT的文章应该没人能比得上他，很多人找他做项目，就说跟着他混，他也欣然同意，对自己的技术学习能力从来没有怀疑过，于是果断的走上QT这条路线分支，从头学习C++、QT，中途也完全一个人完成了一个嵌入式的小项目，想想自己都挺佩服自己的。QT不像其他语言，根本没有什么开源的开发框架，什么都要从头开始，最开始的思路也是从搭建框架开始，然后应用到具体的项目中，后面再不断的迭代框架，形成自己的技术资产，QT开发框架也应用到了很多低代码的思想，现在完成一个普通的项目，应该是没有什么问题的，所以自己做的这块自定义表单进展比较缓慢，很长时间处于半停滞状态，重点在QT方向，心想QT方向做为资源入口，有项目之后，自定义表单和流程引擎再不断的发展和进化，结果还是想得太简单了，现在QT方面近乎停滞状态，疫情也有原因，整体中国经济大环境也有原因，反正结果就是不得不停止脚步，QT搭建的开发框架，后面计划也完全开源出来。
• 当然，以上所有都是在工作时间之外做的，因为有两个baby，没有勇气放下所有来做自己想做的事情，另外，QT这块暂时会停滞在那里，后面的业余时间会全部投入到自定义表单这块的研发上面，后面还规划了很多的东西，有兴趣的可以加入进来，有项目合作的当然更是盛好。