データベースで最初にテーブルを作成し、次にプロジェクトを自動的に更新することが主な目的である場合は、データベース ファーストを使用する必要があります。
とはいえ、データベース ファーストの欠点を考慮する必要があります。私の個人的な経験では、主に次の 2 つの理由により、このアプローチの使用をやめました。
- 私の知る限り、Database First のサポートは終了します。 EF Core にはエディター ツールは含まれていません。これに関するいくつかのリンク:Julie Lerman からの投稿 、EF Core ロードマップ 、および Microsoft からの早期発表 .
- モデル エディタにはいくつかのバグや癖があり、コードがときどき壊れていました。これらのバグは修正されない可能性が高いです (前のポイントを参照)。既存のフィールドの型の変更、外部キーの変更など
- 自動生成されたエンティティ ファイルのソース コード リポジトリのマージが原因で、多くの問題が発生しました。特に（それだけではありませんが）複数の人が同じエンティティで作業していたため、自動生成されたコードでマージの競合が発生していました。また、自動生成されたコードが正しくチェックアウトされないことがあり、edmx と同期しなくなりました。これが他の人にも起こるかどうかはわかりませんが、Visual Studio、エディター、バックグラウンド自動コード生成ツール、および TFS ソース コード マネージャーがうまく連携しないことがあるようです。
したがって、最初にデータベース内のテーブルを作成せずに本当に生きていけない場合は、データベース ファーストを使用しますが、コード ファーストを使用しないと何を失うかを考慮する必要があります。このアプローチは、理由により広く推奨されています。
通常、最近 Database First を使用する主な理由は、レガシー コードを Code First アプローチに移行できないことです。私の知る限り、Code First が正しい方法であることが広く受け入れられています。 これに関する興味深い投稿があります (Code First が導入されたときの EF 4.1 用に書かれた少し古いものであっても、各アプローチの主な長所と短所を扱っています)。
回避策として、Code First を引き続き使用すると同時に、データベース テーブルからリバース エンジニアリングを実行して Code First エンティティを自動的に生成するツールを使用することもできます。これにより、引き続きデータベース内にテーブルを直接生成できますが、移行などすべてで Code First を引き続き使用できます。ここに Julie Lerman によるこれらのツールのいくつかに関する投稿 があります。 .もっと新しいツールがあるかもしれませんが、私はそれらを使用したことがなく、それらについて知りません.
注:Database First での私の個人的な経験はちょっと悪く、長続きしませんでした。おそらく、このアプローチでより積極的な経験を持つ人は、それについてより有用な洞察を与えることができます.私はしばらくの間 Code First を使用してきましたが、このアプローチを非常に気に入っています。私の答えは少し偏っているかもしれません。