質問: プロジェクト(Identity Server 4サーバー)を開始したときに、ApplicationDBContext(ASP.NET IdentityContextを継承し、いくつかのカスタムテーブルを持っています)を作成し、ConfigurationDBContextとIdentity Server 4のPersistedGrantDBContextを使用しました。各DBContext)。ただし、データは同じデータベース(つまり単一のデータベース)にあります。 次に、コードをリファクタリングして、3つのデータベースすべてを1つのDBContextに持つ新しいDBContextを取得しました。 私の問題は、新しい移行です。 これまでのところ、古いDBContextsを削除し、空のデータベースに対して実行すると、まったく同じデータベースを再度作成する移行を作成しました。 ただし、既存のデータベース(既存のデータを含む)を移行する場合、テーブルXが既に存在するという例外が発生します。 これは、古いコードと古いマイグレーションを削除したためだと思います。 したがって、3つの異なるDBContextを1つの新しいDBContextにマージする移行を作成するにはどうすればよいですか。 古いコードをそのままにして古いマイグレーションも使用すると、テーブルが複数回作成されます(古い分割マイグレーションと新しい結合マイグレーションにあるため)? テーブルが存在する場合にエラーをスローしないように新しいマイグレーションに指示する方法はありますか(同じレイアウトであるため、テーブルをそのまま使用します)。
回答: 私の意見では、3つのデフォルト(古い)コンテキストを維持する必要があります。 理由:3 in 1をマージしてデフォルトのコンテキストを廃止することは非常に悪い習慣です。 1. これら3つのすべてのコンテキストには、データを操作するためのAPIがあります。これらのAPIは、すべてのデータが適切に維持されていることを確認し、Code-Firstを実際のコードファーストにしますが、Code-Onceではありません。 2. それらを1つにマージした場合、それらのプロジェクトでデータベースとAPIを最新の状態に保つにはどうすればよいでしょうか。そして、これらのAPIをどのように実装しますか?それらを再度記述したいですか? 3. Code-Firstは主にデータベースの変更用に設計されています。カスタマイズが必要な場合は、独自のコンテキストでカスタマイズしてください。その後、独自のコンテキストを使用してそれらを1つに結合できますが、残念ながら、相互に競合しないように移行コードを慎重に保守する必要があります。 4. IdentityContextを新しいコンテキストのベースとして使用し、他の2つをここにマージしないことをお勧めします。 3つのコンテキストを保持できます。