作者：行云创新 杜欣

在今天，“低代码” 技术已经很难被描述为⼀种新兴的技术服务形式了。

“低代码”这⼀概念，早在1982 年，便由 James Martin 在《⽆程序员的应⽤程序开 发》⼀书中正式提出。⽽从 90 年代起，国外在不同的软件开发发展阶段中，都分别研究并尝试推出了对应的低代码解决⽅案。但真正的时间拐点，要来到 2015 年前 后，随着基础技术设施的不断演进，低代码相关技术逐渐露出曙光，且微软、⾕歌等巨头正式⼊局，低代码赛道正式打开。

同期，国内的低代码⼚商也开始尝试布局，2018 年左右，互联⽹巨头阿⾥、腾讯、百度的纷纷⼊局，也间接为整个⾏业奠定了⽅向。据艾瑞咨询《2021 年低代码⾏业研究 报告》中所⽰，截⾄ 2020 年，中国低代码市场共有 59 起融资事件，融资规模达亿元 以上者依然有 13 起之多。⽽同期市场规模也逐年增⾄ 15.9 亿（2020年），据测算， 该市场规模将于 2025 年达到 131 亿，未来 5 年复合增速为52.6%。

截⾄截稿，36 氪企服点评的低代码开发板块中，已录⼊国内⼚商/产品共计 109 款。 种种迹象都表明，低代码市场，已经逐渐⾏⾄中场。

作为⼀种商业服务，低代码⽆疑是明确的，提供完善的可视化开发界⾯，使⽤户能够 以⾮传统开发的模式进⾏应⽤开发，从⽽达成低成本、⾼效率的应⽤开发。但对于真 正的开发模式⽽⾔，低代码这⼀概念却是开放的，市⾯上的产品不论从技术⽅案、使 ⽤⽅式还是应⽤场景⽽⾔，都早已百花⻬放。

那么，什么样的低代码平台才是更适合开发者的呢？我们不妨先从国内市⾯上最流⾏ 的两种低代码平台形态，来聊聊当前的低代码平台。

表单驱动 - 企业信息化的新中台

⼀般认为，表单驱动是作为 BPM 系统的延续者出现的，再向前溯源的话，更像是早期使⽤ Excel 来进⾏数据管理的做法：多个参与者按某种约定，通过在电脑上编辑、 传递⽂档、信息或者任务，来实现指定的业务⽬标。

⼀些从 BPM 系统或者电⼦表格类产品转型⽽来的低代码开发平台，⼤多延续了这种表单驱动的模式。当前市⾯上主要采⽤这种模式的低代码平台，常⻅的有：简道云、 明道云、宜搭、氚云、得帆云等。

表单驱动型的低代码平台⾃出现伊始，就有着明确的客户群体和应⽤场景。如果说当前哪种低代码平台最适合让从未从事过软件开发的⽤户能够快速的完成⼀款⼩应⽤的开发，那么，⾮表单驱动型低代码平台莫属。

表单驱动型平台的核⼼编辑界⾯其实只有两个，表单设计与流程设计，通过对表单的 设计完成对其抽象数据的建模，并同步绑定数据的创建/编辑界⾯，再借由流程设计， 来定义数据的流程状态，以及不同状态下的可操作⾓⾊，字段的可⻅/可编辑权限等。

在业界的通⾏观点中，“表单驱动”具有更低的使⽤门槛和技术门槛，但是应⽤场景的局限性更⾼，通常仅⽤于开发简单的数据填报系统，很难应⽤在企业级应⽤的开发过程中。

在理想化的企业内部使⽤场景中，该平台会由企业中的多个业务部门同时使⽤，每个部门按照⾃⼰的数字化需求来设计表单，同时参与其它部门的表单填写、流传过程。 从⽽使企业中的每⼀个业务相关⼈员都可以在平台上看到与⾃⼰相关的所有表单，作为⾃⼰的⼯作任务项或关注事项。⽽这，也是企业信息数字化的切实需求。

为了满⾜上述场景，表单驱动型的低代码平台的设计思路也就变得明确了。

1. 为了能够让企业的任意⼀个员⼯都能够很快上⼿，平台需要最⼤化的降低实际使⽤者的学习成本。在⽤户使⽤过程中，需要尽量取消抽象的软件设计过程，甚⾄以牺牲灵活性为代价（⽐如界⾯与动态数据的绑定设计），让⽤户能够与企业业务做直接对应，来达成设计⽬的。

2. 最好是单⼀平台 + 多个同构微应⽤的模式。这样才能够有效的聚合信息，让企业信息流转效率上升。单⼀的表单收集型服务（如：问卷星、腾讯问卷等）虽然也能解决信息的收集问题，但对于信息同步，以及流程控制就会显得乏⼒，⽽这却是企业提升信息流转的综合效率所不可或缺的能⼒部分。

⽽表单驱动的局限也同样明显：

1. 受限于表单与数据模型强绑定的设计与使⽤⽅式，在实际使⽤过程中，往往难以设计出拓展性佳、复杂关联的数据模型。⼤量的表单，⼀⽅⾯会形成⼤量的数据冗余（不同的表单设计背后所映射的是相同的业务数据），另⼀⽅⾯⼜容易形成数据孤岛（表单设计过程中的关联性设计缺失，⽆法在其它业务中进⾏数据复⽤）。同时，由于表单与数据模型的直接对应，也使得对数据的展⽰、操作界⾯只能借由当前表单执⾏，难以设计复杂的数据检索与数据交互。

2. 表单驱动型的低代码平台，通常只能处理数据的采集与展⽰，⽽⽆法基于数据进⾏更为智能化、⾃动化的衍⽣逻辑设计。为了弥补缺陷，低代码平台往往会增加 ⼀些可编程界⾯，以便⽤户通过代码途径来解决上述问题。但伴随着编码功能的开放，平台用户的体验也会开始割裂。更真实的情况是，大量对数据建模都算不上擅长的用户，并没有匹配的技术能力来完成代码的编写。

当然，不论如何，在企业数字化场景下，表单驱动型的低代码平台依然能解决⽇常企业业务中⼤部分简单的信息流转需求。但是对于开发者⽽⾔，表单驱动型低代码平台与开发者的⼯作场景却往往是互斥的。

⼀⽅⾯，表单驱动的⽬标⽤户并不是开发者本⾝，甚⾄平台本⾝，就是为了在企业不具备开发能⼒，或降低开发成本时⽽出现的。

另⼀⽅⾯，则是因为表单驱动型平台中，应⽤设计模式较传统软件开发⽽⾔，进⾏了⼤量简化甚⾄是阉割，这导致开发者在使⽤表单驱动型平台的过程中，往往有⼤量的软件设计思想⽆法在平台中实现。

⼀⾔以蔽之，开发者与表单驱动，可能真的没有什么缘分。

模型驱动 - 传统软件开发的模式再造

不同于表单驱动从早期电⼦表格模式的逐步进化，模型驱动则是从传统软件开发模式中提炼和总结⽽来的。

模型驱动型平台使⽤可视化建模技术来定义数据关系、流程逻辑和构建⽤户界⾯，使开发⼈员和业务⽤户能够快速交付应⽤程序，⽽不需要代码。

在当前市场中，如：Mendix、OutSystems、活字格、ClickPass、微搭等，都属于模型驱动的范畴。

相对于表单驱动⽽⾔，模型驱动与开发者可能要亲近许多。如果说表单驱动是为了让不具备开发能⼒的⽤户也能够开发应⽤，那么模型驱动，则是为开发者提供了另⼀套形不似但神似的开发⼯具。

模型驱动型的低代码平台，更像是对传统软件开发模式的业务再造，将⼤量原来只存在于开发者脑海中的设计模式，实际地构建出⽤户界⾯来进⾏设计操作。同时，平台还将开发过程中各环节的设计⼯作进⾏了范式定义，使得各设计模块可以更好的集成。

换个⾓度来说，模型驱动对开发者的软件设计知识要求并没有降低，⽽是改造了编程⽅式，使得以前开发者需要编写代码的⼯作，可以通过可视化界⾯来定义和配置，从 ⽽加速了应⽤开发的过程，提升了整体效率。

以数据模型与⽤户界⾯的绑定⽅式来举例：

在表单驱动的设计中，⽤户需要先进⾏表单设计，当表单确定后，对应的数据模型也会被⾃动推断确认完毕。⾃此，表单就与数据模型完全绑定，表单的修改亦会直接影响数据模型。⽽数据实体也仅⽀持表单进⾏修改。

但在模型驱动的设计中，数据建模与⽤户界⾯设计是完全分离的。⽤户可以⾃由的通 过单独数据模型设计界⾯进⾏建模，并单独利⽤户界⾯设计器进⾏界⾯设计，最后通过平台的数据绑定机制，为指定的界⾯绑定数据模型，以实现最终的数据展⽰。

⽽这种模型驱动的绑定⽅式，与传统软件开发中的 MVC 设计模式，其实保持了⼀致的：分别设计模型（Model）层，与视图（View）层，并通过控制层（ Controller） 层来控制模型层与视图层的绑定关系。只不过，在模型驱动的低代码平台，模型层、 视图层、控制层都可以分别使⽤可视化界⾯直接进⾏设计，⽽⽆需编写代码。

不过，如果在专业开发者的眼中，这可能会有⼀些开倒⻋的嫌疑。

⽆论是表单驱动，还是模型驱动，希望构建的应⽤设计模式都是让模型层与视图层直接产⽣绑定关系。模型驱动相⽐于表单驱动的优势，也在于其⽀持模型的动态拼装， 让模型层与视图层的绑定关系更灵活。

但在真正的企业级应⽤开发中，在模型层与视图层之间，其实还存在着⼀层业务层。 除了控制视图与模型的关系，业务层最⼤的作⽤，在于单独对业务⾏为进⾏了定义。 既可以是由终端⽤户直接与应⽤交互产⽣的业务⾏为，也可以是由系统主动根据数据 模型、业务特征⾃动触发的业务⾏为。

同时，业务层的出现，使得业务⾏为可以单独控制不同数据的处理逻辑，⽐如多重判 断、事务管理、兼容容错等等。这也是软件⼯程领域中对”⾼内聚、低耦合“这⼀设计⽬标的直接实践。

最后，业务层通过对业务⾏为与数据操作进⾏定义，可以极⼤的提升模块逻辑的复⽤ 性。⽐如在常⻅的复杂业务中，往往需要对多个数据模型同时进⾏操作，如果⽆法单 独设计业务层，就只能在不同的视图位置中，重复多次的设计数据模型操作过程，⽽ 重复设计过程中，些许的不⼀致，往往就容易导致更复杂的业务错误。

所以回到模型驱动的语境⾥，诚然数据模型与视图的动态绑定模式，已经像极了传统 软件开发模式，甚⾄在做⼩型应⽤时，开发者已经能够直观的感受到效率提升。但对 开发者⽽⾔，这依然不是最终的⼯具。

业务层的缺失，并不只是业务⾏为定义的缺失。使应⽤更具智能化、⾃动化的运算能 ⼒，也会因此⽆处安放。⽐如对数据的哈希摘要算法、对⼤量数据的批处理算法、⾮ 常规数据的编解码能⼒、条件化定时任务甚⾄是⽤户推荐算法、⽤户画像⽣成、多要 素智能推送等，在传统软件开发中虽然屡⻅不鲜，但在低代码平台中，却⽆处施展， 需要另辟它径。

当然，随着市场发展，相信各⼤低代码⼚商依然会逐步拓展⾃⾝平台的能⼒版图，让 越来越多的应⽤能⼒可以在⾃⾝平台中被开发者使⽤。但⾄少在今天，即便是模型驱 动，也还是⽆法完全满⾜开发者的需求。

第三种可能性是什么？

虽然在国内，低代码平台主要指向表单驱动与模型驱动两⼤类低代码平台，但在海外，⾔及低代码，却是另外⼀番景象。

与国内低代码的普遍认知不同的是，海外更推崇的模式是将低代码能⼒⼯具化，并尽可能做到领域专属，⽽⾮全能。虽然在国外也不乏有 OutSystems、Mendix 这样的⼤ 型低代码平台，但近些年更得开发者⻘睐的，却是⼀些特定领域内的低代码/⽆代码服务。

在资讯⽹站 nocode.tech 中所收录的低代码⼯具中，根据⼯具的能⼒范围，将其分为如表单设计、应⽤设计、市场⼯具、客户⽀持⼯具、分析⼯具、⾃动化⼯具、数据库⼯具等在内的 37 种类型，截⽌⽬前，已收录的低代码/⽆代码⼯具服务超过 200 款。

在⼯具之上，国外也逐步诞⽣了围绕低代码⼯具进⾏应⽤开发的社区、教学乃⾄⾏业。通过使⽤多种低代码⼯具，并借由 API 进⾏拼装，使之形成完整的业务应⽤，也是当今流⾏的低代码开发趋势。有意思的是，为了提升 API 拼装效率，市场中还同步涌现了⼤量⽤于拼装 API 的低代码⼯具，使整体开发效率可以进⼀步的提升。

在国内市场，也逐渐涌现出了类似的服务形态。如低代码电⼦表格服务维格表，就将⾃⼰定位为⾯向 API 的多维表格，⽽软件集成服务集简云，也开始尝试提供国内各在线服务的 API 集成能⼒。

相⽐于使⽤独⽴的低代码平台，选择集成多种低代码⼯具，会极⼤的拓展应⽤的能⼒半径。在单个低代码平台中，其能⼒半径和应⽤设计界⾯都⾼度依赖于平台本⾝。但选择多个低代码⼯具相互集成的⽅案，则可以极⼤的规避这个问题。

同时，使⽤ API 的对接模式，也为业务深度提供了可靠保证。在传统开发中，API 的出现，使能⼒的提供⽅与使⽤⽅真正分离。我们既可以在业务应⽤中直接调⽤ API 实现能⼒，也可以⾃⾏编写代码来接⼊ API 的能⼒，再向业务应⽤提供更合适的 API。 通过这样的业务封装，可以有效的保障业务的层次与隔离性。

不⽌如此，随着微服务架构的流⾏，API 同时也变成了企业⾃研应⽤中的⼀等公⺠。通过 API 来封装能⼒，体现业务，⼜被其他业务进⾏集成，⼀直都是传统开发中的最佳实践之⼀。

所以我们不免会提出这样的假设，当开发者真正迈⼊低代码的领域时，更合理的结合模式，依然是能⼒领域独⽴，API 先⾏，集成性⼤于封闭性的架构形态。

Methodot，API 先⾏的新⼀代开发平台

为了能够让低代码能⼒真正的提升⼀线开发者的⽇常开发效率，⾏云趣码认真的研究 了⼤量市⾯上现有的低代码平台，以及海内外的⾏业趋势。

在开发者世界中，能够快速的补⻬⾃⼰的能⼒短板，但⼜能发挥⾃⼰真正擅⻓的专业领域，⼀直都是开发者最期望出现的研发模式。⽽当前市⾯上的⼤部分低代码平台， 虽然能够达到快速完成特定⼯作任务的能⼒，但平台本⾝的出现，却也对开发者原本擅⻓的领域，形成了限制。

能不能有⼀款平台，可以让开发者在享受低代码⼯具效率的同时，也能通过编写代码和能⼒集成来提升应⽤能⼒的上限呢？如果有的话，那么它不应该是⼀款低代码平 台，⽽是⼀款富含低代码⼯具能⼒的开发平台。

Methodot 正是这样的⼀款⼀站式在线开发平台，平台本⾝内置了多款低代码开发⼯具，也同时具备完整的编程开发能⼒。

在 Methodot 中，开发者可以⾃由的选择使⽤低代码⽅式或是代码⽅式来完成特定⼯作的开发，可以是前端界⾯、可以是数据建模、也可以是 API 集成。与此同时，平台也上架了⼤量的开源低代码⼯具套件，让开发者按需要进⾏集成。

同时，Mehtodot 还提供了微服务架构可视化编辑器，让服务能⼒真正的作为了应⽤设计⼯程中的⼀级对象，⽆论是传统开发，还是低代码开发，是⾃研应⽤，还是第三⽅服务对接，都可以快速的进⾏集成，⽽⽆需担⼼业务系统的拓展性。

不仅如此，Methodot 还深度整合了云原⽣技术能⼒，通过对软件开发模式进⾏完整的再造， 集研发⼯具、交付引擎、运⾏环境三维⼀体，为开发者打造出了新⼀代的研发空间。换句话说，在 Methodot 中，可以同时进⾏代码编写、编译、构建，并直接进⾏部署直⾄对外提供服务，⽆需准备编码、调试环境，更⽆需单独购置服务器资源。

当前，Methodot 已经正式上线，以期为⼴⼤开发者提供传统开发与低代码开发相融合的在线开发服务。

同时，Methodot 已同步推出了免费版本，并保证基础功能完全开放，欢迎⼴⼤开发者前来试⽤。

云原⽣，低代码，写得少，做得快。

这就是 Methdoot，您的⼀站式云原⽣应⽤在线开发平台。

-------------------------

Methdoot，免费体验地址>