KES Plus深度体验：当数据库开始“越界“做开发平台

文章目录

- 先扯点背景
- 这个"越界"到底是怎么回事
- - 概念的纠缠
  - 技术架构长啥样
- 从"建表"到"上线"到底要几步
- 内置模块：省事是真省事
- - 系统管理
  - 流程管理
- 运维侧：故障切机和限流
- 放到更大的视角来看
- 踩坑实录：那些文档里没写的东西
- [跟Oracle APEX到底差多远](#跟Oracle APEX到底差多远)
- 我的整体判断

兼容是对前人努力的尊重是确保业务平稳过渡的基石然而这仅仅是故事的起点

先扯点背景

说实话，第一次听说KES Plus这个产品的时候，我内心是有点抵触的。一个数据库厂商跑来做开发平台？这不就是那个经典的"不务正业"嘛。你想啊，Oracle做APEX的时候也被很多人吐槽过，说数据库就该干数据库的事，别瞎往应用层伸。但后来APEX在Oracle生态里活得好好的，甚至成了不少企业内部应用的首选方案。所以这次看到金仓搞了个对标APEX的东西，我就想着，行吧，先别急着下定论，自己摸一摸再说。

摸了大概两周，说实话感受挺复杂的，有些地方确实让我眼前一亮，有些地方又觉得还行但没到惊艳的程度。这篇文章我就把这些真实的体验摊开来讲，不吹不黑。

这个"越界"到底是怎么回事

概念的纠缠

在说KES Plus之前，得先厘清一个概念------什么是"数据库驱动的低代码平台"？这个界定本身就挺混乱的。

你看啊，现在市面上叫"低代码"的产品实在太多了，有些就是拖拽表单+流程引擎的套壳产品，有些是面向业务人员的配置化工具，还有些是给开发者用的代码生成器。KES Plus属于哪种？

我自己的判断是这样的：KES Plus的核心定位是"以数据库为中心的开发平台"，它跟传统低代码最大的区别在于------传统低代码是把数据库当存储用，业务逻辑写在外部（Java/Node）；而KES Plus是把业务逻辑也放进数据库里，用PL/SQL写，然后直接发布成RESTful API。前端就是个壳子，负责展示和交互。

这个定位的选择其实影响挺大的。好处是架构极简，一个请求进去，数据库里直接执行PL/SQL，返回JSON，完事儿了。没有中间件，没有ORM，没有Java那堆Bean和Service。坏处也很明显------你得写PL/SQL。如果你的团队没有PL/SQL的经验，学习曲线还是有点陡的。

但话说回来，在信创背景下，很多甲方原本就有Oracle存储过程的遗产，KES Plus这种"PL/SQL即API"的模式，反而在迁移场景下有天然优势。这个后面细说。

技术架构长啥样

那张架构图（就是附件里那张）信息量挺大的，我拆开来讲。

左侧是三大功能块：快速开发IDE、运维管理、第三方系统集成。右侧是核心技术架构层，从上到下三层------

前端开发层：支持B/S应用、移动端、小程序、C/S应用。底层走RESTful API，JSON做数据载体，http/https协议。

后端业务逻辑开发层：这是核心。业务服务API全部用PL/SQL写，发布成"PL/SQL API-1/2/3"，前端通过RESTful接口调用。同时还有视图、函数、存储过程这些数据库对象。最底下一条黄带子很关键------"基于数据库底层的权限控制体系：细粒度权限控制（支持行、列权限）"。

底层支撑层：安全防护+数据存储，KES、KES RAC、共享存储。

整个架构的核心理念就一句话：数据库就是你的后端。没有Spring Boot，没有Express，PL/SQL写完直接发布成接口，前端调就完了。

从"建表"到"上线"到底要几步

一键生成代码这事靠不靠谱

KES Plus最大的卖点之一就是"建表→一键生成代码→直接用"。我实际试了一下，流程大概是这样的：

先建表，比如我做了个车辆管理模块的表：

sql 复制代码

CREATE TABLE "basicInfo"."t_vehicle_info" (
    id varchar NOT NULL,
    module_code varchar,
    dept_id varchar,
    vehicle_number varchar,
    vehicle_brand varchar,
    vehicle_model varchar,
    production_date date,
    purchase_price numeric,
    vin_no varchar,
    status varchar DEFAULT '在岗',
    PRIMARY KEY (id)
);

建完表之后，在IDE里右键表→"生成代码"，弹出一个配置界面，让你选菜单名称、表单字段映射、查询方式这些。配好之后点"保存&生成"，它就自动给你搞出来这些东西：

后端产物：一个PL/SQL包（包含add/update/del/get_by_id/list/page这些标准CRUD方法）、对应的RESTful接口、权限模板、菜单定义

前端产物：VUE列表页面、表单页面、JS文件和路由

sql 复制代码

-- 自动生成的包规范长这样
CREATE OR REPLACE PACKAGE "basicInfo"."pkg_vehicle_info" AUTHID CURRENT_USER AS
    function add(jsonData text) return json;
    procedure add(jsonData text);
    procedure del(ids varchar);
    function update(jsonData text) return json;
    function get_by_id(id_ varchar) return json;
    function list(jsonData text) return json;
    function page(jsonData text) return json;
    function is_exists(id_ varchar) return boolean;
    PROCEDURE workflowCallback(flowContent JSONB);
    TB_NAME VARCHAR := 't_vehicle_info';
    PK_COLUMN_NAME VARCHAR := 'id';
end;

说实话，这个一键生成的功能在日常开发里确实省事。尤其是那种后台管理系统，80%的页面就是增删改查+列表分页，这种活儿让平台帮你干了，你只需要关注那20%的业务逻辑就行。

但我也得说个踩坑的事。生成代码的配置界面里有个"表单类型"的选择，比如文本框、数字输入框、日期框、字典框、附件框这些。一开始我没太注意，结果生成的表单里日期字段是个普通文本框，还得手动改。这个属于使用习惯的问题，多用几次就好了。

PL/SQL开发：比想象中顺手

说实话我之前对PL/SQL是有偏见的，觉得写存储过程这种事又土又难维护。但KES Plus的IDE体验确实让我改观了不少。

在VSCode里装了KES Plus扩展之后，直接在IDE里就能创建和编辑函数、存储过程、包这些对象。语法高亮、自动补全都有，比在sqlplus里敲代码体验好太多了。

比如我写了个计算年度保险费用的函数：

sql 复制代码

CREATE OR REPLACE FUNCTION "basicInfo"."fn_calculate_annual_insurance"(vehicleId varchar)
RETURNS NUMERIC AS
/**
 * 函数名：fn_calculate_annual_insurance
 * 功能：计算车辆年度保险费用
 * 参数：vehicleId - 车辆ID
 * 返回值：年度保险费用
 */
DECLARE
    base_rate NUMERIC(10,2) := 500.00;
    vehicle_age INT;
    insurance_cost NUMERIC(10,2);
BEGIN
    SELECT EXTRACT(YEAR FROM AGE(CURRENT_DATE, production_date::DATE))
    INTO vehicle_age
    FROM "basicInfo"."t_vehicle_info"
    WHERE id = $1;
    
    insurance_cost := base_rate + (vehicle_age * 20);
    RETURN insurance_cost;
END;

注意这里用了$1来引用参数而不是直接拼接变量名，这是KES Plus文档里特意强调的防SQL注入的写法。这点我觉得挺好的，说明平台在安全性方面是有思考的，不是只管功能不管安全。

PL/SQL里还有些挺实用的特性，比如%TYPE和%ROWTYPE：

sql 复制代码

DECLARE
    v_name "t_vehicle_info".vehicle_brand%TYPE;  -- 自动跟列同类型
    v_row "t_vehicle_info"%ROWTYPE;              -- 匹配整行结构
BEGIN
    SELECT * INTO v_row FROM "basicInfo"."t_vehicle_info" WHERE id = 'xxx';
    v_name := v_row.vehicle_brand;
END;

这俩玩意儿在表结构变更的时候特别有用------改了列类型不用手动改变量声明，跟着自动变。

关联数组、可变数组、嵌套表、结构体这些PL/SQL的数据结构也都能用。比如关联数组，类似别的语言里的Map：

sql 复制代码

DECLARE
    TYPE map IS TABLE OF varchar INDEX BY varchar;
    dataMap map;
    i varchar;
BEGIN
    dataMap('first') := 'first data';
    dataMap('second') := 'second data';
    i := dataMap.FIRST;
    WHILE i IS NOT NULL LOOP
        RAISE NOTICE '%', dataMap(i);
        i := dataMap.NEXT(i);
    END LOOP;
END;

动态SQL也支持，用EXECUTE IMMEDIATE或者DBMS_SQL包：

sql 复制代码

-- 带占位符的动态SQL，防注入
DECLARE
    sql_str VARCHAR;
    id varchar := lower(sys_guid());
BEGIN
    sql_str := 'INSERT INTO "basicInfo"."t_vehicle_info"
                VALUES (:id, ''1'', ''basicInfo'', :brand, :age, :job)';
    EXECUTE IMMEDIATE sql_str USING id, '沃尔沃', 3, 'worker';
END;

总体来说PL/SQL开发这块的体验是OK的，IDE加持之后写起来没那么痛苦了。但有一个问题我必须说------调试能力还是偏弱。虽然可以在IDE里看RAISE NOTICE的输出，但跟Java那种断点调试比还是有差距。复杂的业务逻辑出了bug，排查效率会低一些。

发布RESTful接口：核心流程

PL/SQL写完了，下一步就是发布成RESTful接口，这一步在KES Plus里真的很简单。

右键函数→属性→RESTful→填配置：分类目录、RESTful名称、URL路径、请求类型（GET/POST/PUT/DELETE）、返回类型（JSON/单行/集合）、匿名或权限点。

保存之后，这个接口就可以被前端调用了。完整的URL格式是：应用编码/模块编码/RESTful路径。

前端调用也很简单，KES Plus基于axios封装了request：

javascript 复制代码

import { request } from '@kesplus/kesplus';

// 查询车辆列表
request.get('/basicInfo/vehicle/list', {
    params: { vehicleBrand: '沃尔沃' }
}).then(res => {
    // 处理返回数据
});

这里有个设计挺巧妙的------RESTful接口天然跟权限体系绑定。每个接口可以设置是否匿名，非匿名的接口必须关联权限点，只有被授权的角色才能访问。这个是做在数据库底层的，不是应用层过滤，所以不存在绕过API直接查数据的"后门"问题。

异常处理

KES Plus的异常处理分三层：全局异常、系统异常、自定义异常。

全局异常是平台统一处理的，会提取异常的编号、描述和堆栈信息，转成标准格式返回前端。系统异常是平台预定义的，比如登录失败、权限不足这些。自定义异常你自己往结果明细表里插一条就行：

sql 复制代码

-- 定义自定义异常
INSERT INTO "kesplus_app"."kesplus_sys_i18n"(
    "id", "code", "lang", "success", "msg", "create_by"
) VALUES (
    lower(sys_guid()), 'vehicle_not_found', 'zh-CN', '0',
    '车辆信息不存在', '0'
);

-- 在业务代码里抛出
CALL "kesplus_platform".exception('vehicle_not_found');

前端收到的就是标准的JSON错误响应，有code、message、堆栈信息，排查起来还算方便。

内置模块：省事是真省事

KES Plus创建完应用之后，默认自带两个模块：系统管理和流程管理。

系统管理

系统管理包含组织管理、岗位管理、用户管理、角色管理、数据字典。说白了就是企业应用里必有的那套RBAC体系。

组织是两级结构：公司和部门。岗位定义职责。用户关联组织和岗位。角色关联权限。数据字典管固定数据。

这些全是开箱即用的，不用你从头写。建完应用第一件事就是用默认的管理员账号登录，配好组织→岗位→用户→角色，然后就能用了。

权限这块KES Plus做得比较深。它支持行级和列级的细粒度权限控制，而且是在数据库底层做的。什么意思呢？就是说不是在应用层加WHERE条件过滤数据，而是数据库根据用户的权限直接返回该用户能看到的数据。这样就没有"后门"------你就算绕过前端直接调API，也只能看到你有权限的数据。

这块对安全要求高的行业（金融、政务）来说确实是个杀手级特性。

流程管理

流程管理基于BPMN2.0规范，提供了可视化的流程设计器。流程建模的步骤：新建流程→设计流程→发布流程→配置表单。

流程运行时支持：我发起的、待办任务、已办流程。操作包括审批、驳回、撤回、撤销。

版本管理有个规则：同一流程只能有一个活动版本，编辑新版本基于活动版本操作，保存后生成新版本。每个版本必须重新配置表单。未发布的可以删除，已发布的不可以删除。

这套流程引擎对于OA类应用来说够用了，审批流、报销流这些常规场景都能覆盖。但如果你要做那种特别复杂的动态流程（比如条件分支里套条件分支再套并行网关），可能会觉得灵活性不太够。

运维侧：故障切机和限流

KES Plus的运维能力其实比我想象的要强。

平台内置了高可用部署机制，支持基于权重和负载因子的负载均衡策略。故障自动切机------主节点挂了自动切换到备节点。繁忙限流------请求量太大的时候自动限流，还支持VIP通道（关键业务不被限流影响）。

多环境一键部署也是有的，开发/测试/生产环境可以统一管理。

自动巡检能力包括数据库健康检查、故障诊断分析、性能优化建议。这些对DBA来说确实能省不少事，不用每天盯着监控面板手动排查了。

放到更大的视角来看

说到这里我想退一步，聊聊"数据库驱动开发"这个范式本身。

这其实不是什么新概念。Oracle APEX早在2000年代初就有了，但很长一段时间里它都不是主流------因为那个时候的架构思潮是"数据库越薄越好"，业务逻辑往外抽，写Java写.NET。微服务兴起之后更是如此，数据库被降格为"持久层"，只管存数据，别的不许碰。

但最近几年风向有点变了。原因有几个：

一是信创。很多甲方从Oracle迁移过来，原本就有大量的存储过程和PL/SQL代码。你让他们重写成Java？成本太高了。KES Plus这种"PL/SQL即API"的模式正好能承接这些遗产。

二是架构回归。微服务的那套东西，在中小规模场景下经常是过度设计。一个单体应用能搞定的事情，非要拆成十个微服务，然后花大量时间处理分布式事务、服务发现、链路追踪这些基础设施问题。KES Plus这种极简架构，"一个请求+一个响应"就完了，对于内部管理系统来说其实够用。

三是安全合规。在数据库底层做权限控制，比在应用层做安全得多。应用层总有漏洞可能被绕过，但数据库层的行级列级权限，你绕不过去。这对于等保2.0、数据安全法这些合规要求来说是个实质性的优势。

当然也不能只说好的。KES Plus目前面临的挑战也挺明显的：

生态还比较薄弱。Oracle APEX背后有Oracle几十年的生态积累，组件市场、模板市场、第三方插件都很丰富。KES Plus目前还处在起步阶段，开箱即用的组件和模板数量不够多，很多场景还是得自己从零开始写。

PL/SQL的人才问题。现在的开发者主流会的是Java/Python/JavaScript，让他们转去写PL/SQL，学习成本不低。虽然有IDE辅助，但思维方式还是不一样的。这个不是KES Plus自己的问题，是整个"数据库驱动开发"范式的问题。

复杂前端场景的支持。KES Plus的前端基于Vue3+ElementPlus，做后台管理系统绰绰有余，但如果你的应用需要复杂的数据可视化、实时协同编辑、3D渲染这些，平台提供的组件可能不够用，得自己扩展。

踩坑实录：那些文档里没写的东西

用了两周不可能一帆风顺，有些坑我觉得得说说，免得你们走弯路。

坑一：pnpm install的依赖问题

导入demo应用之后直接启动报错，Terminal显示"kesplus不是内部或外部命令"。一开始还以为安装有问题，结果翻文档发现是工程没装依赖。这玩意儿文档里其实写了，但藏在很不起眼的地方，我当时愣是找了半小时才找到。

bash 复制代码

# 导入应用后第一件事
pnpm install
# 然后才能启动
pnpm run dev

坑二：PowerShell脚本执行策略

在Windows上装开发环境的时候，打开安装程序工具检查一直在转圈，卡住不动了。后来发现是Windows默认不允许执行远程签名的PowerShell脚本，得手动改一下：

powershell 复制代码

SET-ExecutionPolicy RemoteSigned
# 输入A确认

这个坑官方FAQ里有提到，但你要是没看FAQ直接上手，大概率会在这卡住。

坑三：RESTful接口的权限配置

这个不算坑，但容易忽略。发布RESTful接口的时候如果选了"非匿名"，就必须关联权限点，否则这个接口谁也调不了------包括你自己。我第一次用的时候选了非匿名但忘了配权限点，结果前端一直403，排查了半天才发现是这原因。

所以建议：开发阶段先把接口设成匿名，方便调试。等开发完了再改回非匿名并配置权限点。

坑四：包内函数调RESTful的语法

调用包内的函数和存储过程时，参数名前面要加冒号：

sql 复制代码

-- 在SQL编辑器中调用包内函数
-- kingbase-language-server:disable validation
SELECT "basicInfo"."pkg_vehicle_info".add(:jsonData);

加了冒号之后IDE会报语法错误提示，但不影响运行。第一行加个-- kingbase-language-server:disable validation禁用语法检查就行了。这种"能跑但IDE报错"的体验确实不太好，希望后面能修。

坑五：动态SQL的占位符

动态SQL里用占位符（USING）防SQL注入是对的，但占位符的语法跟Oracle APEX里有些微妙的差异。比如RETURNING INTO子句的写法：

sql 复制代码

DECLARE
    v_id "t_vehicle_info".id%TYPE;
BEGIN
    EXECUTE IMMEDIATE
        'DELETE FROM "basicInfo"."t_vehicle_info"
         WHERE vehicle_number = :v_num RETURNING id INTO :id'
    USING '京M66666' RETURNING INTO v_id;
    RAISE NOTICE '%', v_id;
END;

这种写法在KES Plus里是支持的，但如果你是从Oracle迁移过来的，有些复杂的动态SQL可能需要微调。别以为100%兼容就真的啥都不用改，实际5%左右的语法调整还是要做的。

跟Oracle APEX到底差多远

这个估计很多人关心。我简单说说我的判断。

相同点：核心理念一致------以数据库为中心，PL/SQL即API，前端只是展示层。安全模型也类似，都是数据库底层做权限控制。

KES Plus不如APEX的地方：

组件和模板丰富度差很远。APEX有二十年的积累，KES Plus还在起步阶段
调试体验。APEX的调试器更成熟，KES Plus目前主要靠RAISE NOTICE看输出
国际化和多语言支持。APEX在全球用，多语言是标配；KES Plus目前主要面向国内
社区规模。这是硬伤，Oracle社区多大不用说了

KES Plus比APEX强的地方：

前端技术栈更现代。Vue3+ElementPlus+Vite，APEX那个前端......说实话有点年代感
前后端分离更彻底。APEX很多渲染还是在服务端完成的，KES Plus是纯正的SPA架构
信创环境适配。APEX只能跑在Oracle上，KES Plus跑在KES上，信创场景天然适配
本地化支持。中文文档、中文社区、国内技术支持团队，对国内用户来说确实更方便

我的结论：KES Plus大概在APEX 60-70%的水平（纯功能覆盖度），但在信创场景下的实际可用性能到85%以上------因为那些APEX有但你用不上的功能（比如英文社区、全球CDN集成）在信创环境下本来就不需要。

我的整体判断

用了两周下来，我对KES Plus的评价是：在特定场景下非常有竞争力，但不是万能的。

适合的场景：

企业内部管理系统（OA、ERP、CRM类）
Oracle迁移场景，有大量PL/SQL遗产的项目
安全合规要求高的政务/金融应用
开发团队规模不大、需要快速交付的项目

不太适合的场景：

面向C端的高并发互联网应用
需要复杂前端交互的产品
团队完全没有PL/SQL经验的全新项目

最后说一点比较个人的感受吧。我觉得KES Plus最让我欣赏的地方不是某个具体功能，而是它的设计理念------让数据库重新回到架构的中心位置。这些年数据库被边缘化太久了，大家都把它当存储用，业务逻辑全搬出去了。但其实数据库才是离数据最近的地方，在数据库里做计算，不存在网络传输的开销，不存在ORM转换的损耗，事务一致性也天然有保障。KES Plus把这个理念落到了产品里，我觉得方向是对的。

当然了，方向对不代表执行就完美。组件生态、调试体验、文档深度这些都需要持续打磨。但至少起步是扎实的，不是那种PPT产品。对于一个对标Oracle APEX的国产产品来说，能做到这个程度已经不容易了，后续能不能做好关键看生态建设。