CodeFirstは大規模なアプリケーションを対象としていますか？
私はEntity Framework、特にEF 4.1について読み、このリンク（ http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development- with-entity-framework-4.aspx ）とコードファーストのガイドです。
きちんとわかりましたが、疑問に思っていました。CodeFirstは、迅速な開発のためのソリューションであり、あまり計画を立てなくてもすぐに始められるのでしょうか、それとも実際に大規模アプリケーションで使用することを意図しているのですか？
私はそこに批判者がいるかもしれませんが、HanselmanとGutherieからそれらの投稿のいくつかを読んだ後、Entity Frameworkで Julia Lermanの本 を読んだとき、最初にコードで本当に苦労しました。アプリケーションを構築してきた長年の間に、プロセスと選択の両方によって多くの道を歩み、アプリケーションを構築するときにデータ中心の視点をとることで、はるかに成功することがわかりました。
ここでは、基幹業務アプリケーションについて話しています。これは、背後にソフトウェアソリューションが必要なビジネス上の問題またはプロセスがある場合です。何らかの方法で管理する必要のあるデータがあります。あなたのデータとそれがどのように関連しているか、そしてそれがビジネス内でどのように使用されているかを知っている方が良いでしょう。したがって、そのデータをモデル化し、その周りにアプリケーション/ソリューションを作成します。私の経験では、後付けのデータを使用してアプリケーションの作成を開始すると、最終的に何かが取り除かれ、その後、リファクタリングが行われます（多くの場合、メジャーリファクタリング）。
小さなアプリケーションは例外かもしれませんが、私はデータ中心のアプローチを使い続けます。
CodeFirstを大規模なエンタープライズプロジェクトで使用できない理由はわかりません。私はいくつかのプロジェクトでEF CodeFirstを使用していると言います。1つはEF CodeFirstモデルによってデータベースが生成され、もう1つはEF CodeFirstが既存のデータベースにマップされるプロジェクトです。
私の経験から、大規模なプロジェクトでのCFの効果は、ビジネスレイヤーからデータレイヤーを抽象化する方法に大きく依存します。
たとえば、私のプロジェクトの1つでは、ビジネスレイヤーがlinqを介してデータベースを直接呼び出します。 Linqを使用してデータベースレイヤーを抽象化し、CodeFirstを使用してPOCOをデータベーススキーマにマップします。この場合、CodeFirstは、DBの規則（リレーションシップとテーブル名）とC＃クラス名の違いを維持する作業を大幅に簡素化し、ビジネスレイヤーがデータベースと対話する方法に大きな影響を与えることなくデータベースを変更できます。
ただし、別のプロジェクトでは、データベースアクセスを非ジェネリックリポジトリパターンに抽象化し、リポジトリのGet *メソッドはデータベースでクエリを実行することのみを担当し、実際のオブジェクトを返します（IQueryable<T>sではありません）。この場合、リポジトリメソッドはDBエンティティをPOCOエンティティに変換します。この場合、CodeFirst POCOは短命であり、ビジネスレイヤーC＃クラスにすばやく変換されるため、CodeFirstはそれほどメリットがありません。
最終的には、チームがどのように構造化されているか、データベーススキーマを変更する非DBAエンジニアがチーム（またはシニア）がどの程度快適であるか、およびスキーマの変更がコード構造にどの程度影響するかによります。 CodeFirstが既存のデータベースにマップされているので、プロパティ名のグローバルな名前変更を行わなくても、プロパティを新しい列名に再マップするのは簡単です。これは、特に、より意味のある名前について話しているときの要因です。 C＃プロパティではなくデータベースフィールドの場合。また、C＃エンティティを完全に改造することなく、新しいデータベースフィールドのコードサポートを追加するのも簡単です（Linq-to-sqlを既存のデータベースからEF CodeFirstに任せた理由の1つ）。
Code Firstは大規模なアプリケーションには適していません。大規模なアプリ開発のターンアラウンドは非常に巨大です。
通常、ビジネスアプリのライフサイクルは、
- バージョン1は生産中です
- バージョン2はベータ版です
- バージョン3は開発中です
- バージョン4は計画中です。
そして、他のクロスアプリケーション通信ブリッジ、いくつかのスケジュールされたタスク、いくつかのサードパーティ統合、モバイルなどのいくつかの異なる通信デバイスのためのウェブサービスがあります。
最終的には、Code FirstはEntity ModelのObjectContextを使用し、古いEFはEDMXを生成し、ObjectContextをEntityObjectと共に使用することで、すべてに十分に対応できました。テキストテンプレートを簡単にカスタマイズしてコードを生成できます。変更の検出メソッドはObjectContext実装の方が低速ですが、プロキシを生成する代わりに、EFチームは最初にコードを再発明する代わりに、変更の検出速度を簡単に改善できました。
自動移行
自動移行は理論的には良さそうに聞こえますが、いったんライブに移行すると実際には不可能です。プロトタイピング、クイックデモの開発にのみ適しています。
このようなシステムでは、コードファーストマイグレーションはまったく適していません。バージョン1とバージョン2は、ほとんどの場合、同じデータベースと通信します。バージョン3とバージョン4は通常ステージングであり、データベースが異なります。
データベースが最初
Database Firstは実用的なアプローチであり、SQLスクリプトの比較、視覚化、維持が簡単です。 DBAは簡単に作業できます。
テキストテンプレート
独自のテキストテンプレートを作成して、EDMXおよびObjectContextをクエリおよび作成し、パフォーマンスの問題に対処するカスタム実装はほとんどありません。問題なく同じデータベースと通信する複数のバージョンを持つ複数のアプリケーションがあります。
私にとって、.ttファイルを右クリックして[カスタムツールの実行]をクリックすることは、クラスを記述してモデルを構成および作成するよりもはるかに速くて簡単なステップです。
通常、大規模なプロジェクトの場合、データベースはすでに作成されています。これは、レガシーデータベースであるか、パフォーマンスのために適切なdbaによって作成されたためです。 CodeFirstの唯一の利点は、EFのエンティティではなくPOCOを使用する場合です。
"コードファースト"はEFをより "アジャイル"（その用語についてはあまりハープしないでください、私は必ずしも方法論を意味するものではありません）で使用するためのものであり、グリーンフィールドアプリは、既存のデータモデルまたは既存のデータ。 Djangoを使用できるアプリの種類、またはPHPフレームワーク、またはRailsこれらのフレームワークのガイドラインに従うことにより、通常は次のようにデータモデルを作成します。従来のマイクロソフトの処理方法であるデータモデルを中心にアプリケーションを構築する代わりに、コードの一部。
だから質問に答えるなら、私はノーと言うでしょう。すでに既存のデータがあり、それを処理するアプリケーションを作成している場合、Code Firstはそれほど意味がありません。ただし、EFはコードファーストEFはもちろんのこと、あまり使用していません。コードへの疎結合アプローチであり、常にメリットがあるようです。 Code Firstを使用し、クラスを既存のデータモデルにポイントできる（モデルを強制的に生成するのではなく）と仮定すると、Code Firstアプローチは、通常のすべての「粗末」を使用せずに、適切に抽象化されたテスト可能なコードを書くのに役立ちます。エンティティフレームワーク（つまり、生成されたメタクラス）。
本当に大きなプロジェクトでは、コードファーストは意味がありません。
実際、プロジェクトが非常に大きくなると、懸念事項が厳密に分離されることがよくあります。同じ人がC＃コードを書いたり、データベース設計をしたり、HTML/CSSを書いたり、Photoshopでビジュアルデザインをしたりすることはできません。代わりに、データベースの設計はデータベース管理者（または少なくとも自分の仕事を知っている専任の担当者）が行います。
データベースは、データベース、SQL、管理、およびデータベース設計ツールに精通している人が設計するため、この人がEntity Frameworkを使用しているのを見るのは奇妙です。
さらに、Entity Frameworkがデータベースを適切に設計するのに十分強力かどうかはわかりません。インデックスについてはどうですか？制約？ビュー？
大規模なシステムでもコードを最初に実行可能：作成後にモデルを調べ、Fluent APIを使用して、希望のデータベースモデルに到達するまでリマップします。