从许多调查报告上看，开发人员群体对低代码的评估维度集中在几个点上，页面的灵活性、业务逻辑的灵活性和技术架构的专业性。而这几个点也是不同的低代码厂商和产品差异性最显著的畛域。明天，咱们以活字格为例，将眼光聚焦在可视化业务逻辑构建的原理和体验上和大家聊聊。
从 Forrester 在 2014 年提出低代码概念到当初，低代码的定义逐步清晰。
低代码的次要特色是全程可视化开发，实质上讲，是一套元数据驱动的可视化开发解决方案。这里的元数据是一个泛化的概念，不单指数据字段的定义，还要蕴含业务逻辑。业务逻辑在元数据中，次要体现为组件的配置和编排。
组件是低代码中最要害的要害，在不同的产品中，这些组件有不同的名字，比方节点、命令等。低代码平台在学习门槛、利用场景和应用群体的差异化次要源于这些组件的形象水平不同。形象水平越高，应答简单利用场景的灵活性也就越差。与之对应，形象水平偏低的话，必然会引入 IT 技术概念，导致学习门槛显著晋升。所以，低代码内置组件是否引入 IT 技术概念，特地是软件开发概念，是辨别面向技术人员的低代码和无代码（面向业务人员的低代码在市场端正在更名为无代码，是 Forrester 和中软协的共识）的重要标记。
面向业务人员的组件，在设计上偏向于事实中能够看到的货色，比方页面上的元素和操作，如字段、规定、增删改查等。封装档次过高，能笼罩的场景就会变少。通常来说，可配置的我的项目随着封装的档次增长，比方咱们将 4 个各自有 3 个配置我的项目的元素封装在一起，须要提供的选项是 3^4=81。如果封装到第一层，那么提供的配置我的项目只有 3 *4=12。事实中的可配置性远不止这么 3 - 4 个，这种高封装的组件显然无奈提供这种指数增长的配置性，最终也就体现为灵活性更差，可配置性有余了。
走向另一个极其，那就是编码开发中常见的命令式语言和申明式语言。狭义上讲，这两种都能够成为元数据，比方 C# 须要编译成 IL，CLR 加载 IL 来执行动作，这里的 IL 就是元数据。因为封装档次太低，用户对此无奈感知。在命令式语言的根底上，还有一种类型是申明式语言。申明式语言的封装档次有肯定晋升，通常面向特定的畛域，提供足够的灵活性。比方在页面渲染中的 HTML，数据库操作中的 SQL。相比于命令式语言，申明式语言的优缺点很明确，整体上看在当初的软件开发畛域之中应用申明式语言是利大于弊的。
最初补充一下，最后桌面利用开发，不论是 MFC 还是 WinForm，都采纳了命令式语言。起初 WPF、H5、Android、iOS，全都切换成了申明式语言，能够看出申明式语言在界面展现上是有劣势的。
造成这个状况一个不容忽视的起因是晚期的终端设备计算能力太差，很难承当解析的工作；当初交互终端的计算能力越来越强，解析申明式语言的性能开销曾经客户忽略不计了。
回到低代码的话题，低代码平台提供的组件封装是介于业务模型和申明式语言两头的。咱们以驾照辨认为例，形象水平能够简略的分为四层。越往下封装粒度越低，往上越高。不同的低代码平台在这个事件上有什么不一样呢？依照低代码概念提出者 Forrester 的观点，低代码平台能够分为面向业余开发者和业务人员两类。在这个问题上，封装档次有十分显著的差别。前者通常会提供全副四层，而后者则通常提供上两层。
所以，对于面向业务人员的低代码来说，不反对简单的业务逻辑和 WebAPI 构建能力，也就很好了解了。不是技术无奈实现，而是市场定位不须要做。
作为 Forrester LCDP for PRO 的代表产品之一，活字格为简单业务逻辑构建提供了什么样的组件和编排体验呢？首先在设计时，活字格将组件的封装档次下沉到了靠近编码开发的层面，在此基础上提供一些罕用的高层次能力。在体验上，用表达式树的模式，模仿编码开发的缩进层级。
整套逻辑编排机制，能够运行在前端，也能运行在后端。
除了组件和编排，咱们还须要提供一些能够与组件进行交互的函数。为了尽可能多的笼罩多样化的利用场景，函数库的齐备性是一个不小的挑战。.NET 和 VBA 的函数库太过扩散，而且过于宏大了，于是咱们抉择了参考另一个在企业信息化中罕用的计划，Excel。
于是，咱们将 Excel 公式作为范本，实现了 400 多个计算公式。抉择这条路还有一个重要的起因，那就是在过来的 30 年里，咱们在开发 Spread 表格控件的同时，积攒下了一套欠缺的表达式引擎。间接拿过去，放到业务逻辑引擎里，事倍功半，而且成熟度高。如果你本人做相似的性能，也能够应用 SpreadJS，间接调用外面的 CalcEngine。
简单的业务逻辑通常无奈保障一步到位，所以在解决了构建问题后，咱们还须要解决调试和自测的问题。调试是申明式语言绝对于命令式语言的劣势，如咱们无奈调试 HTML 的渲染过程。然而，SQL Management Studio 给了咱们一个解决的思路：将执行日志残缺的打进去。这里的“残缺”，指的是输入每一步的变量，每一个分支条件以及每一个组件的执行耗时，还有对数据库进行操作的所有 SQL 语句。
这种日志岂但能够用于自测和调试，在前期须要保护这段业务逻辑，甚至接手别人开发的业务逻辑时，可视化的表达式树加残缺的执行日志，都能起到很大的作用。
在简单业务能力的根底上，WebAPI 的构建就瓜熟蒂落了。咱们只须要在运行在服务端的业务逻辑的根底上，提供 WebAPI 所需的“壳子”。
介绍到这里，咱们能够明确的感觉到，构建 WebAPI 和简单业务逻辑，用到组件都是面向开发人员的语言体系，这再次印证了面向业务人员的低代码和无代码平台通常不会提供相似性能的判断。毕竟，想要给没有任何 IT 根底的业务人员培训这么一套体系，投入是微小的，回报危险是很大的。
回到产品需要，如果只是开发简单业务逻辑，咱们仿佛无需构建 WebAPI。那么，为什么活字格会专门搞出 WebAPI 构建能力，它能够用来做什么？只是为了做前端后端拆散，让低代码开发和编码开发进行配合？这一点的确重要，这是为咱们团队从编码开发向低代码转型减少了一条更事实的门路，但仅限于此？
答案显然是否定的，WebAPI 最次要的利用场景是系统集成。企业信息化走到明天，每家企业都曾经领有了各类软件应用，如何与这些不同时代，不同技术架构的零碎做集成，缩小数据孤岛？这是低代码平台必须要解决的问题，至多不能造新的数据孤岛。在做集成的时候，除了被动调用其余零碎外，为其余零碎提供 WebAPI 接口，供其调用是很常见的场景。
说了这么多，咱们看一段 8 分钟的视频，直观感受一下，如何构建一个 WebAPI，供第三方调用，如何在 WebAPI 中调用第三方的 WebAPI。
总结一下，明天咱们探讨了低代码与元数据驱动的关系，组件的形象水平与利用场景和灵活性的关系，用来撑持简单业务逻辑的组件设计和编排形式，输入具体日志辅助调试的机制，将业务逻辑封装为 WebAPI 的要点和系统集成的利用场景。最初用一段视频，直观展现了应用活字格构建 WebAPI 的用户体验。
明天展现的活字格低代码开发平台，在官网能够下载免费版。我在几个月前做过一个公开课，具体介绍应用活字格构建 WebAPI 的过程。搭配视频和活字格低代码平台，感兴趣的敌人能够亲自体验一下。
《【掘金公开课】补全短板，走向全栈：低代码开发纯前端或纯后端利用》https://juejin.cn/live/3808810
问答：
Q：宁老师，看了获益匪浅，我有两个问题：（一）低代码工具晋升我的项目开发效率方面有没有曾经量化的指标？（二）如果须要程序员解决自定义的性能问题，是否有对应的开发语言的接入机制？
A：问题 1，我这有几个我的项目的理论案例，效率晋升的幅度次要看我的项目需要的类型，增删改查占比越高，晋升越大。界面精细化要求越低，晋升越大。这里的第二个和第三个，规模相似，复杂度相似，只是因为第三个是面向连锁医美会员客户的，界面要求高，开发效率受到了很大影响；问题 2，低代码平台哪有全靠厂商本人搞的。大多提供各层级的编程接口。让你能够接管、替换任何一次档次，来满足低代码平台内置能力搞不定的场景。前端须要提供 JS 接口，能操作页面元素；后端须要提供 Java/C# 接口，实现非凡 API 集成；数据库端还得反对间接执行 SQL 语句，晋升性能；用户认证层面反对平安接口，实现用户集成。再“高级”一点，还得反对插件接口，能间接扩大低代码平台的能力，提供给本人用之外，还能卖给其余开发者，取得盈利。
Q：这种低代码平台，跟 RPA 厂商的低代码平台有什么区别呀
A：RPA 厂商，低代码是为了裁减本人 RPA 的能力，通常会和本人家的产品或场景深度绑定
Q：我想问一下，低代码是云厂商能力做还是公司本人就能够做？当初看到的基本上都云厂商在做
A：从 Forrester 的报告上看，云厂商只是其中一个分类。只是，互联网大厂的市场宣传能力，切实不是其余类型厂商能够比较的
Q：这个算是以前针对开发人员的代码生成器？放慢开发进度
A：能够了解为，这个是代码生成器的“进阶版”。代码生成器是一次性的工具，一旦在生成的代码上再开发，通常就没有方法再享受可视化的效率晋升了。低代码走了元数据驱动的路线，能够在后续的开发和保护中，始终用可视化的形式进行。
理解更多低代码相干内容：https://help.grapecity.com.cn…