第三章：整体架构解析

好，咱们进入第三章。这一章我打算把低代码平台的骨架给你拆开看看。说白了，就是前端怎么搭、后端怎么跑、数据库怎么存。我在好几个低代码项目里摸爬滚打过后，发现架构这东西，光看文档是学不会的，得跟着实际代码走一遍才行。

3.1 前端架构：React 还是 Vue？

先聊前端。低代码平台的前端，核心就两件事：页面渲染和组件编排。我个人习惯用 React，因为它的 JSX 和组件化思想跟低代码的「拖拽生成」天然契合。但 Vue 也有它的优势，比如模板语法更直观，上手快。

我建议你根据团队情况选。如果团队 React 强，就用 React；如果 Vue 熟，就用 Vue。别纠结技术栈，关键是架构设计。

3.1.1 核心模块划分

不管用哪个框架，前端架构都逃不开这几个模块：

• 设计器（Designer）：拖拽、配置、预览，这是低代码的门面
• 渲染器（Renderer）：把 JSON Schema 转成真实 UI 组件
• 组件库（Component Library）：封装好的基础组件和业务组件
• 状态管理（State Management）：管理页面数据流和组件间通信

嗯，这里要注意。很多新手会把设计器和渲染器混在一起写，结果后期维护起来特别痛苦。我在项目中就吃过这个亏——一开始图省事，设计器和渲染器共用一套组件，后来想单独升级渲染器，发现根本拆不开。

3.1.2 关键技术选型

模块	React 方案	Vue 方案
拖拽引擎	react-dnd / dnd-kit	vuedraggable
状态管理	Redux Toolkit / Zustand	Pinia / Vuex
表单引擎	Formily / React Hook Form	FormKit / VeeValidate
样式方案	Tailwind CSS / styled-components	UnoCSS / scoped CSS

你想想看，拖拽引擎是低代码的灵魂。我建议别自己造轮子，直接用社区成熟的库。dnd-kit 在 React 生态里表现不错，vuedraggable 在 Vue 里也很稳。

3.2 后端架构：Spring Boot 还是 Node.js？

后端这块，争议比较大。低代码平台的后端，核心是元数据管理和动态 API 生成。说白了，就是用户在前端配好页面，后端要能自动生成对应的数据接口和业务逻辑。

我个人更倾向 Spring Boot，因为它的生态成熟，事务管理、安全框架、ORM 都很完善。但如果你团队全是前端出身，Node.js 也是个不错的选择，开发效率高，前后端语言统一。

3.2.1 后端核心模块

• 元数据服务（Metadata Service）：存储页面配置、组件属性、数据模型
• 动态 API 引擎（Dynamic API Engine）：根据元数据自动生成 CRUD 接口
• 工作流引擎（Workflow Engine）：处理审批流、业务流
• 权限服务（Auth Service）：用户、角色、权限管理

我曾经在一个项目里，把元数据服务和业务逻辑写在一起，结果每次改页面配置都要重启服务。后来我学乖了，元数据必须独立出来，用单独的数据库存储，运行时动态加载。

3.2.2 后端技术栈对比

维度	Spring Boot	Node.js (Express/Nest)
开发效率	中等，需要写 Java 代码	高，JavaScript/TypeScript 快速开发
性能	高，适合复杂业务	中等，适合 I/O 密集型
生态	极其丰富，Spring 全家桶	丰富，npm 包众多
学习曲线	陡峭，需要理解 IoC、AOP	平缓，前端开发者友好

我的建议是：如果要做企业级低代码平台，选 Spring Boot。如果做轻量级、内部使用的工具，Node.js 完全够用。

3.3 数据库设计概览

数据库设计是低代码平台的根基。你想想看，用户拖拽出来的页面，最终都要落到数据库里。设计得好，平台灵活可扩展；设计得不好，改个字段都要改代码。

3.3.1 核心数据模型

低代码平台的数据库，核心就三张表：

• 应用表（application）：存储应用的基本信息，比如应用名称、版本、状态
• 页面表（page）：存储页面配置，包括页面布局、组件列表、事件绑定
• 组件表（component）：存储组件的属性配置，比如按钮的文字、颜色、点击事件

嗯，这里有个关键点。页面配置和组件配置，我建议用 JSON 字段存储。为什么？因为低代码的配置结构是动态的，今天可能只有 5 个属性，明天可能就变成 10 个了。用 JSON 字段，不用频繁改表结构。

3.3.2 表结构示例

-- 应用表
CREATE TABLE application (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(100) NOT NULL COMMENT '应用名称',
  description TEXT COMMENT '应用描述',
  status TINYINT DEFAULT 0 COMMENT '状态：0-草稿，1-发布',
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

-- 页面表
CREATE TABLE page (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  app_id BIGINT NOT NULL COMMENT '所属应用',
  name VARCHAR(100) NOT NULL COMMENT '页面名称',
  route VARCHAR(200) COMMENT '路由路径',
  layout JSON COMMENT '页面布局配置',
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  FOREIGN KEY (app_id) REFERENCES application(id)
);

-- 组件配置表
CREATE TABLE component_config (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  page_id BIGINT NOT NULL COMMENT '所属页面',
  component_type VARCHAR(50) NOT NULL COMMENT '组件类型：button/input/table',
  props JSON COMMENT '组件属性配置',
  events JSON COMMENT '事件绑定配置',
  sort_order INT DEFAULT 0 COMMENT '排序',
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  FOREIGN KEY (page_id) REFERENCES page(id)
);

你看，这个设计很简单，但很实用。我在实际项目中，还会加一个数据模型表（data_model），用来存储用户自定义的数据结构。比如用户想建一个「员工表」，里面有姓名、年龄、部门，这些字段定义就存在 data_model 表里。

3.3.3 数据库设计原则

• 元数据与业务数据分离：元数据存配置，业务数据存用户数据，别混在一起
• 适度冗余：JSON 字段虽然灵活，但查询效率低。高频查询的字段，单独拎出来建索引
• 版本控制：每次发布都保存一份配置快照，方便回滚

3.4 架构总结

好，咱们把这一章串一下。低代码平台的架构，说白了就是：

• 前端：设计器 + 渲染器，通过 JSON Schema 通信
• 后端：元数据服务 + 动态 API 引擎，自动生成接口
• 数据库：JSON 字段存动态配置，关系表存固定元数据

这个架构我在好几个项目里验证过，稳定性和扩展性都不错。你如果从头开始搭，照着这个思路走，基本不会出大问题。

下一章，咱们会深入前端设计器的源码，看看拖拽和渲染到底是怎么实现的。嗯，那才是真正有意思的部分。