12月4日に、EF Core 2.2の最終バージョンがリリースされました。 ASP.NET Core 2.2および.NET Core 2.2と並行してリリースされ、言語オブジェクトとデータベース間のマッピングを管理するためのオープンソースおよびクロスプラットフォーム技術の最新リリースです。
EF Core 2.2 RTMには、100以上の修正といくつかの新機能が含まれています。これらについては、この記事で説明します。
リンクは、Habréの対応する記事につながります。 これは、シリーズの最後の3番目の記事です。 次回は新しいリリースについてお話します-そしてそれは新年になります。
空間データ
空間データは、オブジェクトの物理的な位置と形状を保存するために使用されます。 多くの既存のデータベースには、このようなデータを格納、インデックス付け、取得するための組み込みメソッドがあります。 主な使用シナリオは、選択した距離でオブジェクトを検索し、特定のポイントがポリゴンの一部に含まれていることを確認することです。 EF Core 2.2は、NetTopologySuite(NTS)ライブラリの型を使用して、そのようなデータベースおよびジオデータを操作できるようになりました。
空間データは、特別なプロバイダー用の拡張パッケージのセットとして実装されます。 これらの各パッケージは、NTSタイプおよびメソッドの新しいマッピングと、データベース内の対応する空間タイプおよび機能の両方を追加します。 このようなプロバイダー拡張機能は、SQL Server、SQLite、およびPostgreSQLに既に実装されています(Npgsqlプロジェクトのおかげです)。 空間タイプは、他の拡張機能を使用せずに、インメモリプロバイダーEF Coreと一緒に直接使用できます。
拡張機能がインストールされると、新しいタイプのサポートが含まれます。 これらのタイプのプロパティは、エンティティで使用できます。例:
using NetTopologySuite.Geometries; namespace MyApp { public class Friend { [Key] public string Name { get; set; } [Required] public Point Location { get; set; } } }
もちろん、このデータを保存できるようになりました:
using (var context = new MyDbContext()) { context.Add( new Friend { Name = "Bill", Location = new Point(-122.34877, 47.6233355) {SRID = 4326 } }); context.SaveChanges(); }
同様に、空間データと操作を含むデータベースへのクエリを作成することが可能になります。
var nearestFriends = (from f in context.Friends orderby f.Location.Distance(myLocation) descending select f).Take(5).ToList();
空間データは、 公式ドキュメントから始めるべき大きなトピックです。
依存エンティティのコレクション
EF Core 2.0には、1対1の関係をモデル化する機能が導入されています。 EF Core 2.2は、この機能を拡張して、この点で誰がメインエンティティ(所有者)で、誰が依存(所有)しているかを直接示す機能を備えています。 これにより、エンティティの範囲を制限および明確にすることができます。
たとえば、依存エンティティ:
- これらは、他のタイプのエンティティに含まれる参照プロパティ( 英語の「ナビゲーションプロパティ」 )でのみ使用できます。
- メインエンティティと共にのみ
DbContext
自動的にロードおよび追跡されます。
リレーショナルデータベースでは、通常の1対多のリレーションシップと同様に、依存コレクションはメインエンティティのテーブルにマップされず、個別のテーブルにマップされます。 ドキュメント指向のデータベースでは、すべてが多少異なり、メインエンティティが格納されている同じドキュメントに依存エンティティを(依存コレクションまたはリンクに)埋め込むことを計画しています。
この機能を使用するには、新しいOwnsMany()
APIを呼び出します。
modelBuilder.Entity<Customer>().OwnsMany(c => c.Addresses);
クエリタグ
この機能は、コード内のLINQクエリとそれらから生成されたSQLクエリ間の接続を見つけるタスクを簡素化することを目的としています。
タグを有効にするには、新しいTagWith()
メソッドを使用してLINQクエリに注釈を付けます。 空間データセクションの前の例を少し変更してみましょう。
var nearestFriends = (from f in context.Friends.TagWith(@"This is my spatial query!") orderby f.Location.Distance(myLocation) descending select f).Take(5).ToList();
ログで次のテキストを確認できます。
-- This is my spatial query! SELECT TOP(@__p_1) [f].[Name], [f].[Location] FROM [Friends] AS [f] ORDER BY [f].[Location].STDistance(@__myLocation_0) DESC
いつものように、これに関する[ドキュメントのセクション]があります。
EF Core 2.1との互換性
EF Core 2.2とEF Core 2.1の既存プロバイダーとの後方互換性を確保し、EF Core 2.2に更新した後、目に見える問題なくアプリケーションがアセンブルされるように、多くの時間と労力を費やしました。 ほとんどの場合、ほとんどの場合、新しいバージョンへの移行は簡単ですが、それでも、突然問題に遭遇した場合は、バグトラッカーでそれらについて話す価値があります 。
現時点では、アプリケーションコードの小さな変更が必要な変更は1つだけです。 これについては、次のチケットの説明で読むことができます。
- #13986 :通常のプロパティと依存プロパティの両方として設定されたタイプでは、2.1から2.2へのアップグレード直後にプライマリキーを作成する必要があります。
古いコードの変更が必要な問題のリストを引き続き維持および更新する予定です。
次のステップ:EF Core 3.0
バージョン2.2のリリース後、次の目標はEF Core 3.0です。 新しい機能はまだ実装されていないため、12月4日にリリースされたNuGetパッケージには、EF Core 2.2のリリース後に行われたわずかな変更のみが含まれています。
次のリリースでは、すでに広く議論されているいくつかの大きなアイデアが計画されています。 将来のニュースリリースでそれらについてお話ししたいのですが、ここであなたがすでに何か言うことができるいくつかのトピックがあります:
LINQの改善 。 LINQを使用すると、タイプ情報を使用してIntelliSenseを表示し、コンパイル時に検証することで、プライマリ言語からデータベース言語に切り替えることなく、データベースクエリを作成できます。 しかしこれはまた、LINQを使用すると、無制限の数の複雑なクエリを記述できることを意味します。これは、LINQプロバイダーにとって常に大きな課題でした。 EF Coreの最初のバージョンでは、要求のどの部分をSQLに変換できるかを判断し、このクライアントのメモリを使用して、クライアントで要求の残りの部分を直接実行できるようにすることで、この問題を解決しました。 このクライアント側での実行は役立つ場合がありますが、多くの場合、非常に非効率的な要求につながり、コードが実稼働に入るまで見つけることができません。 EF Core 3.0は、LINQの内部構造とそのテスト方法を変更する徹底した仕事をしたいと考えています。 それらをより耐久性と信頼性の高いものにする必要があります(たとえば、新しいパッチリリースをローリングした後にリクエストが壊れないようにするため)。 多数の式のSQLで正しい変換を実装します。 より多くの場合により効率的に機能するクエリの生成に焦点を当てます。 効率の悪いリクエストは見過ごされないことを考慮してください。
Cosmos DBのサポート 。 EFプログラミングモデルに精通している開発者がAzure Cosmos DBをメインベースとしてすぐにターゲットにできるように、EF CoreのCosmos DBプロバイダーで作業を続けています。 課題は、グローバル配信、「常時オン」可用性、弾力性のあるスケーラビリティ、低遅延など、Cosmos DBの最高の機能を活用することです。 EF Coreプロバイダーは、利用可能な機能のほとんどを提供する必要があります。 EF Core 2.2のかなり前にこれを開始し、 いくつかの予備バージョンをリリースしました 。 EF Core 3.0と並行してプロバイダーの開発を続けます。
C#8.0のサポート 。 C#8.0には、非同期ストリーム(
await foreach
を含む)やEF Coreがサポートするnull可能な参照タイプなどの便利な新機能がいくつかあります。
データベースをクエリタイプに逆変換する 。 EF Core 2.1は、データベースから読み取ることはできますが更新できないデータを表すクエリタイプのサポートを追加します。 SQLデータベースのビューのモデリングに最適であるため、EF Core 3.0では作成を自動化したいと思います。
プロパティバッグエンティティ 。 これにより、通常のプロパティではなくインデックス付きのデータにデータを保存するエンティティが追加され、.NETの同じクラスのインスタンス(たとえば、
Dictionary<string, object>
)を使用して、多くの異なるタイプのエンティティを1つに表示できますそして、同じEF Coreモデル。 この機能は、統合エンティティを使用せずに本格的な多対多の関係を構築するための次のステップです。つまり、EF Coreの最も期待される機能の1つです。
.NET Core上のEF 6.3 EFを使用する多くのアプリケーションが存在することは明らかであり、.NET Coreを使用して利点を得るためだけにEF Coreに移植するには、多くの労力が必要になることがあります。 したがって、EF 6の次のバージョンを適応させて、.NET Core 3.0でも機能するようにします。 これは、開発者がアプリケーションを移植してコードをできるだけ変更する必要がないようにするためです。 もちろん、これにより多くの制限が発生します(たとえば、新しいプロバイダーが必要になり、空間データのサポートがSQL Serverで有効になりません)。 さらに、EF 6に追加機能を追加する予定はありません。
おわりに
EFチームは、最終的にEF Core 2.2の導入につながった品質フィードバックと開発支援についてコミュニティに感謝します。 いつものように、新しいishshuiをトラッカーに直接追加できることをお知らせします 。 よろしくお願いします!
1月1日からのDotNextのチケットの価格が上がることを忘れないでください。 個人-1000人、標準-2000人。 アーリーバードに関する詳細はサイトにあります 。