BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース EF Core 2.1ロードマップ: ビュー、Group By、遅延読み込み

EF Core 2.1ロードマップ: ビュー、Group By、遅延読み込み

ブックマーク

原文(投稿日:2018/02/28)へのリンク

あなたのリクエストに応じて、ノイズを減らす機能を開発しました。大切な情報を見逃さないよう、お気に入りのトピックを選択して、メールとウェブで通知をもらいましょう。

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

Adoption Stage
Style

この記事に星をつける

おすすめ度
スタイル

BT