AppBoxFuture(八): 另类的ORM实现

  一般的ORM实现基于配置或注释，由反射或Emit生成相应的Sql语句，而后将Sql发送给数据库解析Sql字符串生成AST再交给优化器处理后执行，返回的数据再经由反射或Emit转换为相应的实体实例。做者认为上述方式主要存在如下两个问题：

1. 实体类代码是硬编码的，若是实体类定义变动必须从新编译应用再部署，不利于实现运行时动态变动实体定义；
2. CRUD操做转换为Sql的实现复杂，且须要针对不一样的数据库作适配优化。

  因为做者追求极致简单的系统架构以及丝般顺滑的开发体验，因此做者采用了另类的方式在框架内实现了ORM，之于另类在什么地方咱们先经过一些简单示例后再来讲明一下实现原理。

1、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正在设计开发中。

2、实现原理

设计时:

  这部分实现重度依赖Roslyn功能，服务端在开发人员登陆至IDE后会经过Roslyn生成虚拟项目。

• 实体模型保存时服务端生成虚拟的实体类代码，并加入虚拟项目内；
• 服务模型保存时服务端生成虚拟的服务类代码，并加入虚拟项目内；发布时服务端的编译引擎解析虚拟的服务代码，而后转换为运行时服务代码，再经过Roslyn编译为动态服务组件。其中虚拟代码转换为运行时代码的过程主要是：

1. 将实体属性取赋值操做(eg: entity.Name = "aa" 或 var temp = entity.Name)转换为针对运行时Entity类的GetXXX()及SetXXX()操做。这里须要注意的是运行时只存在一个Entity类（相似于KVO经过字典表保存属性值）；
2. 将查询条件转换为可序列化的表达式，这样存储引擎执行查询命令时可委托clr emit生成过滤指令，存储引擎在扫描时直接使用过滤指令计算知足条件的记录。

运行时:

  这部分实现参考如下流程图，须要注意的是存储引擎是基于RocksDB的，实体数据转换为KV数据（如Key=Id, Value=[字段标识:字段值;字段标识:字段值]），这样转换过程就不须要使用反射或Emit。

3、性能测试

  做者作了简单的性能测试(单节点I74C8G虚拟机)：

• 并发插入不带索引不带外键的简单实体约28000tps;
• 经过唯一索引查询约80000qps;
• 带条件扫描少许记录约35000qps。

4、查询限制

• 存储引擎不支持join，可经过分别查询出数据后利用Linq作join操做；
• 存储引擎暂只支持根据Entity.Id或指定索引查询排序，不支持自定义排序。

5、本篇小结

  本篇主要介绍了框架集成的ORM的另类实现，Github上的运行时已经更新可测试。若是您有问题或Bug报告，请留言或在Github提交Issue。