如何在低代码平台上构建应用程序

意味着从四个核心层（数据模型、用户界面、业务逻辑和访问控制）组装业务应用程序，而不是手动编写每一行代码。例如，4D 项目作为编译后的桌面、客户端服务器或 Web 应用程序从单个代码库发布，因此小型 IT 团队可以在几周而不是几个季度内从表设计到部署应用程序。

• 在考虑构建应用程序的工作方式时，每个业务应用程序（无论是低代码还是手动编码）都会简化为四个层面：数据所在的位置、用户如何查看和编辑它、在其上运行什么规则以及允许谁接触它。
• 如果你弄错了，数据模型是最容易过时的决定——首先规范化，故意非规范化，永远不要让表单决定你的表结构。
• 值列表、选择字段和查找是任何应用程序中最便宜的提升可靠性的低成本方案：它们在输入点阻止不良数据，而不是稍后清理它。
• 低代码平台以灵活性换取速度。在提交之前了解应用程序的哪些部分是真正自定义的，因为这就是天花板所在的地方。
• 部署模型（桌面、客户端-服务器、Web、移动）是一个设计决策，而不是事后才考虑的细节——它改变了您处理并发、会话和离线使用的方式。
• 一个可用的应用程序胜过一个完美的模式。发布一个功能精简的第一个版本，观察人们如何实际使用它，然后扩展。

“构建应用程序”的实际含义

了解构建应用程序的工作原理是将业务问题转化为人们日常使用的软件的过程，而软件部分通常只占工作的一小部分。较大的一半是决定应用程序必须做什么、必须拒绝做什么以及每个决定由谁负责。跳过这一步的团队最终会重建同一屏幕三次，因为没有人就“客户”是什么达成一致。

低代码和无代码工具改变了这项工作的经济性。 AppSheet、Base44、Figma 的 AI 应用构建器和 Flutter 都从不同的角度解决同一问题：AppSheet 依赖于已有的电子表格和数据库，Flutter 的目标是需要 iOS 和 Android 代码库的开发人员，而 4D 则处于中间位置 - 一个关系数据库引擎，带有可视化表单设计器和完整的编程语言（当您需要时）。正确的选择更多地取决于数据所在的位置以及应用程序启动后由谁维护，而不是功能。

任何应用程序的四个层

第 1 层：数据模型

在考虑构建应用程序的工作方式时，数据模型是描述您的业务的一组表、字段和关系。在 4D 中，您可以在结构编辑器中进行定义：每个表包含具有特定类型的字段（文本、整数、实数、日期、时间、布尔值、图片、BLOB、对象）的字段，并且表之间的关系被显式声明，以便数据库引擎强制执行它们。良好构建的模型意味着发票行不能没有发票而存在，并且当订单引用客户时不能删除客户。

三个规则最重要：

1. 一个事实，一个地方。 如果客户的地址同时存在于“客户”表和“发票”表中，他们将在一个月内出现分歧。
2. 对关系建模，而不是对报告建模。 多对多关系（例如，产品到供应商）需要一个联接表，即使您的第一个报告仅显示一侧。
3. 谨慎选择键。 自动递增整数快速且简单； UUID 在数据库之间的合并中仍然存在。根据您是否会合并来自两个系统的数据进行选择。

关系设计不是低代码发明——它来自 E. F. Codd 的关系模型，并且范式（1NF 到 3NF）仍然描述您将遇到的故障模式。如果您上次正式接触维基百科是在几年前，那么关于数据库规范化的维基百科文章是一个合理的回顾。

Related: Airtable — A spreadsheet-simple interface sitting on top of a real relational database, with automations, views, and shareable interfaces..

第 2 层：用户界面

用户界面是数据模型与实际人类相遇的地方，也是大多数应用程序项目成功或失败的地方。当用户知道两个字段时要求输入十二个字段的表单将被放弃。显示 4,000 行且没有筛选器的列表将滚动一次，并且永远不会再次打开。

在 4D 项目中，表单以可视方式设计并绑定到表或变量。实际的决定是：

• **输入表单与显示表单。**数据输入形式应该狭窄且连续；审查表格可能很密集。
• 列表与详细信息。 为用户提供一个可搜索列表，然后是一个详细视图 - 而不是一个巨大的可编辑网格。
• 默认值优于提示。 预填写今天的日期、当前用户、上次使用的部门。您设置的每个默认值都是您保存一百次的击键。
• 验证放置。 在表单中进行验证以获取即时反馈，并在数据层中再次进行验证，以便导入和 API 调用无法绕过它。

第 3 层：业务逻辑

业务逻辑是一组规则，使您的应用程序不仅仅是一个数据输入屏幕：计算总数、应用折扣、生成文档、发送通知、执行审批链。这是低代码平台差异最明显的地方。

If you are shopping: Zoho Creator — A low-code app builder that plugs into the wider Zoho suite and prices per user rather than per app..

电子表格优先的工具通过公式和自动化处理逻辑。可视化构建器通过事件处理程序和工作流程步骤来处理它。具有真正编程语言的平台（4D 使用自己的语言，Flutter 使用 Dart）可让您在视觉路径耗尽时编写任意代码。诚实的权衡：可视化逻辑的构建速度更快，并且对于非程序员来说更容易维护，但一旦规则具有多个分支，它就会变得难以阅读。当工作流需要八个条件和一个循环时，代码胜出。

第 4 层：访问控制和部署

访问控制回答两个问题：谁可以查看哪些记录，以及谁可以更改它们。大多数小团队应用程序至少需要三个角色 - 管理员、编辑者、查看者 - 通常还需要第四个角色，因为“只能看到自己部门的记录”。行级过滤是团队忘记的部分，也是导致事件的部分。

部署是最后一层。 4D 应用程序可以作为单用户桌面应用程序运行，也可以作为许多用户共享一个数据库的客户端服务器系统运行，或者作为为浏览器提供服务的 Web 应用程序运行。每个选择都会改变您的并发模型、备份策略以及推送更新的方式。客户端-服务器为您提供集中的数据和真实的交易； Web 部署让您无需安装任何东西即可实现；桌面部署为您提供了简单性，但代价是协调性。

选择平台：标准列表

标准	问什么	为什么这很重要
数据所有权	数据的物理位置在哪里？我可以将其导出为标准格式吗？	迁移成本才是真正的锁定，而不是许可
逻辑天花板	当视觉规则用完时，我可以编写自定义代码吗？	确定应用程序是否能在第二年生存下来
部署选项	桌面、客户端服务器、Web、移动设备——支持哪些？	改造部署模型成本高昂
线下行为	网络掉线时会发生什么？	现场和仓库应用程序失败却没有答案
整合	REST、SQL、文件导入/导出、webhooks？	大多数应用程序必须与其他东西对话
维护模式	当构建者离开时谁来修理？	公民开发的应用程序通常比其作者的任期更长久

在考虑构建应用程序的工作原理时，最后一行值得强调。构建真正有用的应用程序的公民开发人员已经创建了一个生产系统，无论是否有人这样称呼它。从第一天开始就做好移交计划：记录表格，清楚地命名事物，并保留应用程序强制执行的规则的书面列表。

关于如何构建应用程序的实用构建序列

第 1 步 - 用一句话写出问题陈述。“跟踪设备借用以及谁拥有每一项”是一个可构建的范围。 “改善运营”则不然。

第 2 步 — 列出名词和动词。 名词变成表格；动词变成动作。这是老式的领域建模，但它仍然有效。

Related: Knack — A no-code database builder aimed at portals, directories, and internal tools — with flat-rate pricing instead of per-user fees..

第 3 步 — 绘制出交付时必不可少的三个屏幕。 通常是列表、详细信息/编辑表单以及搜索或仪表板。其他一切都是第二版。

第 4 步 — 构建数据模型并加载真实样本数据。 十个实际记录暴露了一百个空行永远不会暴露的设计缺陷。

第 5 步 - 连接值列表和查找。 选择字段、下拉列表和关系选择器是整个应用程序中价值最高、最省力的功能。它们可以防止因拼写错误导致的重复，从而使报告毫无用处。

Our pick: Claris FileMaker Pro — The long-running relational database platform for teams that need custom apps on desktop, web, and mobile from a single file..

第 6 步 — 一次添加一个逻辑规则，每条规则后进行测试。 批量构建五个规则，然后进行调试比顺序构建它们要慢。

第 7 步 — 设置角色并测试每个角色。 以受限用户身份登录并确认他们看不到不该看到的内容。

第 8 步 — 部署到一个小组，然后扩大范围。 三到五人的试点小组将找到您从未想过的缺失字段。

构建应用程序时的常见错误

在考虑构建应用程序经常出错的原因时，请避免以下陷阱：

让表单驱动架构。 如果屏幕需要字段，那是 UI 问题，不会自动更改表。添加列来满足一种布局是数据库腐烂的原因。

跳过删除规则。 决定删除父记录时会发生什么。级联、限制或孤儿——为每个关系选择一个并将其写下来。

将验证视为可选。 每个重要的字段都需要一条规则。自由文本“状态”字段在一个季度内变成具有相同值的六种拼写。

忽略第二个用户。 单用户应用程序在并发性方面可能很草率。当两个人编辑同一条记录时，您需要一个策略——记录锁定、乐观检查或故意做出最后写入获胜的决定。

在数据之前构建报告。 基于不一致数据构建的仪表板会让人们不信任应用程序，并且很难重新赢得信任。

跨平台构建应用程序有何不同

当您的数据已经存在于电子表格中并且您的规则很简单时，在电子表格支持的工具上构建应用程序的速度最快。在 Flutter 等开发人员框架上构建应用程序可为您提供像素级控制和本机性能，但代价是为每个屏幕编写和维护代码。在以数据库为中心的低代码平台（如 4D）上构建应用程序介于两者之间：您将获得真正的关系引擎、可视化设计器以及用于需要它的部分的编程语言。

关于构建应用程序有何不同的决定性问题不是“哪个最强大”，而是“这个应用程序在十八个月内需要什么？”如果答案涉及复杂的权限、多表事务或与现有 ERP 的集成，那么具有真正数据库的平台将为您节省重写的时间。如果答案是“通过电子邮件发送 PDF 的简单表单”，那么几乎任何方法都可以，您应该选择您的团队可以维护的表单。

资料来源和进一步阅读

• 低代码开发平台 - 维基百科：低代码开发平台 (LCDP) 提供软件开发环境 - 通常是图形用户界面 (GUI) - 涉及很少或根本不需要编写…

常见问题

构建应用程序通常需要多长时间？

一个专注的内部应用程序（一组核心表、一些表单、基本角色）通常在低代码平台上需要几天到几周的时间，具体取决于涉及的业务逻辑量。数据模型和规则比屏幕花费的时间更长。与外部系统集成或需要离线支持的应用程序需要更长的时间，因为这些部分需要真正的工程而不是配置。

我需要知道如何编程来构建应用程序吗？

不，对于一大类内部工具。可视化表单设计器、值列表和工作流构建器涵盖数据输入、查找和无需代码的简单批准。当您需要自定义计算、复杂的条件逻辑、API 集成或大型数据集的性能调整时，编程就变得很有必要。许多成功的应用程序都是 90% 配置和 10% 代码。

低代码和无代码有什么区别？

无代码工具假设构建者永远不会编写代码，并通过限制功能来实现这一承诺。低代码工具提供可视化构建块，但当可视化路径耗尽时会暴露脚本或编程层。实际差异在第二年就显现出来了：无代码应用程序达到上限并被替换，而低代码应用程序则得到扩展。

我应该构建自定义应用程序还是使用现成的产品？

当您的流程真正独特或数据必须保留在您自己的数据库中时，自定义应用程序更具优势。当您的流程（会计、电子邮件、项目跟踪）标准化时，现成产品更具优势，因为您继承了它们的维护和合规工作。昂贵的中间立场是购买产品，然后对其进行大量定制，导致您最终还是得承担维护工作。

构建应用程序时最重要的步骤是什么？

建立正确的数据模型是杠杆率最高的步骤，因为每个表单、报告和规则都是建立在其之上的。好的模型能够优雅地吸收新的需求；一个糟糕的模型会迫使变通办法成倍增加。在设计任何一个界面之前，请多花一天时间规范化表格并定义关系。

小型 IT 团队能否长期维护自定义应用程序？

是的，如果该应用程序已记录并且该平台是团队能够招到相关人才的平台。保留一份书面数据字典，一致地命名表和字段，并避免一个人的知识孤岛。风险不是代码中的技术债务，而是构建它的人的离开，这就是为什么在小团队环境中移交文档比优雅的代码更重要。