CodeFirstは大規模なアプリケーションを対象としていますか？

私はEntity Framework、特にEF 4.1を読んでおり、このリンクをフォローしています（http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- framework-4.aspx）およびCode Firstのガイドです。

私はそれをきれいに見つけましたが、コードファーストは、多くの計画なしですぐに飛び込むことができる迅速な開発のための単なるソリューションであると考えられていますか、それとも実際に大規模なアプリケーションに使用されることを意図していますか？

中傷する人もいるかもしれませんが、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は短期間でビジネスレイヤC＃クラスに迅速に変換されるため、CodeFirstはあまり利点を提供しません。

最終的には、チームの構造と、データベーススキーマを変更するDBA以外のエンジニアに対するチーム（またはシニア）の快適さ、およびスキーマの変更がコード構造にどの程度影響するかによります。CodeFirstが既存のデータベースにマップされている場合、そのプロパティ名のグローバルな名前変更を行うことなく、新しい列名にプロパティを再マップすることは簡単です。 C＃プロパティではなくデータベースフィールドの場合。また、C＃エンティティを完全にリモデリングすることなく、新しいデータベースフィールドのコードサポートを追加することは簡単です（既存のデータベースからLinq-to-sqlをEF CodeFirstに残した理由の1つ）。

Code Firstは、大規模なアプリケーションには適していません。大規模なアプリ開発のターンアラウンドは非常に巨大です。

通常、ビジネスアプリのライフサイクルは次のようになります。

1. バージョン1は生産中です
2. バージョン2はベータ版です
3. バージョン3は開発中です
4. バージョン4は計画中です。

また、他のクロスアプリケーション通信ブリッジ、スケジュールされたタスク、サードパーティの統合、モバイルなどのさまざまな通信デバイス用のWebサービスがあります。

最終的にCode FirstはEntity ModelのObjectContextを使用します。古いEFはEDMXを生成し、EntityContextでObjectContextを使用すれば、すべてに十分です。テキストテンプレートを簡単にカスタマイズして、コードを生成できます。ObjectContextの実装では、変更の検出方法は遅くなりますが、EFチームは、プロキシを生成する代わりに、最初にコードを再発明する代わりに、変更の検出速度を簡単に改善できました。

自動移行

自動移行は理論的には良いように思えますが、実際に運用を開始すると実際には不可能です。プロトタイピングに適しているだけで、簡単なデモを作成できます。

Code First Migrationは、このようなシステムにはまったく適していません。バージョン1とバージョン2は、おそらく同じデータベースと通信します。バージョン3とバージョン4は通常ステージングであり、異なるデータベースがあります。

最初のデータベース

Database Firstは実用的なアプローチであり、SQLスクリプトの比較、視覚化、保守が簡単です。DBAは簡単に作業できます。

テキストテンプレート

独自のテキストテンプレートを作成して、パフォーマンスの問題に対処するカスタム実装をほとんど行わずに、EDMXとObjectContextをクエリおよび作成しました。問題なく同じデータベースと通信する複数のバージョンを持つ複数のアプリケーションがあります。

私にとって、.ttファイルを右クリックして[カスタムツールの実行]をクリックするのは、はるかに速くて簡単なステップであり、クラスの作成、モデルの構成および作成を行います。

通常、大規模なプロジェクトの場合、データベースはすでに作成されています。レガシーデータベースであるか、パフォーマンスのために有能なdbaによって作成されているためです。CodeFirstの唯一の利点は、EFのエンティティではなく、POCOを使用する場合です。

「コードファースト」はEFをより「アジャイル」（その用語であまりハープしないで、方法論を意味するわけではありません）とグリーンフィールドアプリを使用するためのものです既存のデータモデルまたは既存のデータ。Django、PHPフレームワーク、またはRailsを使用して、従来のデータモデルを中心にアプリケーションを構築する代わりに、通常コードの一部としてデータモデルを作成するフレームワークのガイドラインに従うことができるアプリの種類物事を処理するマイクロソフトの方法。

したがって、質問に答えるには、ノーと言うでしょう。既存のデータが既にあり、それを処理するアプリケーションを作成している場合、Code Firstはあまり意味がありません。ただし、Code First EFはもちろん、EFをまったく使用していません。常に有益なコードへの疎結合アプローチのようです。Code Firstを使用し、クラスを既存のデータモデルに（モデルの生成を強制するのではなく）指すことができると仮定すると、Code Firstアプローチは、通常の「残酷な」使用なしに適切に抽象化されたテスト可能なコードを書くのに役立ちますEntity Framework（つまり、生成されたメタクラス）。

本当に大規模なプロジェクトでは、コードファーストは意味がありません。

実際、プロジェクトが非常に大きくなると、懸念事項が厳密に分離されることがよくあります。同じ人がC＃コードを書いたり、データベースデザインを行ったり、HTML / CSSを書いたり、Photoshopで視覚的なデザインをしたりすることはできません。代わりに、データベースの設計はデータベース管理者（または少なくとも自分の仕事を知っている熱心な人）によって行われます。

データベースは、データベース、SQL、管理、およびデータベース設計ツールに精通した人によって設計されているため、Entity Frameworkを使用している人を見るのは奇妙です。

さらに、Entity Frameworkがデータベースを適切に設計するのに十分強力かどうかはわかりません。インデックスはどうですか？制約？ビュー？

大規模なシステムでも最初のコードは実行可能です。作成後にモデルを調べて、好みのdbモデルに到達するまで、流れるようなAPIを使用して再マップするだけです。