Entity Framework Core 7.0 の計画

計画プロセスで説明されているように、Entity Framework Core 7.0 (EF Core 7.0) の計画には関係者からの意見が取り入れられています。簡潔にするため、EF Core 7.0 は単に EF7 とも呼ばれます。

重要

この計画は確約ではありません。リリース全体を通して学習し続けるにつれて進化します。 現在、EF7 で計画されていない機能が盛り込まれる可能性があります。 現在、EF7 で計画されている機能が除外される可能性があります。

一般情報

EF Core 7.0 は、EF Core 6.0 に続く次のリリースであり、現時点では、2022 年 11 月に .NET 7 と同時にリリースされる予定です。 EF Core 6.1 リリースの計画はありません。

サポートされているプラットフォーム

EF7 では現在、.NET 6 を対象としています。 これは、リリースが近くなった時点で .NET 7 に更新される可能性があります。 EF7 では、.NET Standard のどのバージョンも対象にしていません。詳細については、「.NET Standard の将来」を参照してください。 EF7 は、.NET Framework では実行されません。

EF7 は .NET サポート ポリシーに合わせるため、長期サポート (LTS) リリースではありません

互換性に影響する変更

EF Core と .NET プラットフォームの両方の機能強化が継続的に行われているため、EF7 に含まれる破壊的変更の数は多くありません。 当社の目標は、破壊的変更を可能な限り最小限にすることです。

テーマ

EF7 への大規模な投資は、主に次のテーマに該当します。

  • 要求の多かった機能
  • NET プラットフォームとエコシステム
  • EF6 からパスを前方にクリアする
  • パフォーマンス

次に、これらの各テーマについて詳しく説明します。 各テーマの状態の概要は、EF Core の隔週の更新に関するページで追跡できます。 フィードバックや提案については、GitHub Issue #26994 にコメントしてください。

テーマ: 要求の多かった機能

これまでと同じように、計画プロセスの基になっているものは主に、GitHub の機能への投票 (👍) です。 他の要因に加えて、これらの投票に基づいて、EF7 では次の要求が多かった機能に取り組む予定です。

JSON 列

追跡: 問題 #4021: データベースに格納されている JSON 値を EF プロパティにマップする

価値提案: リレーショナル データベース列に格納されている JSON ベースのドキュメントを保存してクエリを実行します。

この機能により、任意のデータベース プロバイダーによって実装できる JSON サポートのための一般的なメカニズムとパターンが導入されます。 コミュニティと協力して、Npgsql および Pomelo MySQL の既存の実装を調整し、SQL Server と SQLite のサポートも追加します。

一括更新

追跡: 問題 #795: 一括 (つまり、セット ベース) CUD 操作 (データをメモリに読み込まない)

価値提案: データをメモリに読み込まない多くのデータベース行に対する効率的な述語ベースの更新。

後に SaveChanges が続く変更の追跡は、エンティティを挿入、更新、および削除するための EF Core の主要なメカニズムです。 このメカニズムにより、確実に制約を満たすようにデータベース操作が順序付けされ、追跡対象のエンティティがデータベースに加えられた変更と同期されます。 しかし、適切なデータベース コマンドを作成するためにエンティティをメモリに読み込むにはデータベース ラウンドトリップが必要です。その後に、これらのコマンドを実行するためのデータベース ラウンドトリップが続きます。

これに対し、一括 (セット ベース) の更新では、データベースに対して行う必要がある変更を定義し、最初にエンティティをメモリに読み込まずにそれらの変更を実行する必要があります。 これは、特に同じ変更を多くの異なるエンティティや行に適用する必要がある場合に、追跡対象の更新よりも大幅に高速になる可能性があります。

EF7 では、一括更新と削除を実装する予定です (ただし、挿入は実装しない)。 一括更新は、バッチ更新と同じではないことに注意してください。 EF Core では、SaveChanges を介してデータベースに更新を送信するときに、追跡対象の多くのエンティティに対する変更が既にバッチに結合されています。

ライフサイクル フック

追跡: 問題 #626: ライフサイクル フック

価値提案: EF コードで興味深いことが発生したときにアプリケーションが対応できるようにします。

ライフサイクル フックを使用すると、エンティティ、プロパティ、リレーションシップ、クエリ、コンテキスト インスタンス、およびその他の EF コンストラクトに対して特定の興味深い条件やアクションが発生するたびに、アプリケーションまたはライブラリの通知が有効になります。 さまざまなインターセプターイベントなど、EF Core の以前のバージョンに対して多くのライフサイクル フックを実装しました。 EF7 では、重要な欠落しているフックを追加する予定です。 たとえば、エンティティ インスタンスを作成した後に操作するためのフックは、一般に ObjectMaterialized と呼ばれます。

Table-Per-Concrete-Type (TPC) マッピング

追跡: 問題 #3170: TPC 継承マッピング パターン

価値提案: TPT マッピングのパフォーマンス ヒットを受けることなく、階層内のエンティティを別のテーブルにマップします。

EF Core では、.NET 継承階層の Table-Per-Hierarchy (TPH)Table-Per-Type (TPT) マッピングがサポートされています。 Table-Per-Concrete-Type (TPC) マッピングは、階層内の各エンティティ型が異なるデータベース テーブルにマップされるという点で TPT マッピングに似ています。 しかし、TPT では基本型のプロパティをその基本型のテーブル内の列にマップしますが、TPC ではマップされる実際の具象型と同じテーブルに基本型のプロパティをマップします。 これにより、特定の型に対してクエリを実行するときに複数のテーブルを結合する必要がないため、大幅により高速なパフォーマンスが得られる可能性があります。 その代わりに、階層の各具象型にマップされたテーブル内の列が重複するため、データが非正規化されます。

TPC マッピングの作業では、より一般的なエンティティ分割、および TPT、TPC、またはエンティティ分割でのテーブルごとに異なるファセットの指定のサポートもカバーされます。

CUD 操作をストアド プロシージャにマップする

追跡: 問題 #245: 挿入、更新、削除 (CUD 操作) をストアド プロシージャにマップする

価値提案: ストアド プロシージャを使用してデータ変更を管理します。

EF Core では、ストアド プロシージャからのデータのクエリが既にサポートされています。 この機能を使用すると、SaveChanges によって生成された挿入、更新、および削除をデータベース内のストアド プロシージャにマッピングできます。

値オブジェクト

Issue #9906: C# 構造体またはクラスを値オブジェクトとして使用する」によって追跡

価値提案: アプリケーションでは、EF モデルで DDD スタイルの値オブジェクトを使用できます。

以前は、集計のサポートを目的として、エンティティを所有するのはチーム ビューであり、値オブジェクトに対する妥当な近似でもありました。 経験上、そうではないことがわかりました。 そのため、EF7 では、ドメイン駆動設計での値オブジェクトのニーズに焦点を当てて、より優れたエクスペリエンスの導入が計画されています。 この方法は、所有エンティティではなく値コンバーターに基づいています。

この作業の最初の対象は、複数の列にマップする値コンバーターを可能にすることです。 リリース時のフィードバックに基づいて、サポートが追加される可能性があります。

値コンバーターを使用する場合の値の生成をサポートする

追跡: 問題 #11597: コンバーターを使用して、より多くの型の値の生成をサポートする

価値提案: DDD スタイルのカプセル化されたキー型では、自動的に生成されるキー値を最大限に活用できます。

EF Core 6.0 では、値コンバーターを介してマップされたキーで、より多くの型の値の生成を使用することができました。 EF7 では、このサポートを一般化して拡張する予定です。

マップされていない型の生 SQL クエリ

Issue #10753: 結果のエンティティ型を定義せずに生 SQL クエリをサポートする」によって追跡

価値提案: アプリケーションでは、ADO.NET にドロップしたり、サードパーティ製ライブラリを使用したりすることなく、より多くの型の生 SQL クエリを実行できます。

現在、生 SQL クエリでは、キーが定義されているかどうかにかかわらず、モデル内の型を返す必要があります。 EF7 では、EF モデルに含まれていない型を直接返す生 SQL クエリを許可する予定です。

ここでの作業では、GuidDateTimeintstringなどの単純またはスカラー型を返す生 SQL クエリもカバーされます。

データベース スキャフォールディング テンプレート

追跡: 問題 #4038: 既存のデータベースからエンティティ型と DbContext をスキャフォールディングするためのコード テンプレート

価値提案: dotnet ef database scaffold によって生成されるコードは完全にカスタマイズできます。

既存のデータベースからスキャフォールディング (リバース エンジニアリング) するときに生成されるコードを調整する要求を頻繁に受け取ります。 生成されたエンティティの型と DbContext に対して T4 テンプレートをサポートすることで、EF7 でこれらの要求に対処する予定です。 開発者は標準テンプレートをカスタマイズしたり、新しいテンプレートを最初から作成したりできます。

テーマ: .NET プラットフォームとエコシステム

EF7 で計画されている作業の多くには、さまざまなプラットフォームとドメインにわたる .NET のデータ アクセス エクスペリエンスの向上が含まれます。 これには、必要に応じて EF Core での作業が含まれますが、.NET テクノロジ全体で優れたエクスペリエンスを確保するために他の領域での作業も含まれます。 EF7 リリースでは、次のプラットフォームやテクノロジに焦点を当てます。

このリストは、顧客データ、戦略上の方向性、利用可能なリソースなど、多くの要因に基づいています。 これらのプラットフォームに対して取り組む一般的な領域の概要を以下に示します。

分散トランザクション

追跡: dotnet/runtime の問題 #715: System.Transactions で分散または昇格されたトランザクションを実装する

価値提案: 分散トランザクションを使用する .NET Framework アプリケーションを .NET 7 に移植できます。

.NET Framework の System.Transactions ライブラリには、分散トランザクションをサポートするために Windows 分散トランザクション コーディネーター (DTC) を利用するネイティブ コードが含まれています。 このコードが .NET Core に移植されたことはありません。 .NET 7 の期間では、この機能を最新の .NET に導入するプロセスを調査して開始する予定です。 これは最初に Windows でのみ行われ、ADO.NET プロバイダーでも分散トランザクションがサポートされるデータベース シナリオのみがサポートされます。 WCF など、分散トランザクションのその他の使用は、.NET 7 ではサポートされません。 フィードバックとコストに基づいて、今後のリリースで他のシナリオや Windows 以外のプラットフォームのサポートを実装する可能性があります。

EF Core ツール

追跡: 問題 #26798: EF Core ツールを最新化する

価値提案: dotnet ef コマンドは使いやすく、最新のプラットフォームやテクノロジで動作します。

.NET プラットフォームは、EF Core 1.0 で移行、データベース スキャフォールディングなどのツールを初めて導入して以来進化しています。 EF7 では、ツール アーキテクチャを更新して、.NET MAUI などの新しいプラットフォームをより適切にサポートし、複数のプロジェクトの使用などの領域でプロセスを効率化する予定です。 これには、問題が発生したときのフィードバックの向上、ログ記録、パフォーマンス、新しい sugar との統合の向上が含まれます。

EF Core とグラフィカル ユーザー インターフェイス

追跡: 問題 #26799: データ バインディングとグラフィカル インターフェイスのエクスペリエンスを向上させる

価値提案: EF Core を使用してデータ バインドされたグラフィカル アプリケーションを簡単に構築できます。

EF Core は、Windows フォームや .NET MAUI などのデータ バインディング シナリオで適切に動作するように設計されています。 しかし、これらのテクノロジ間の点をつなぐことは、必ずしも簡単であるとは限りません。 EF7 では、EF Core と Visual Studio の両方の作業でエクスペリエンスを向上させ、EF Core を使用してデータ バインド アプリケーションを簡単に構築できるようにする予定です。

SqlServer.Core (Woodstar)

追跡: .NET Data Lab リポジトリで

価値提案: 最新の .NET アプリケーションの SQL Server と Azure SQL への高速でフル マネージドのアクセス。

Microsoft.Data.SqlClient は、SQL Server 用の完全な機能を備えた ADO.NET データベース プロバイダーです。 .NET Core と .NET Framework の両方で、広範な SQL Server 機能がサポートされています。 しかし、その動作間での多くの複雑なやり取りが含まれる、大規模で古いコードベースでもあります。 これにより、より新しい .NET Core 機能を使用して得られる可能性のある潜在的利益を調査することが困難になります。

昨年、.NET 用の高パフォーマンス SQL Server ドライバーの可能性を調査するために、口語では "Woodstar" として知られるプロジェクトを開始しました。 EF7 の期間に、このプロジェクトにさらに多くの投資を行う予定です。

重要

Microsoft.Data.SqlClient への取り組みは変わりません。 EF Core であってもなくても、引き続き SQL Server と Azure SQL の両方に接続するための推奨される方法です。 新しく導入される SQL Server のフィーチャーは引き続きサポートされます。

Azure Cosmos DB プロバイダー

追跡: "area-cosmos" というラベルが付けられていて 7.0 のマイルストーンに含まれる問題

価値提案: 引き続き、EF Core での Azure Cosmos DB の操作が最も簡単で生産性が高くなるようにします。

6.0 リリースでは EF Core Azure Cosmos DB データベース プロバイダーに関する大幅な機能強化が行われました。 これらの機能強化により、EF Core から Azure Cosmos DB を操作するためのファースト クラスのエクスペリエンスが得られました。これは、導入の大幅な増加によって反映されています。 EF7 では、次のさらなる Azure Cosmos DB プロバイダーの機能強化により、この勢いを持続する予定です。

最大の利益を得るために投資する場所を評価できるように、必要な Azure Cosmos DB プロバイダー機能に必ず投票 (👍) してください。

移行エクスペリエンス

追跡: 問題 #22946: データベース移行の機能強化

価値提案: 簡単に移行を開始し、後で CI/CD パイプラインで効果的に使用できます。

EF Core 6.0 では、移行バンドルが導入され、継続的インテグレーションおよびデプロイ システム内のクラウドネイティブ アプリケーションとデータベース デプロイのエクスペリエンスが大幅に向上しました。 EF7 では、お客様からのフィードバックに基づいて、この領域をさらに改善する予定です。 たとえば、問題が発生した場合の回復を容易にするために、単一トランザクションでのすべての移行の実行をサポートする予定です。

さらに、移行を開始する開発者のエクスペリエンスを向上させる予定です。 これには、プロジェクトの学習時または開始時にデータベースを自動的に作成し、プロジェクトの成熟に伴い、マネージド移行に簡単に切り替えられることが含まれます。 あるいは、既存のデータベースを使用するプロジェクトの場合は、初期 EF モデルを簡単に作成し、将来的には移行を使用するデータベースの管理に切り替える予定です。

最新の .NET

.NET が進化し続けるにつれて、データへのアクセスが引き続き優れたエクスペリエンスになるようにしたいと考えています。 これを容易にするために、EF7 の期間中に 3 つの領域を進める予定です。

トリミング

追跡: 問題 #21894: アプリケーション サイズを小さくするための EF Core アプリでのトリミング サポートを改善する

価値提案: 効率的に AOT コンパイルできるより小規模なアプリケーション。

EF Core では、大量のランタイム コードの生成が実行されます。 これは、Xamarin や Blazor のようなリンカー ツリーのシェイキングに依存するアプリ モデルや、iOS のような動的コンパイルを実行できないプラットフォームでは課題になっています。 EF7 では未使用のコードのトリミングを大幅に改善する予定です。 これにより、EF Core を使用する場合のアセンブリ サイズがより小さくなるため、デプロイが容易になり、Ahead-Of-Time (AOT) コンパイルがより効率的になります。

System.Linq.Expression を進化させる

価値提案: LINQ クエリで最新の C# 言語機能を使用します。

Roslyn チームと協力して、LINQ 式でより多くの C# 機能を使用できるように計画しています。 これは、主に EF Core リポジトリの外部で追跡される進行中の作業です。

新しい LINQ 演算子を変換する

追跡: 問題 #25570: .NET LINQ の新機能をサポートする

価値提案: LINQ クエリを SQL に変換するときに、新しい LINQ 演算子を使用します。

新しい LINQ 演算子は最近 BCL に追加されました。今後さらに追加されることが予想されます。 問題 #25570 では、EF7 LINQ プロバイダーへのこれらのサポートの追加を追跡します。 この問題は、新しい LINQ 演算子が追加されると更新されます。 既存のすべての LINQ 演算子と同様に、演算子でデータベースに対して妥当で有用な変換を行っている場合にのみサポートを追加します。

ADO.NET プロバイダー用の Open Telemetry

追跡: 問題 #22336: データベース トレース用に DiagnosticSource/OpenTelemetry を標準化する

価値提案: 選択したツールで監視できるクロスプラットフォームの業界標準テレメトリ。

Open Telemetry は、クラウドネイティブ ソフトウェアの一般的なテレメトリ メカニズムを促進するための Cloud Native Foundation のイニシアチブです。 データベースに関しては、これにはデータベース クライアント テレメトリ標準の確立が含まれます。 .NET エコシステム内の ADO.NET プロバイダーに Open Telemetry を提供するのに役立つように、EF7 期間で作業を行う予定です。 これには、Microsoft.Data.Sqlite だけでなく、オープン ソースの MySQL および Npgsql プロバイダーのコミュニティとの連携が含まれます。 また、他のプロバイダーにも連絡し、ADO.NET プロバイダーの保守担当者が関心がある場合は連絡を取ることをお勧めします。

System.Data の機能強化

追跡: 7.0 のマイルストーンで area-System.Data というラベルが付けられている dotnet\runtime リポジトリの問題

価値提案: 低レベルのデータ アクセスを向上させ、より高レベルのすべてのコードにメリットをもたらします。

すべてのリリースと同様に、.NET の低レベルのデータベース アクセス API、System.Data の改善を検討する予定です。 パフォーマンスの向上 (たとえば、API を使用するときにボックス化を排除してメモリ割り当てを減らす) と、いくつかの使いやすさの向上に重点を置きます。

正確な改善の範囲は、後で実現可能性に基づいて決定されます。

クラウドネイティブのデータ アクセスを調査する

価値提案: マイクロサービスやクラウド ネイティブなどの最新のアプローチをサポートする .NET データ アクセスの今後の進化。

EF7 の期間では、特にマイクロサービスとクラウドネイティブ アプリケーションに関して、.NET プラットフォーム全体のデータ アクセスに対する最新のアプローチを調査する予定です。 この調査は、.NET のデータ アクセス テクノロジへの今後の投資を促進するのに役立ちます。

テーマ: EF6 からパスを前方にクリアする

追跡: ドキュメントに関する問題 #1180: EF6 からの移植に関するより完全なガイドを提供する

価値提案: アプリケーションを EF6 から EF7 に簡単に移動できます。

EF Core では常に、レガシ EF6 スタックでカバーされていない多くのシナリオがサポートされており、一般にはるかに高いパフォーマンスが実現しています。 しかし、EF6 でも同様に、EF Core でカバーされていないシナリオがサポートされています。 EF7 では、これらのシナリオの多くのサポートが追加され、より多くのアプリケーションでレガシ EF6 から EF7 に移植できるようになります。 同時に、レガシ EF6 から EF Core に移行するアプリケーションの包括的な移植ガイドを計画しています。

このテーマの作業の多くは、既述の作業と重複しています。 より重要な作業項目の一部を以下に示します。

さらに、レガシ EF6 GitHub リポジトリで、EF6 での今後の作業を計画していないことを明確にする予定です。 ただし、Microsoft.Data.SqlClient で EF6 を使用するためのサポートを追加する予定です。 これはランタイム サポートに限定されます。 Visual Studio で EF6 デザイナーを使用するには、引き続き System.Data.SqlClient が必要です。

EF Core には、EF6 とは根本的に異なるアーキテクチャがあることに注意してください。 特に、Entity Data Model (EDM) の仕様は利用されません。 つまり、EF Core では EDMX や EntitySQL などの特定の機能がサポートされることはありません。

テーマ: パフォーマンス

優れたパフォーマンスは、EF Core、低レベルのデータ アクセス、および実際にすべての .NET の基本原則です。 すべてのリリースには、パフォーマンスの向上に関する重要な作業が含まれています。 これまでと同様に、このテーマには多くの反復的な調査が含まれ、リソースに重点を置く場所が示されます。

データベースの挿入と更新のパフォーマンス

追跡: 問題 26797: 変更の追跡と更新のパフォーマンスを向上させる

価値提案: EF Core からのハイ パフォーマンス データベースの挿入と更新。

過去のいくつかのリリースでは、非追跡クエリでの EF Core のパフォーマンスの向上に重点を置きました。 EF7 では、データベースの挿入と更新に関連するパフォーマンスに重点を置く予定です。 これには、変更追跡クエリのパフォーマンス、DetectChanges のパフォーマンス、データベースに送信される挿入と更新コマンドのパフォーマンスが含まれます。

この作業の一部には、一括 (セット ベース) 更新の実装が含まれます。これは、要求の多い機能として上記で追跡されています。 しかし、SaveChanges を使用して従来の更新のパフォーマンスも向上させる予定です。

TechEmpower 複合スコア

追跡: 問題 26796: TechEmpower 複合スコアのパフォーマンスを向上させる

価値提案: すべての .NET アプリケーションでの高パフォーマンスで低レベルのデータ更新。

何年も、業界標準の TechEmpower ベンチマークを .NET 上で PostgreSQL データベースに対して実行してきました。 過去のいくつかのリリースでは、低レベルのデータ アクセスと EF Core の両方について、Fortunes ベンチマークが大幅に改善されました。

EF7 期間では、特に TechEmpower 複合スコアの改善を目標にする予定です。 これにより、より広い範囲のシナリオでパフォーマンスが測定されます。

その他の機能

追跡: 7.0 のマイルストーンで type-enhancement というラベルが付けられている問題

価値提案: 既存および進化するアプリケーション要件を満たすために EF Core を継続的に改善します。

EF 7.0 では他に次のような機能が計画されていますが、これらに限定されません。

推奨事項

計画に関するフィードバックは重要です。 計画に関するフィードバックや一般的な提案については、GitHub Issue #26994 にコメントしてください。 issue の重要度を示す最善の方法は、GitHub でその issue に投票 (👍) することです。 このデータが、次のリリースの計画プロセスに取り込まれます。