两个 DObject：Delphi ORM vs Fun

> 对比对象:Delphi 单元 `MO_DObject.pas`(约 16500 行)与 Fun 标准库 `lib-orm` 家族(7 个文件共约 1030 行)。前者是经典的 Delphi/Pascal 企业级 ORM,后者是 Fun 语言"数据库"模块的自托管实现。本文基于两份源码逐行对照,说清它们的血缘、异同,以及 Fun ORM 究竟"差"在哪里、"赢"在哪里。

## 一、缘起:同一作者的两代实现

把两份源码并排打开,血缘关系几乎写在脸上。Fun 的核心类名就叫 `DObject`,其 schema 加载函数 `LoadSchema` 解析的 XML 节点名为 `DoTable / DoField / DoRelation / DoRelationField`,属性含 `Alias / IsPrimary / IsAutoIncrement`——这是 Delphi 版 DObject 一脉相承的数据字典风格;连"未修改前的属性快照"这种细节(旧值表 + 脏检查)也能在两边找到对应物。再考虑到两者署名同为张卫东(Zhang Weidong, 2010-2026),基本可以断定:**Fun 的 lib-orm 是作者对自己 Delphi 时代 ORM 思想的一次"脚本语言重写"**。

但重写不等于照搬。Delphi 版是一套 16545 行、20 个接口、80 余个类的完整框架,而 Fun 版把全部实现压缩进 1029 行——包括核心 CRUD(389 行)、批量事务层(74 行)、CTE 扩展(88 行)、RPC 层(77 行)、代码生成(37 行)和 ADO 连接层(364 行)。16 倍的体量差,不是偷工减料四个字能概括的,它背后是两套截然不同的架构哲学。

## 二、架构对比:一张表看懂

| 维度 | DObject (Delphi) | lib-orm (Fun) |
|------|-----------------|---------------|
| 代码规模 | 16545 行 / 单元 | 1029 行 / 7 文件 |
| 抽象方式 | 20 个 interface + 类继承树 | 纯动态 map + 闭包,鸭子类型 |
| 查询语言 | 完整 OQL 对象代数(Visitor 模式) | 字符串模板 + `Condition` 条件树 |
| 多表连接 | Join / LeftJoin / GroupBy / Having / Case | 无 JOIN;CTE 与子查询靠 `lib-orm-cte` |
| 变更跟踪 | 字段级状态机(New/Uncommited/Modified/Commited) | 对象级快照:`isNew` + `@old$` |
| 工作单元 | TObjectManager + UncommitedObjectList | OrmModify 包一层 Begin/Commit/Rollback |
| 身份管理 | TObjectSpace + UncommitedObjectList | 无(每次 Get 生成新对象) |
| 缓存 | TLocalCache(None/Global/Local) | 无 |
| 数据库方言 | Access / Oracle / SQL Server 三套 SqlBuilder | ADO 通用通道 + 引号符/分隔符自动探测 |
| SQL 安全 | 参数化查询(TParamedSql) | 正则黑名单拦截 + 转义 |
| 远程能力 | 无(需自行搭建) | lib-orm-rpc:JSON-RPC 服务开箱即用 |
| 递归查询 | 无专用支持 | WITH RECURSIVE(lib-orm-cte) |
| 代码生成 | 设计时组件 | GenCode 运行时生成强类型包装类 |

## 三、共同的基因:哪些设计被继承了下来

第一,**schema 驱动**。两者都不用注解或手写映射,而是把表结构(字段、类型、主键、自增)提炼成一份数据字典,ORM 一切行为由字典驱动。Fun 的 `LoadSchema` 甚至直接读 XML 定义,与 Delphi 版"设计时编辑元数据"的思路同源。

第二,**关系导航**。Delphi 版用 `TParentRelationInfo / TChildRelationInfo` 描述父子外键;Fun 版把这个结构做成了 `@Parent / @Children` 两个键映射表,`GetParent / GetChildren / NewChildren` 三个方法完成跨表跳转,键值对应关系原样保留:

```fun
o.@Parent[r.ParentName] = rf;      // 父关系:别名 + 键映射
rf.@Keys[f.ParentField_Alias] = f.ChildField_Alias;
```

第三,**CRUD 与 Create 全套**。Insert 时回填自增主键(`selectAutoId` 二段执行)、Update 前做脏检查只发变更列、Delete 按主键定位、甚至运行时 `CREATE TABLE` 建表(DObject 也有表结构创建能力)——这些主库存活技能两边一一对应。

第四,**事务与可观测性**。DObject 有 `BeginTransaction / Commit / Rollback`;Fun 的 `OrmModify` 把多表批量写包进同一个事务,异常自动回滚。两边都支持 SQL 打印开关(`PrintSQL / dontPrintSQL`),这是调试期最实用的功能。

## 四、Fun ORM 差了哪些:七个实打实的缺失

**1. 没有 OQL 代数,JOIN 是最大空白。** DObject 把 SELECT/FROM/JOIN/WHERE/GROUP BY/HAVING/ORDER BY/INSERT/UPDATE/DELETE 甚至 CASE 表达式全部对象化,配上 Visitor 模式遍历改写;Fun 版本质是"格式化字符串拼接 + 条件树",`Get` 只支持单表 SELECT。除 CTE 扩展里可以指定 FROM 外,**两张表的 JOIN 在 Fun ORM 里没有表达方式**——需要 JOIN 时得退回 `db.Execute` 手写 SQL。这是与 Delphi 版差距最大的一处。

**2. 没有字段级状态机与 Unit of Work。** Delphi 版为每个字段维护 New/Uncommited/Modified/Commited 四态,对象另有五态,由专门的 StateManager 管理;提交时只写真正变化的字段,且未提交对象列表(`_UncommitedObjectList`)支持整体提交/回滚语义。Fun 版只有 `isNew` 加一份 `@old$` 快照:能算出"哪些列变了",但说不出"这个对象处于生命周期的哪一步"。

**3. 没有 ObjectSpace(身份地图)。** 同一行数据 `Get` 两次,Fun 会生成两个互不相干的 `DObject` 实例,改了其中一个再 Save,另一个毫无感知。DObject 的 ObjectSpace 保证对象身份一致性,这是长会话应用(如桌面程序全程持有数据上下文)的关键设施。

**4. 没有缓存。** `CacheType_Global/Local` 在 Fun 版中找不到对应物,每次查询都直连数据库。对脚本场景这未必是问题,但离 Delphi 版的离线缓存 + XML 持久化(TXmlProvider 甚至能把整个 ObjectSpace 存成 XML 文件当"口袋数据库",自带事务和自增管理)差了一个量级。

**5. 方言层薄。** DObject 为 Access/Oracle/SQL Server 各写了一个 SqlBuilder,分页、类型映射、引号规则各安其位。Fun 版只有 ADO 一个通道,靠运行时读 `OpenSchema(DBInfoLiterals)` 自动探测引号符和 schema 分隔符来适配方言——思路聪明,但分页语法(`TOP` 写死在 CTE 模块)、类型映射(`Create` 用一张写死的 13 项默认表)仍是"一招鲜"。`SQ` 函数里那句 `// todo: SQL Injection` 作者自己也承认:正则黑名单只是权宜之计,参数化查询(TParamedSql)才是正道,而 Fun 版没有走到这一步。

**6. 接口抽象与可测试性缺失。** Delphi 版 20 个 interface 把连接、提供者、对象集、SQL 构建器全部解耦,任何一环都可以 Mock 替换。Fun 版全是具体类和 map,没有接缝——动态语言可以靠 monkey-patch 补救,但框架本身没有给出这个结构。

**7. 惰性加载与级联缺失。** `GetParent/GetChildren` 是即时单跳查询;没有"访问时才发 SQL"的集合代理,也没有级联保存/删除(Delphi 版通过关系元数据由 ObjectManager 统一调度,如 `DeleteObject` 会处理从属对象;Fun 版代码里留着 `// todo: Remove from owner list?` 的欠账)。

## 五、反超的部分:脚本语言的后发优势

客观地说,Fun ORM 并非全面落后,有几处是 Delphi 版没有的:

- **WITH RECURSIVE**:树形/图状数据的递归查询一等公民化,`CteObject` 用锚点 + UNION ALL 两段式定义,这在 Delphi 版里没有专用设施。
- **RPC 开箱即用**:`OrmRpc` 继承 JSON-RPC 服务器,`Rpc_OrmGet/Save/Update/Delete` 四个方法把整套 ORM 暴露成网络服务,客户端免驱动直连——Delphi 版要自己搭中间层。
- **运行时代码生成**:`GenCode(schema)` 直接从 schema 生成带关系方法的强类型包装类源码并 eval,Delphi 版同类能力依赖设计时组件。
- **流式结果**:`rs2json` 支持 stream 模式逐行写 TSV,大结果集不必整体载入内存。
- **Schema 反向工程**:`lib-ado-schema` 从现存数据库读出表/列/主外键生成 schema,配合 `GenCode` 形成"接库即用"的闭环。

## 六、结语:不是差距,是定位

把 16 倍的体量差简单读成"Fun ORM 不如 DObject"并不公平。DObject 诞生于 Delphi 的黄金范式:编译期强类型、接口解耦、组件化 IDE、桌面程序长会话——所以它需要 OQL 代数、字段状态机、身份地图和缓存,这些是"企业级中间件"的生存装备。Fun ORM 则是脚本语言的胶水件:动态 map、即时会话、自托管标准库——它把 schema 驱动、关系导航、脏检查、事务这些 ORM 的"最小可用集"压进一千行,再把 Delphi 时代没有的 CTE、RPC、运行时代码生成作为增量补上。

一句话总结:**DObject 是一台调校完整的发动机,Fun ORM 是一辆轻便的摩托**——缺了汽缸盖(JOIN/OQL)、涡轮增压(状态机/UoW)和油箱(缓存/身份地图),但换句话说,你也不需要先考驾照(接口/配置)才能骑上去。若 Fun 未来要补课,优先级应当是:参数化查询 → JOIN 支持 → 对象级身份缓存,这三件事收益最大,且都能在现有 map 架构内渐进完成,不必推倒重来。