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

データベースを信頼できるソースとして使用する場合、アップグレードは主に、生成されたエンティティの形に対する変更に対処することに関係します。 移行する手順には以下が含まれます。

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

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

スキーマの変更の処理

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

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

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

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

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

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

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

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