共计 1434 个字符，预计需要花费 4 分钟才能阅读完成。
为什么很多开发团队吐槽低代码开发平台，其中大抵归纳了几个方面的起因：
1、应用过后会升高对技术的依赖度，工具人的偏向更加重大
2、目前大部分的低代码都是一次性的低代码，仅仅是在第一次构建模型的时候，能够生成一些根底代码，在零碎可能降级前期保护实质上还是源码开发，没有实质的区别
3、很多优良的低代码开发平台是黑盒，不通明，放心应用后技术被绑架
4、放心低代码开发平台的局限性和扩展性存在问题
……
其实这些问题并不是什么粗浅的问题，第一点是无奈防止的，大势所趋，高效率的工具必定会逐渐渗透到传统的手工打造的行业，这个也是当初大家很少能看到“铁匠”的起因。第三、四点，以 JVS 疾速开发平台为例，是能够提供源码级交付的，就不必放心，且整体框架反对“零代码”+“原生代码”的交融开发模式（这里就不深刻解说实现形式），所以不是问题，那么咱们明天具体捋一捋第二条，一次性的低代码和继续化的低代码的关键点在哪里？
聊这个问题之前，先要聊下“数据长久化”让低代码触手可及，以 mybatis 为例说一下，它次要在数据库和 java 程序之间构建一套能够疾速操作的规范入口，造成咱们所谓的增删改查（CRUD），能够反对程序通过动静调用的形式去操作数据库，而无需具体的理解数据库的具体 SQL 操作。
如上图所示，mybatis、mybatis plus 把这个过程做得很好，把库表对应的 CRUD 的接口代码做得十分不错，技术人员只须要建库建表与写一些业务逻辑调用，两头机械重复性的工作都交给数据长久的工具去干掉了，这样势必晋升很大一部分的工作效率。
但随着低代码的概念一直继续发酵与升华，有跟多的管理者心愿不仅仅是生成两头的 CRUD 代码，是否把另外两端的代码也生成了，这个也就是“零代码”的出发点了，而且这种模式有个 bug 一旦退出了业务代码后，就很难再进行二次配置化，所以这也成为“一次性”的低代码，如果咱们要实现“继续化”低代码 如何做呢？
以这个为出发点，那么有几个问题是无奈回避的：
1、数据库表须要动静构建，最好是依据界面上的业务需要，主动创立、批改底层的库表接口，数据库表的柔性化就是一个问题。
2、须要将原来的部署代码实现性能转变为配置数据 + 性能动静渲染，实现性能的热插拔，也就是生成的不再是代码，而是配置数据，那么须要构建多个能力引擎把配置数据 渲染胜利能（多个之间如何确定边界，这个咱们能够专门聊聊），从而实现无需启停环境实现性能所配即所得。
3、各个引擎之间如何更好的做好数据联动与参数管制，从而实现业务能力的联动性配置。
咱们再次以 JVS 疾速开发平台为例，JVS 构建了一个套动静的数据模型的引擎，它外围的性能：
1、基于用户配置的性能字段，动态创建、批改底层的数据库表构造
基于表单主动构建库表构造：
基于列表页的主动构建
2、实现多个引擎（列表、表单、逻辑、流程）之间的数据联动应用
数据模型是各个能力引擎之间对数据加工、存储的外围，也是各个引擎能做好联动应用的根底，而且能够做到数据层与页面级的分层级管制。而且有了动静的数据模型，传统的代码（前端、后端）也是能够接入到配置的过程中来，从而实现 0 代码 +100% 代码的交融应用。
3、向低代码配置提供长久化的数据增删改查，那么让整体内能够实现业务逻辑的配置化，通过可视化的操作配置，实现各种服务的能力拼装。
所以，以后的低代码，能启动灵魂且画龙点睛的 是动静的数据模型。
JVS 根底框架开源地址：https://gitee.com/software-minister/jvs
