EF6 から EF Core への移植
Entity Framework Core (EF Core) は、最新のアプリケーション アーキテクチャのためにEntity Framework を完全に書き換えたものです。 基本の変更により、直接アップグレード パスがありません。 このドキュメントの目的は、EF6 アプリケーションを EF Core に移植するためのエンドツーエンド ガイドを提供することです。
重要
移植プロセスを開始する前に、EF Core がご自身のアプリケーションのデータ アクセス要件を満たしていることを確認することが重要です。 必要な情報はすべて、EF Core のドキュメントに記載されています。
重要
移植性アナライザーには .NET 5 および .NET 6 と互換性がないと EF Core に誤って報告される既知のイシュー (microsoft/dotnet-apiport #993) があります。 EF Core が .NET 5 および .NET 6 のターゲット フレームワークと 100% 互換性がある場合、これらの警告は無視しても問題ありません。
アップグレードする理由
新しい Entity Framework 開発はすべて、EF Core で発生しています。 新機能を EF6 にバックポートする予定はありません。 EF Core は最新の .NET ランタイム上で実行され、ランタイム、プラットフォーム (ASP.NET Core や WPF など) 固有で言語固有の機能をフル活用します。 アップグレードによって得られるベネフィットの一部を次に示します。
- EF Core で継続的なパフォーマンスの改善を活用できます。 たとえば、EF6 から EF Core 6 に移行したあるお客様は、クエリ分割機能により、負荷の高いクエリの使用が 40 分の 1 に削減されました。 多くのお客様は、最新の EF Core に移行するだけで、パフォーマンスが大きく改善したと報告しています。
- EF Core の新機能を使用します。 EF6 に追加される新機能はありません。 Azure Cosmos DB プロバイダーや
DbContextFactoryなど、すべての新しい機能が追加されるのは EF Core のみです。 EF6 と EF Core の完全な比較 (EF Core 専用の機能を含む) については、「EF Core と EF6 を比較する」を参照してください。 - アプリケーション スタックの最新化を依存関係の挿入を使用して行い、データ アクセスを gRPC や GraphQL などのテクノロジとシームレスに統合します。
移行に関するメモ
このドキュメントでは、"移行" という用語が EF Core の機能と混同されないように、 "移植" と "アップグレード" という用語が使用されています。 移行の処理方法が大幅に改善されているため、EF Core の移行は EF6 Code First Migrations と互換性がありません。 移行履歴の移植に推奨されるアプローチはありません。そのため、EF Core で "新しく" 開始することを計画してください。 EF6 移行のコードベースとデータは維持できます。 EF6 で最終的な移行を適用してから、EF Core で最初の移行を作成します。 これで、以後 EF Core で履歴を追跡できるようになります。
アップグレードの手順
アップグレード パスは、アップグレードのフェーズとアプリケーションの種類によって整理された複数のドキュメントに分割されています。
EF Core の "フレーバー" を決定する
EF Core がドメイン モデルとデータベースの実装を行うには、いくつかのアプローチがあります。 一般に、ほとんどのアプリがこれらのパターンのいずれかに従い、移植へのアプローチ方法はアプリケーションの "フレーバー" によって異なります。
真のソースとしてのコードは、データ属性、fluent 構成、または両方の組み合わせによって、コードとクラスを通じてすべてがモデル化されるアプローチです。 データベースは、最初に EF Core に定義されているモデルに基づいて生成され、その後の更新は通常、移行を通じて処理されます。 これは "コード ファースト" と呼ばれることが多いですが、この名前は完全に正確なわけではありません。あるアプローチでは、既存のデータベースから開始し、エンティティを生成し、コーディングしながら維持するからです。
真のソースとしてのデータベースのアプローチでは、データベースからコードをリバース エンジニアリングまたはスキャフォールディングする必要があります。 スキーマの変更が行われた場合、変更の反映のためにコードは再生成または更新されます。 これはよく "データベース ファースト" と呼ばれます。
最後に、より高度なハイブリッド マッピングのアプローチは、コードとデータベースを個別に管理し、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- オプションを使用したり
OnConfiguringをオーバーライドしたりするためにDbContextコンストラクターを変更する DbModelBuilder～ModelBuilderDbEntityEntry<T>の名前をEntityEntry<T>に変更するDatabase.LogをMicrosoft.Extensions.Logging(高度) またはDbContextOptionsBuilder.LogTo(単純) API に移行するWithRequiredとWithOptionalの変更を適用する (こちらを参照してください)- 検証コードを更新する。 EF Core に組み込まれたデータ検証はありませんが、自分で実行することができます。
- 必要なステップに従って EDMX から移植する。
- EF Core のアプローチに基づいて特定のステップを実行します。
すべてのアプローチに関連する多くの考慮事項があります。そのため、EF6 と EF Core の間の詳細な違いに対処して回避する方法も確認する必要があります。
.NET
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示