Entity Framework Core (つまり、略して EF Core) は、最新のアプリケーション アーキテクチャ用の Entity Framework の完全な書き換えです。 基本的な変更により、直接アップグレード パスはありません。 このドキュメントの目的は、EF6 アプリケーションを EF Core に移植するためのエンド ツー エンド ガイドを提供することです。
Von Bedeutung
移植プロセスを開始する前に、EF Core がアプリケーションのデータ アクセス要件を満たしていることを検証することが重要です。 必要なものはすべて 、EF Core のドキュメントで確認できます。
Warnung
EF Core では最新の .NET のみがサポートされ、.NET Framework はサポートされません。 そのため、プロジェクトがまだ .NET Framework を対象としている場合は、EF6 から EF Core への移行を開始する前に、最新の .NET に移行する必要があります。 EF6 では最新の .NET がサポートされているため、EF6 を維持しながら最新の .NET に移行してから、EF6 から EF Core への移行に取り組むことができます。
アップグレードの理由
すべての新しい Entity Framework 開発は EF Core で行われています。 EF6 に新機能をバックポートする予定はありません。 EF Core は最新の .NET ランタイムで実行され、ランタイム、プラットフォーム固有 (ASP.NET Core や WPF など) と言語固有の機能を最大限に活用します。 アップグレードによって得られる利点の一部を次に示します。
- EF Core の継続的な パフォーマンス向上を 活用します。 たとえば、EF6 から EF Core 6 に移行したあるお客様は、 クエリ分割機能により、大量のクエリの使用が 40 倍削減されました。 多くのお客様は、最新の EF Core に移行するだけで、パフォーマンスの大幅な向上を報告しています。
- EF Core の 新機能 を使用します。 EF6 に新しい機能は追加されません。
Azure Cosmos DB プロバイダーや
DbContextFactoryなど、すべての新機能は EF Core にのみ追加されます。 EF Core 専用の機能を含む EF6 と EF Core の完全な比較については、「 EF Core と EF6 の比較」を参照してください。 - 依存関係の挿入を使用してアプリケーション スタックを最新化し、データ アクセスを gRPC や GraphQL などのテクノロジとシームレスに統合します。
移行に関する注意事項
このドキュメントでは、EF Core の機能としての移行という用語との混同を避けるために、ポートとアップグレードという用語を使用します。 EF Core での移行は、移行の処理方法が大幅に改善されたため、 EF6 Code First の移行と互換性がありません。 移行履歴を移植するための推奨される方法はないため、EF Core で "新しい" を開始することを計画してください。 EF6 の移行からコードベースとデータを維持できます。 EF6 で最終的な移行を適用し、EF Core で最初の移行を作成します。 EF Core で今後の履歴を追跡できます。
アップグレードの手順
アップグレード パスは、アップグレードのフェーズとアプリケーションの種類別に整理された複数のドキュメントに分割されています。
EF Core の "フレーバー" を決定する
ドメイン モデルとデータベースの実装で EF Core がどのように機能するかには、いくつかの方法があります。 一般に、ほとんどのアプリはこれらのパターンのいずれかに従い、ポートへのアプローチ方法はアプリケーションの "フレーバー" によって異なります。
信頼できるソースとしてのコード は、データ属性、fluent 構成、またはその両方の組み合わせを使用して、コードとクラスを通じてすべてをモデル化するアプローチです。 データベースは、EF Core で定義されているモデルに基づいて最初に生成され、以降の更新は通常、移行によって処理されます。 多くの場合、これは "コード優先" と呼ばれますが、既存のデータベースから開始し、エンティティを生成し、次にコードを進めて維持する方法が 1 つのアプローチであるため、名前は完全には正確ではありません。
信頼できるソースとしてのデータベース アプローチでは、データベースからコードをリバース エンジニアリングまたはスキャフォールディングする必要があります。 スキーマの変更が行われると、変更を反映するようにコードが再生成または更新されます。 これは多くの場合、"データベース優先" と呼ばれます。
最後に、より高度な ハイブリッド マッピング アプローチは、コードとデータベースを個別に管理し、EF Core を使用して 2 つの間でマップするという理念に従います。 通常、このアプローチは移行を避けます。
次の表は、いくつかの大まかな違いをまとめたものです。
| アプローチ | 開発者ロール | DBA ロール | 移行 | スキャフォールディング | リポジトリ |
|---|---|---|---|---|---|
| 最初のコード | エンティティを設計し、生成された移行を確認/カスタマイズする | スキーマ定義と変更を確認する | コミットごと | なし | エンティティ、DbContext、移行を追跡する |
| データベース優先 | 変更後のリバース エンジニアリングと生成されたエンティティの検証 | データベースが再スキャフォールディングに変更されたときに開発者に通知する | なし | スキーマの変更ごと | 生成されたエンティティを拡張する拡張機能/部分クラスを追跡する |
| ハイブリッド | エンティティまたはデータベースが変更されるたびにマップするように fluent 構成を更新する | エンティティとモデルの構成を更新できるように、データベースが変更されたときに開発者に通知する | なし | なし | エンティティと DbContext を追跡する |
ハイブリッド アプローチは、従来のコードとデータベースのアプローチと比較してオーバーヘッドが増える、より高度なアプローチです。
EDMX からの移行の影響を理解する
EF6 では、 Entity Data Model XML (EDMX) という名前の特殊なモデル定義形式がサポートされました。 EDMX ファイルには、概念スキーマ定義 (CSDL)、マッピング仕様 (MSL)、ストア スキーマ定義 (SSDL) など、複数の定義が含まれています。 EF Core は、内部モデル グラフを使用してドメイン、マッピング、およびデータベース スキーマを追跡し、EDMX 形式をサポートしていません。 多くのブログ記事や記事では、EF Core では "コード優先" のみがサポートされているということです。EF Core では、前のセクションで説明した 3 つのアプリケーション モデルがすべてサポートされています。 データベースをリバース エンジニアリングすることで、EF Core でモデルを再構築できます。 エンティティ モデルを視覚的に表現するために EDMX を使用する場合は、EF Core に同様の機能を提供するオープン ソースの EF Core Power Tools の使用を検討してください。
EDMX ファイルのサポート不足の影響の詳細については、 移植 EDMX ガイドを 参照してください。
アップグレード手順を実行する
アプリケーション全体を移植する必要はありません。 EF6 と EF Core は、同じアプリケーションで実行できます (同 じアプリケーションでの EF Core と EF6 の使用を参照)。 リスクを最小限に抑えるために、次の点を考慮する必要があります。
- まだ行っていない場合は、.NET Core の EF6 に移動します。
- アプリのごく一部を EF Core に移行し、EF6 と並行して実行します。
- 最終的に、残りのコードベースを EF Core に移行し、EF6 コードを廃止します。
移植自体については、大まかに次を実行します。
- EF6 と EF Core の間の動作の変更を確認します。
- EF6 で最終的な移行 (ある場合) を実行します。
- EF Core プロジェクトを作成します。
- コードを新しいプロジェクトにコピーするか、リバース エンジニアリングを実行するか、両方の組み合わせを実行します。
- 参照とエンティティの名前を変更し、動作を更新します。
-
System.Data.EntityからMicrosoft.EntityFrameworkCoreへ - オプションを使用したり
DbContextをオーバーライドしたりするためにOnConfiguringコンストラクターを変更する -
DbModelBuilderからModelBuilderへ -
DbEntityEntry<T>の名前をEntityEntry<T>に変更する -
Database.LogからMicrosoft.Extensions.Logging(高度な) API またはDbContextOptionsBuilder.LogTo(単純) API に移行する -
WithRequiredとWithOptionalに変更を適用する (こちらを参照) - 検証コードを更新します。 EF Core に組み込まれているデータ検証はありませんが、自分で 行うことができます。
- 必要な手順に従って EDMX から移植します。
-
- EF Core のアプローチに基づいて特定の手順を実行します。
すべてのアプローチに関連する多くの考慮事項があるため、 EF6 と EF Core の詳細な違いに対処して回避する方法を確認することもできます。
GitHub で Microsoft と共同作業する
このコンテンツのソースは GitHub にあります。そこで、issue や pull request を作成および確認することもできます。 詳細については、共同作成者ガイドを参照してください。
.NET