从遗留项目提取低代码平台

从遗留项目提取低代码平台browise 的诞生文章目录从遗留项目提取低代码平台browise 的诞生引子提取什么1. 元数据驱动 SQL 引擎ea-component2. 报表模板引擎FileUtil.print3. 32 个前端 UI 组件怎么提取不修改原文保持包名不变砍掉过时的依赖重写而非迁移的模块额外新写的部分前端核心层7 个 TypeScript 文件通用工具4 个 Java 文件Demo含报表接口最终架构一点经验引子我手上有两个项目VedioCall2004 年起的政务框架一路从 Struts 1 演进到 Spring Boothnxnb2017 年基于 VedioCall 的社保系统72 人月交付 200 人月工作量两个项目里都跑着一套叫browise的自研框架。这套框架没有独立版本号、没有单独的仓库、没有文档——它只是散落在各个项目里的 Java 文件、JSP 标签、JavaScript 脚本。2024 年我接到新任务做一个新项目。业务不同但底层需求一样——CRUD、报表、工作流、表单。面前两条路A. 重新选型Formily / Avue / Amis然后开始适配B. 把 browise 提取出来变成一个独立平台我选了 B。不是情怀是算过账的提取成本约 2 周适配任何一个第三方框架至少 4 周而且第三方框架不覆盖元数据 SQL 引擎和脏标记 RowSet这两块最核心的能力。提取什么一个遗留框架散落在项目里第一步不是写代码是考古。翻阅 VedioCall 和 hnxnb我圈出了必须保留的部分1. 元数据驱动 SQL 引擎ea-component这是整个框架最值钱的部分。它做的事情是你配置一条 SQL 定义存数据库表里引擎自动生成 CRUD 分页 8 种数据库兼容。比如你配一条查询SELECT * FROM EMP WHERE NAME #name#引擎会自动解析参数绑定自动处理分页Oracle 用 rownumMySQL 用 LIMITSQL Server 用 row_number()自动处理加密字段的加解密自动处理敏感字段的脱敏所有 metadata 缓存在 memory 里这套代码在 VedioCall 里叫ea-component结构是三个 Maven 模块ea-core引擎内核ea-spring-boot-starterSpring Boot 自动装配ea-adapter-browiseDataSource 连接提供者32 个 Java 文件分布在三个模块中。2. 报表模板引擎FileUtil.printVedioCall 的 FileUtil.java 有 2805 行核心是一个叫print()的方法。它的机制是读一个 Excel 模板文件识别单元格里的~$#^标记动态填充数据生成新 Excel。~dsName.colName → 多行展开一行数据生成一行输出 $dsName.colName → 单行取值取第一条数据 userName → 系统变量 ^anything → 隐藏行注释用这套语法设计师 2012 年就用了解决了每个报表都要写 Java 代码的问题。3. 32 个前端 UI 组件从 TextBox、ComboBox 到 MetaGrid、MetaTree一共 32 个 Dojo 组件。组件本身不值钱Element Plus 里全有值钱的是绑定协议和字典集成。怎么提取不修改原文这是最重要的原则。ea-component 在 VedioCall 里已经稳定运行了几年修改原文等于在不稳定的基础上搭建新系统。万一改坏了影响的是生产系统。做法复制。把 ea-core、ea-spring-boot-starter、ea-adapter-browise 三份代码复制到新项目的browise-metadata模块中合并成一个模块。原文留在D:\work\ea-component\作为只读参考。保持包名不变复制代码时包名全部保留com.browise.ea.core.*。不做重构式迁移——改包名除了让 diff 难做没有任何好处。砍掉过时的依赖VedioCall 的报表引擎依赖了 jxlJExcelAPI这个库只支持 .xls 格式2009 年就停止维护了。提取时做了一次升级jxl → Apache POI 5.2.5。好处支持 .xlsxPOI 还在活跃维护5.2.5 是 Java 8 兼容的最新版本重写而非迁移的模块前端 32 个组件和核心数据层RowSet、绑定、字典没有从 Dojo 原文迁移——它们是全新编写的。为什么Dojo 的 JavaScript 和 Vue 3 的 TypeScript 差异太大逐行迁移不如重新实现。但设计不变——保留了绑定协议、脏标记、三缓冲的概念只是换了一套实现语言。额外新写的部分前端核心层7 个 TypeScript 文件useRowSet.tsRow 类 RowSet脏标记版本在浏览器端跑useCenter.tsStore 管理器对应 Dojo 的 DataCenteruseBinding.tsprovide/inject 绑定协议useDict.ts字典中心httpClient.tsaxios 封装通用工具4 个 Java 文件Result.java统一 API 响应BrowiseException.java异常封装StringUtil.java字符串工具DesensitizeUtil.java数据脱敏Demo含报表接口一个 Spring Boot 启动类 一个 ReportController验证后端可以跑起来。最终架构browise/ ├── browise-common # 通用工具4 Java 文件 ├── browise-metadata # 元数据 SQL 引擎32 Java 文件从 ea-component 复制 ├── browise-report # 报表引擎7 Java 文件参照 FileUtil.java 重写 ├── browise-demo # 演示应用含报表接口 ├── browise-vue # 前端约 50 个源文件 ├── browise-crypto # 骨架 ├── browise-data # 骨架 ├── browise-dict # 骨架 ├── browise-workflow # 骨架 ├── browise-formbuilder # 骨架 ├── browise-notify # 骨架 ├── browise-spring-boot-starter # 骨架提取的ea-component32 Java 文件→ browise-metadata参照重写的FileUtil.print ToPDF → browise-report全新编写的前端全部 browise-common browise-demo骨架待做的crypto / data / dict / workflow / formbuilder / notify / starter一点经验从遗留项目提取平台比从零造轮子更难。难在两点第一要分得清核心资产和历史债务。不是所有在生产系统里跑的代码都值得提取。table布局写的 JSP 页面不值钱但 binding 协议值钱。日志输出的工具类不值钱但 SQL 引擎值钱。第二要有克制力。提取时总想顺便重构、顺便升级、顺便改包名。克制住。先保证提取出来的东西能编译、能运行。改进是提取之后的事。第三篇文章聊32 个 Vue 组件的设计取舍——为什么不用 adapter 层、为什么 options 通过字典中心、为什么提供 23 种字段类型。