AppBoxFuture(八): 另类的ORM实现
通常的ORM实现基于配置或注释，由反射或Emit生成相应的Sql语句，然后将Sql发送给数据库解析Sql字符串生成AST再交给优化器处理后执行，返回的数据再经由反射或Emit转换为相应的实体实例。作者认为上述方式主要存在以下两个问题：
- 实体类代码是硬编码的，如果实体类定义变更必须重新编译应用再部署，不利于实现运行时动态变更实体定义；
- CRUD操作转换为Sql的实现复杂，且需要针对不同的数据库做适配优化。
由于作者追求极致简单的系统架构以及丝般顺滑的开发体验，所以作者采用了另类的方式在框架内实现了ORM，之于另类在什么地方我们先通过一些简单示例后再来说明一下实现原理。
一、CRUD操作
还是用系统自带的Emploee模型作为示例，在IDE新建服务模型添加以下代码保存发布后可通过主菜单->Service->Invoke运行测试：
//事务新建两条记录
var emp1 = new Entities.Emploee();
emp1.Name = "Rick";
emp1.Account = "rick@appbox.dev";
emp1.Birthday = new DateTime(1977, 3, 16);
var emp2 = new Entities.Emploee();
emp2.Name = "Johne";
emp2.Account = "johne@appbox.dev"
emp2.Birthday = new DateTime(1979, 1, 2);
var txn = await Transaction.BeginAsync();
try {
await EntityStore.SaveAsync(emp1, txn);
await EntityStore.SaveAsync(emp2, txn);
await txn.CommitAsync();
} catch (Exception ex) {
txn.Rollback();
}
//查询记录
var q = new TableScan<Entities.Emploee>();
q.Filter(t => t.Name == "Rick");
var emps = await q.ToListAsync();
//更新记录
emps[0].Name = "Rick Lu";
await EntityStore.SaveAsync(emps[0]);
//删除记录
await EntityStore.DeleteAsync(emps[0]);以上只是已实现的一些Api示例，复杂的如根据索引查询、聚合查询等Api正在设计开发中。
二、实现原理
设计时:
这部分实现重度依赖Roslyn功能，服务端在开发人员登录至IDE后会通过Roslyn生成虚拟项目。
- 实体模型保存时服务端生成虚拟的实体类代码，并加入虚拟项目内；
- 服务模型保存时服务端生成虚拟的服务类代码，并加入虚拟项目内；发布时服务端的编译引擎解析虚拟的服务代码，然后转换为运行时服务代码，再通过Roslyn编译为动态服务组件。其中虚拟代码转换为运行时代码的过程主要是：
- 将实体属性取赋值操作(eg: entity.Name = “aa” 或 var temp = entity.Name)转换为针对运行时Entity类的GetXXX()及SetXXX()操作。这里需要注意的是运行时只存在一个Entity类（类似于KVO通过字典表保存属性值）；
- 将查询条件转换为可序列化的表达式，这样存储引擎执行查询命令时可委托clr emit生成过滤指令，存储引擎在扫描时直接使用过滤指令计算满足条件的记录。
运行时:
这部分实现参考以下流程图，需要注意的是存储引擎是基于RocksDB的，实体数据转换为KV数据（如Key=Id, Value=[字段标识:字段值;字段标识:字段值]），这样转换过程就不需要使用反射或Emit。
三、性能测试
作者做了简单的性能测试(单节点I74C8G虚拟机)：
- 并发插入不带索引不带外键的简单实体约28000tps;
- 通过惟一索引查询约80000qps;
- 带条件扫描少量记录约35000qps。
四、查询限制
- 存储引擎不支持join，可通过分别查询出数据后利用Linq做join操作；
- 存储引擎暂只支持根据Entity.Id或指定索引查询排序，不支持自定义排序。
五、本篇小结
本篇主要介绍了框架集成的ORM的另类实现，Github上的运行时已经更新可测试。如果您有问题或Bug报告，请留言或在Github提交Issue。
版权声明：本文为BaiCai原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。