[低代码探索]"优速搭"一款基于元数据驱动的框架级低代码-理论篇

gd
6,360 阅读14分钟

前言

  随着近几年低代码概念的愈趋火热 🔥，很多厂商都开始自研低代码产品。但大多都陷入普通人不会用，程序员看不起的尴尬境地😨。因此我正在开发一款低代码产品，尝试探索解决目前行业的痛点。虽然目前我的产品尚未完善，但为了避免闭门造车，自用自嗨，也乘着这次机会接收大家的批评与建议🙏。文章内容我会分成多篇系列性的讲解。其中理论系列，主要介绍"优速搭"低代码平台的开发过程与技术选型、涉及的原理等、以及与目前市面上主流低代码零代码平台的比较、以及参考引用的低代码文章的介绍与分析。其中实践系列，主要介绍"优速搭"低代码平台的使用步骤，包括如何零代码在线开发，如何低代码在线Coding，如何高代码离线开发(当框架一样使用)，同时会录制视频放到B站。
  避免标题党，我可是两篇理论与实践一起发布的哦。今天是第一篇，先介绍理论，着急的可以先看第二篇，第二篇有优速搭试用链接。 优速搭低代码平台-理论篇 优速搭低代码平台-实践篇

正文

低代码的设计思想

主流平台的低代码设计思想

  低代码开发平台在设计思想上主要可以分为表单表格驱动和模型驱动两种。
  前者将页面的表单和数据的存储结构合二为一，而后者则与纯代码开发思想接近，实现了数据与表现的完全分离。
  表单表格驱动的典型代表：Airtable、阿里宜搭、字节飞书多维表格、轻流、明道云等。
  模型驱动的典型代表：Mendix、OutSystems、腾讯微搭、阿里Mobi、百度爱速搭、华为AppCube、网易轻舟、金蝶苍穹云、蓝卓SupOS、数睿数据等。
  单纯从列举数量来看，入局模型驱动的厂商更多。事实确实如此，后者在可扩展性上是绝对的优势，如果用户不希望仅仅开发玩具应用，对定制化二次开发有要求的，必然得选择模型驱动。
  当然存在即合理，表单驱动适合那些完全没有开发经验的人群使用，自然很难开发复杂企业级应用。不过在国内似乎表单驱动的低代码厂商知名度更高，融资更多，因为表单驱动号称无代码、人人都是开发者，它所面向的人群更大，人口红利就更大，可能对于国内投资人来说内容不管怎么样，人口红利大来钱更快，就是好产品吧😂。

软件开发思想对低代码的启发

DRY (Don't Repeat Yourself)

  作为程序员多少都了解一些程序设计原则，如 SOLID、DRY、KISS、YAGNI、LoD等等，其中DRY (Don't Repeat Yourself) 就是低代码的核心思想之一，尽可能的功能复用。低代码平台也不是凭空蹦出来的，是在积累了大量的场景化组件后自然形成的一种趋势，主要是内置封装完善组件以及功能模块。但软件没有银弹低代码也有其缺点，由于基于内置组件，内置组件的完善程度也决定了低代码平台的可用度。但现在做个页面谁不是用element-ui、用Antd之类的这些现成的框架的呢?用这些框架本质也是把官网那些参数找到塞到页面里面，个别场景这些框架可能也会不满足我们的需求也会要自己手写组件定制。所以只要低代码平台组件市场生态够丰富，能灵活支持在线离线二开，这个就不算问题。

声明式编程 vs 命令式编程

  这一点是我在看百度大佬发表的 爱速搭设计理念 的一些文章受到的启发。可以看看大佬这篇文章讲解得很好。下面是我自己的理解。
  声明式编程在于目标描述--所写即所得，大大降低了开发难度。从Jquery命令式操作DOM ---> Vue声明式的MVVM双向绑定 就是一种低代码思想的体现，变量改变界面立即生效所写即所得(ps. react其实也一样只是不能直接修改变量而是调用set···)。低代码组件通常对应一份Json形式的 Schema。下面是优速搭原子组件一部分Schema设计。

存储时优速搭原子组件的Schema参考 
 
   {
   //静态属性相当于ui框架官网提供的属性，因为优速搭内置组件也是基于element-plus封装的下面这些静态组件是直接赋值到element-plus等组件的属性上的
    "staticConfig": {
        "type": "Select",
        "componentAttr": {
            "multiple": false,
            "clearable": false,
            "collapseTags": false,
            "collapseTagsTooltip": false,
            "multipleLimit": 0,
            "size": "default"
        },
        "rule": [
            {
                "required": true,
                "trigger": "change"
            }
        ]
    },
    //动态属性会根据参数或接口请求等动态生成上面的staticConfig
    "dynmicConfig": {
        "optionsConfig": {
            "dataFromType": "DictData",
            "labelKeyAlias": "name",
            "params": {
                "moduleCode": "gd_sys",
                "dictTypeCode": "resource_type"
            },
            "valueKeyAlias": "value"
        },
        "onChangeFunc": "const matchedPageTemplateMeta = configObj.metaItemList.find(el=>el.key==='pageTemplate');matchedPageTemplateMeta.isShow=!configObj.formData['id'] && configObj.value==='Page';"
    }
}

  在设计器中右边的属性面板的每个变量对应着组件的属性。下面是"优速搭设计器"截图 2.2页面设计篇-可视化编辑页面.PNG   随着前端各端都已经全面转向声明式UI,(Android的Jetpack Compose、IOS的SwiftUi、跨端的Flutter、Web的Vue React、web图表类的Echart、嵌入式的Qt QML),而Json天然是声明式的，所以用Json定义前端必然是大势所趋。
  说完前端声明式，后端其实也是一样的趋势。Spring Bean的装配从以前的XML解析 ---> 如今到处是注解式编程，正是把声明式编程吸收到Java语言内部。声明式编程还有另一个好处就是侵入性低，比代码级侵入易读得多，更容易重构。

约定大于配置

  这一条原则是被Spring Boot发扬光大的。对于低代码的设计也应该遵循这一原则。下面举一些例子：

  1. 在低代码数据模型维护里面，建了一张表并关联另一张表，在页面设计器里面选择"左树右表组件"时应该需要自动过滤掉其他无关数据源。
  2. 在低代码数据模型维护里面，字段关联字典，这时往往表格组件里显示的是值对应字典的name，表单里面自动需要下拉框并配置好Options。
  3. 在低代码数据模型里面字段类型是时间类型，设计器中选上这个字段在表单里面就默认用日期组件，不要让用户再做多余的操作。
  4. 不要什么都是需要拖拽的，拖拽本来就是一种低效的交互方式，用户就简单做个表格表单也给拖拽，这不是反而多此一举嘛。所以我在考虑设计低代码平台的时候，秉着"能自动推导就不选择，能选择就不拖拽"的原则。什么时候需要拖拽，在多个CRUD组件布局排版时就得拖拽了。什么是CRUD组件在下文马上会介绍。

"优速搭"平台的设计

  在使用过多家低代码平台后，我认为基于模型驱动的低代码目前需要解决概念过多操作繁琐的问题，所以平台的应用设计过程应该职责分离能让不同水平的使用者协同开发，这样就能降低使用门槛，使受众更广。所以我提出了一种基于元数据驱动的低代码方案，主要分为两部分，数据模型的维护、页面的可视化设计。而且平台应该在一个页面就能完成数据模型维护与页面可视化设计，通过按钮切换tab侧边栏功能，就像VSCode、IDEA一样，功能很强大但界面很清爽永远只有一个界面。因为我用了好几家低代码平台，好多都是需要在不同页面里面去操作，跳来跳去很烦。在平台界面设计方面，我是参考了阿里开源的低代码引擎，虽然阿里开源的低代码引擎只有前端部分，但总体界面还是可以借鉴的，所以优速搭平台乍一看与阿里那套长得很像，但实现完全不同。阿里使用React，我使用Uniapp。

操作层面设计

数据模型(两大维护)

  数据模型的维护里面主要分为物理的表维护、字典的维护。一图胜千言，直接上图。

1.1数据篇-数据模型管理.PNG

1.2数据篇-数据建模可视化关联.PNG

1.3数据篇-字典管理.PNG

页面的可视化设计(三大组件)

  页面设计部分主要是对内置组件的使用，内置组件分为三类组件。

布局组件

  用于提供排版等布局功能，控制CRUD组件排版的

CRUD组件

  CRUD组件也称为CRUD容器，就提供增删改查的能力，把生成的前端组件UI元数据 和 组件Data数据注入到内部的原子组件里面。CRUD组件分为按传入内部Data数据不同可分为数组型、对象型。数组型如表格类组件、树组件、移动端瀑布卡片组件，这些都归为数组型。当然不仅仅我是这么分的就上个月底(2022年7月20号)阿里云也发布了一篇 无代码生产新模式探索 讲解内部平台的设计思路，其中一张截图里面隐晦的包括了这两种分类，我就不圈出来了，看你是否眼尖啦👀
阿里无代码探索截图.png CRUD组件具有一定的场景适用性，因为具体场景的交互设计往往比较固定。如，后台管理场景大多是表单、单表、左树右表、一进页面是否请求、点击按钮分页发什么请求都比较模式化固定。如移动端的瀑布卡片下滑，下滑会触发请求，到底了会提示等等，这些都可以内置在CRUD场景组件里。
移动端瀑布卡片下滑

原子组件

  原子组件能够被所有CRUD容器复用的一类基础组件,只封装UI属性或UI事件，不封装接口请求等业务相关的功能，会接收上面CRUD组件传递进来的前端组件UI元数据 和 组件Data数据，进行最终渲染。我在开发自己低代码平台的时候，一直会关注低代码相关文章之类，有很多人在评论里说低代码根本解决不了很多产品经理脑瓜一拍提出复杂联动效果，但我认为只要能取到对应的 前端组件UI元数据 和 组件Data数据，所谓的联动就是去修改对应数据即可，应该不存在实现不了的效果，除非想修改element-plus、 Antd等开源组件 本身也没提供的效果，但这种需求本来就已经过分了哈，你就得自己封装原子组件。

使用体验方面设计

  这里参考Gartner低代码能力要素

Gartner低代码能力要素.jpg   当然目前优速搭尚未完全满足上面所有要求，而且很多功能尚未完善，一个人开发真的是忙不过来呀😫，但我会按着这个方向设计。
  另外基于上面的要求我还加上一些另外的要求，是我看另一篇文章时觉得挺有道理的，MES和MOM的未来，低代码与模型驱动，文章总结成一句话"运行时模型驱动是未来的趋势"。大概这就是上面阿里云那张图片 无代码生产新模式探索 中提到的API推导。这种灵活性很多场景都需要，比如，实施人员突然想在界面里加个字段加个组件输入框之类，可能由于之前设计没有考虑到，这是如果按照传统前后端分离的高代码开发方式，是不是前端后端都得忙活起来，改代码再编译发布，这就太低效了，如果能直接通过web低代码平台可视化操作，然后运行时立即生效，这样体验多棒。我会在后面的实践篇中演示如何用"优速搭"运行时修改生效。虽然运行时生效性能必然比不上传统直接编译的方式，只是会多访问了一次数据库动态拼接SQL或JQL,若加上缓存之类的优化后，性能差别不了多少。

技术选型

  好啦，讲了那么多设计思想，下面介绍下"优速搭低代码平台"用到了哪些技术栈。

前端技术选型

  既然要做低代码，必然需要支持多平台跨端。但目前就算是高代码也没有跨端的统一完美技术方案。因此肯定得对应web端和移动原生端根据相同的Schema去生成对应端的组，起码思路是一样的，就是积累 三大组件 嘛，这是一个大型体力工程😑。当然有些Web端跨端框架支持Android、IOS，但可能性能体验被饱受诟病，要求不高场合可以用用，但最好是转为原生代码。
  Web端有分BAT各家小程序、纯web，满足要求的开源框架就只有两个了。一个是Vue的Uniapp，一个是React的Taro。所以我这里选用Uniapp。但直接用一套UI做跨端，PC端和H5体验差异比较大。因此利用Uniapp的条件编译H5端用uni-ui、PC端用element-plus

后端技术选型

  由于低代码平台是Saas类应用，需要考虑多租户，然而服务器租用是个巨大开销。我之前第一次创业那会儿傻乎乎的租了几台ECS服务器，但业务量没起来，白白在那儿闲置着，给阿里云做了很多贡献😭。现在好了ServerLess的出现让我这种囊中羞涩的穷汉可以低成本得开发项目啦。因此我这里就用了UniApp母公司DCloud提供得UniCloud简直好用得一逼，而且目前还是免费的，感觉DCloud公司还是很用心在推广ServerLess的。虽然过程中遇到些问题，但好在解决了。前面说到多租户我就利用UniCloud账号避免自己设计多租户了，站在巨人肩膀上😁。由于UniCloud利用的是云端数据库类似Mongodb。因此使用上自然与传统关系型数据库不一样。但我这里都屏蔽了数据库细节，云端用MongoDB，源码导出后依然可以线下用MySql、PostgreSql存储。因为优速搭平台云端的后端是基于元数据动态生成接口的。源码导出时会自动根据元数据利用CodeGen得到对应类手写的代码，导出时选择你需要的数据库即可。

8月20日加更

今天刚看到一篇阿里云栖的文章，链接放在下方了。看完后实现思路真的是好接近😱。哎，看来真的是华山一条路，元数据驱动真的会是低代码平台的终极解决方案吗？
一种低代码的建设实践与设计思路

结束

好啦，理论篇差不多讲完了，下一篇进入实践篇，主要以视频形式并会附上试用链接，敬请期待。也希望看到这里朋友顺手点个赞或发个评论支持一下哦。🙏

谢谢观赏.webp

avatar
文章
阅读
粉丝