EF6 から EF Core へのポート - 信頼できるソースとしてのデータベース

データベースを信頼できるソースとして使用している場合、アップグレードには、ほとんどの場合、生成されるエンティティの形状に対する変更に対処する必要があります。 移行する手順は次のとおりです。

1. データベースをモデル化するポイントインタイムを選択します。
2. EF6 プロジェクトが最新であり、データベースと同期していることを確認します。
3. EF Core プロジェクトを作成します。
4. スキャフォールディング ツールを使用して、データベースをコードにリバース エンジニアリングします。
5. EF Core で生成されたクラスがコードと互換性があることを検証します。
6. 例外の場合は、生成されたクラスを変更して モデル構成 を更新するか、コードをモデルに適応させます。

EF Core では現在、データベースのコピーを正常に生成するために必要なすべてのものがスキャフォールディングされていますが、データベース優先のアプローチでは多くのコードは必要ありません。 この問題の修正は 、問題 #10890 で追跡されます。 必要なく無視しても問題ありません。シーケンス、制約名、一意でないインデックス、インデックス フィルターなどです。

スキーマ変更の処理

データベースが信頼のソースである場合、EF Core は、移行経由でスキーマ情報をプッシュするのではなく、データベースからスキーマ情報をプルします。 一般的なワークフローは、データベース スキーマが変更されるたびにリバース エンジニアリング手順を再実行することです。 スキャフォールディング プロセスを自動化し、テストを実行して変更を確認できるため、包括的なテスト スイートは、このアプローチにとって重要です。

モデルの違いを処理するためのヒント

さまざまな理由から、C# ドメイン モデルをリバース エンジニアリングで生成されたものとは異なる形にしたい場合があります。 多くの場合、これは、スキーマの変更後に自動生成されるコードを手動で更新することを意味します。 コードを再生成するときに余分な労力を防ぐ方法の 1 つは、DbContext と関連エンティティに部分クラスを使用することです。 その後、ビジネス ロジックとプロパティに関連するコードを、上書きされない別のクラス ファイルのセットにデータベースで追跡されないようにすることができます。

モデルが生成されたモデルと大きく異なるが、頻繁に変更されない場合は、 リポジトリ パターン をアダプターとして使用することを検討する必要があります。 リポジトリは、EF Core で生成されたクラスを使用し、使用するカスタム クラスを発行できます。 これにより、スキーマが変更されるたびにアプリケーション全体のリファクタリングを実行する必要はなく、変更をリポジトリ コードに分離することで、変更の影響を軽減できます。

代替ワークフローを検討し、 ハイブリッド アプローチと同様の手順に従う必要がある場合があります。 毎回新しいクラス セットを生成する代わりに、新しいクラスのみを生成するように特定のテーブルを指定します。 既存のクラスをそのまま保持し、変更されたプロパティを直接追加または削除します。 次に、モデル構成を更新して、データベースが既存のクラスにマップされる方法の変更に対処します。

コード生成をカスタマイズする

EF Core 6 では現在、生成されたコードのカスタマイズはサポートされていません。 EF Core Power Tools などのサード パーティ製のソリューションを利用できます。 おすすめのコミュニティ ツールと拡張機能の一覧については、「 EF Core のツールと拡張機能」を参照してください。

最後に、 EF6 と EF Core の違いの詳細な一覧 を確認して、移植に関する残りの問題に対処します。