Entity Framework Coreは、元のEntity Frameworkに追いつくための進化を継続している。まずはビューのサポートだ。意外なことにこれからリリースされるEF Core 2.1まではデータベースのビューは正式にサポートされていなかった。また、主キーのないレアなテーブルもだ。
ビューのサポートが欠けているため、EF Core 2.0には回避策がある: ROW_NUMBERを主キーの代わりに作成して、ビューをテーブルのように作成する。これにより、ビューがテーブルのようにデータベースコンテキストを構成できる。ROW_NUMBERを戻すことでビューを変更できず、カラムの組み合わせが一意でない場合、Key属性でランダムなカラムを指定できる。AsNoTrackingを使うことで、EFのキャッシュロジックを回避でき、行の「重複」が破棄される。
EF Core 2.1では、「読み取り専用」のビュー、ヒープテーブル、インラインSQLの代わりに、「クエリタイプ」のセットが利用できる。これにより主キーが必要ではなくなる。
Group Byのサポート
もう1つのEF Coreの想定外の制限は、SQLでGROUP BY操作を生成できないことだ。現在、全体のデータセットがクライアントに転送され、その後、EF Coreがインメモリでグルーピング操作を実行する。これにより、データベースで操作するのと比べて、ネットワーク、メモリ、CPU使用率に大幅に高くなる可能性がある。
EF Core 2.1がリリースされてから、ビューやインラインSQLでグループ化の操作を回避できる。上記の回避策によりビューをテーブルとして扱うことができる。
遅延読み込み
遅延読み込みとして知られる熱く議論されてきた機能である。いくらかの開発者はそれを気に入っているが、パフォーマンスの低下や想定しない実行時エラーに繋がる落とし穴もある。EF Core 2.1で遅延読み込みが追加されたが、元のEntity Frameworkにあったようなものではない。
遅延読み込みを有効にするには、オブジェクトにAction<object, string>を受け入れるコンストラクタを含める必要がある。コレクションのプロパティは、次のパターンが使われる。:
public ICollection<Post> Posts {
get => _lazyLoader.Load(this, ref _posts);
set => _posts = value;
}
この例では _lazyLoaderが前述のコンストラクタからのActionである。LoadはEF Coreにコールバックされる拡張メソッドである。
元バージョンのEFのようにEF Coreはボイラープレートコードなしで遅延読み込みがサポートされることが期待されている。
トランザクション
トランザクションは常にEF Coreがサポートされていたが、データベーストランザクションに限定されていた。次期バージョンでは、TransactionScopeと、System.Transactions名前空間によって提供される他の機能を利用できる。「アンビエントトランザクション」として知られるこの機能では、データベース、メッセージキュー、Webサービス、ファイルシステムなどの複数リソースをまたいだトランザクションを調整できる。たとえば、トランザクションでNTFSハードドライブへの書き込みが失敗した場合、データベースへの変更が自動的にロールバックされる。
値変換
ORMで少なく見積もられている機能は、値変換の機能である。単純なケースでは、数値や文字列の表現を列挙型に格納するなどがある。ORMが複数のデータベースエンジンのサポートが必要な場合、さらに面白くなる。
例えば、データモデルが符号なし整数である場合、いくつかのデータベースでは符号なし整数をネイティブでサポートしているため、それができる。しかし、SQL Serverなどでは、符号付き整数しかサポートされていない。モデルが両方をサポートする必要がある場合、ORMが変換を処理できることが重要になる。
EF Core 2.1はさらに進化し、カスタム変換ロジックをプラグインできるようになる。これにより、例えば、プロパティ値の透過的な暗号化および復号化が可能になる。
空間データ型
新しいロードマップへ最初の応答は、空間データ型のサポートの新しい要求であった。SQL Serverは、GeometryとGeography型で表現されている。Geometryはユーグリッド(平面)座標系を扱い、Geographyはより複雑な楕円座標系を処理する。
EF Core 2.1では部分的にサポートされている。まずは.NET Framework上で動作する必要がある。このライブラリは.NET Coreでは利用できない。次に、ビューやインラインSQLを使って、geometryやgeographyをwell-known binary (WKB)やwell-known text (WKT)に変換する必要がある。これらは、このようなデータを表現する業界標準である。最後に、(上で説明した)値コンバーターを書いて、WKB/WKTと.NETオブジェクトの値の間を変換できる。
その他に予定されている.NET Core向けの機能は、EF 2.1ロードマッププレスリリースを参照して欲しい。
Rate this Article
- Editor Review
- Chief Editor Action