通常ORM設定やコメントに基づいて、反射またはSQLエミットによって対応する文を形成するために、次にAST最適化された処理を生成行うために、再度SQLのSQL文字列を解決するためにデータベースに送信されたデータは、その後、反射を介して返さ又は放出するように変換されます。それぞれのエンティティ。著者は、次の2つの質問を中心に上記の方法を信じています：

エンティティクラスの定義の変更は、アプリケーションの再配備は動的変更エンティティを助長されていません再コンパイルし、実行を定義する必要がある場合は、エンティティクラスのコードは、ハードコード化されています。
複雑にCRUD操作を実装し、異なるデータベース用に最適化された適応を行う必要があるSQL。

究極のシステムアーキテクチャと絹のような滑らかな開発経験のシンプルな追求のため、著者らは、代替の枠組みの中でORMを達成するための代替方法を使用しているのでどこかにいくつかの簡単な例を挙げてみましょうすると、その後の原則の実現を説明します。

、CRUD操作

：>>テストを実行するためにService-を起動します - またはシステムを使用して、IDEの新しいサービスモデルのメインメニューから解放保存することができ、次のコードを追加し、例としてEmploeeモデルが登場します

//事务新建两条记录
var emp1 = new Entities.Emploee();
emp1.Name = "Rick";
emp1.Account = "[email protected]";
emp1.Birthday = new DateTime(1977, 3, 16);
var emp2 = new Entities.Emploee();
emp2.Name = "Johne";
emp2.Account = "[email protected]"
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クエリの開発を設計されている重合を実現しています。

第二に、実現原理

デザイン：

これは、部分的に大きく依存ロザリン関数の後に達成され、IDEでサーバーにログオンロスリンすることにより、仮想プロジェクト開発者が生成されます。

サーバーを保存するソリッドモデルは、仮想エンティティクラスのコードを生成し、仮想プロジェクトに追加すると、
サービスモデルは、仮想サーバサービス・クラス・コードが生成され保存され、仮想プロジェクトに追加し、公開サーバコンパイラエンジンは、仮想サービスコードを解析し、次いで場合、サービスコードを実行してロザリン動的サービスコンポーネントによってコンパイルに変換。前記プロセスの実行コードに仮想コードは以下のとおりです。

エンティティ属性の割り当てを取り出します（例：entity.Name =「AA」やVARの一時を= entity.Name）エンティティクラスのランタイム操作用のgetXXX（）メソッドとsetXXX（）に変換されます。それだけで1つのクラスのランタイム・エンティティ（似たKVOディクショナリ表格納されている属性値）が存在することに留意すべきです。
将查询条件转换为可序列化的表达式，这样存储引擎执行查询命令时可委托clr emit生成过滤指令，存储引擎在扫描时直接使用过滤指令计算满足条件的记录。

运行时:

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

三、性能测试

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

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

四、查询限制

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

五、本篇小结

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

AppBoxFuture（VIII）：代替ORMの実装