コード優先vsモデル/データベース優先
EDMXダイアグラムでEntity Framework 4.1のコード優先のモデル/データベース優先の使用の長所と短所は何ですか？
EF 4.1を使用してデータアクセス層を構築するためのすべてのアプローチを完全に理解しようとしています。リポジトリパターンとIoCを使っています。
私はコードファーストアプローチを使うことができることを知っています：私のエンティティとコンテキストを手で定義し、そしてModelBuilderを使ってスキーマを微調整します。
EDMXダイアグラムを作成し、T4テンプレートを使用して同じPOCOクラスを生成するコード生成手順を選択することもできます。
どちらの場合も、私はPOCOにとらわれないORMオブジェクトとDbContextから派生したコンテキストになります。
Database-firstは、Enterprise Managerでデータベースを設計し、モデルをすばやく同期して、デザイナを使用して微調整できるので、最も魅力的なようです。
それでは、これら2つのアプローチの違いは何ですか？それは、Enterprise Managerに対するVS2010の優先度だけなのでしょうか。
私は違いがあると思います：
最初のコード
- ハードコアなプログラマーはどんな種類のデザイナーも好きではなく、EDMX xmlでマッピングを定義するのは複雑すぎるので、非常に人気があります。
- コードを完全に制御できます（変更が難しい自動生成コードはありません）。
- 一般的な期待はあなたがDBに悩まないことです。 DBは論理のない単なる記憶域です。 EFは創造を扱うでしょう、そして、あなたはそれが仕事をする方法を知りたくありません。
- あなたのコードがデータベースを定義しているので、データベースへの手動の変更はたぶん失われます。
最初のデータベース
- DBAが設計したDBを別に開発した場合、または既存のDBがある場合は非常に人気があります。
- あなたはEFにあなた自身のためのエンティティを作成させるでしょう、そしてマッピングの修正の後にあなたはPOCOエンティティを生成するでしょう。
- POCOエンティティに追加の機能が必要な場合は、T4テンプレートを修正するか、部分クラスを使用する必要があります。
- データベースによってドメインモデルが定義されているため、データベースを手動で変更することが可能です。あなたはいつでもデータベースからモデルを更新することができます（この機能はとてもうまくいきます）。
- 私はよくVS Databaseプロジェクトを一緒に使用します（PremiumとUltimateのバージョンのみ）。
最初のモデル
- あなたがデザイナーのファンであれば人気のある私見（=コードやSQLを書くのが好きではない）。
- モデルを「描き」、ワークフローでデータベーススクリプトを生成し、T4テンプレートでPOCOエンティティを生成します。あなたはあなたのエンティティとデータベースの両方に対するコントロールの一部を失うでしょうが、小さい簡単なプロジェクトのためにあなたは非常に生産的になるでしょう。
- POCOエンティティに追加の機能が必要な場合は、T4テンプレートを修正するか、部分クラスを使用する必要があります。
- モデルがデータベースを定義しているため、データベースへの手動変更はおそらく失われます。データベース生成パワーパックがインストールされている場合、これはよりよく機能します。それはあなたが（再作成するのではなく）データベーススキーマを更新するか、またはVSでデータベースプロジェクトを更新することを可能にします。
EF 4.1の場合、コードファーストとモデル/データベースファーストに関連する機能が他にもいくつかあると思います。最初にコードで使用されたFluent APIはEDMXのすべての機能を提供するわけではありません。 Model/Databaseを最初に使用してDbContext（まだ試したことはありません）を使用する場合は、ストアドプロシージャのマッピング、クエリビュー、ビューの定義などの機能が機能することを期待します。
"Programming Entity Framework"の作者であるJulie Lermanによる、この単純な "意思決定ツリー"は、より自信を持って意思決定を下すのに役立つはずだと思います。
より多くの情報 ここ 。
データベースが最初でモデルが最初に違いはありません。生成されたコードは同じであり、あなたはこのアプローチを組み合わせることができます。たとえば、sqlスクリプトを使用してデータベースを変更し、モデルを更新するよりも、designerを使用してデータベースを作成できます。
あなたが最初にコードを使うとき、あなたはレクリエーションデータベースとすべてのデータを失うことなしにモデルを変えることはできません。私見、この制限は非常に厳格であり、本番で最初にコードを使用することはできません。今のところそれは本当に使えません。
最初のコードの2番目のマイナーなデメリットは、モデルビルダーがmasterデータベースに対する権限を必要とすることです。 SQL Server Compactデータベースを使用している場合、またはデータベースサーバーを制御している場合は、これは影響しません。
最初のコードの利点は非常にクリーンでシンプルなコードです。あなたはこのコードを完全に制御することができ、それをあなたのビューモデルとして簡単に修正して使うことができます。
バージョン管理なしで単純なスタンドアロンアプリケーションを作成し、プロダクションで変更が必要なプロジェクトで最初にmodel\databaseを使用する場合は、コードファーストアプローチを使用することをお勧めします。
Entity Frameworkでコード優先設計を使用する3つの理由
1）巧妙で、膨れが少ない
既存のデータベースを使用して.edmxモデルファイルとそれに関連するコードモデルを生成すると、自動生成されたコードが大量に生成されます。あなたが何かを壊したり、あなたの変更が次の世代に上書きされたりしないようにこれらの生成されたファイルに触れることは絶対に恥ずかしいです。この混乱の中では、コンテキストと初期化子も一緒に詰まっています。計算された読み取り専用プロパティのように、生成されたモデルに機能を追加する必要がある場合は、モデルクラスを拡張する必要があります。これは結局ほとんどすべてのモデルのための必要条件であり、あなたはすべてのための拡張で終わることになります。
最初のコードであなたの手でコード化されたモデルはあなたのデータベースになります。構築している正確なファイルがデータベース設計を生成します。追加のファイルはなく、プロパティを追加するとき、またはデータベースが知る必要のない他のものを追加するときは、クラス拡張を作成する必要はありません。適切な構文に従っている限り、それらを同じクラスに追加するだけです。必要であれば、Model.edmxファイルを生成してコードを視覚化することもできます。
2）より優れた統制
DBを最初に使用するときは、アプリケーションで使用するためにモデル用に何が生成されるのかを判断します。命名規則が望ましくない場合があります。時には関係や連想があなたが望んでいるものとは全く異なるものです。遅延ロードとの一時的でない関係がAPIレスポンスに大きな損害を与えることもあります。
あなたが遭遇するかもしれないモデル生成問題のための解決策がほとんど常にある間、コードを最初に行くことはあなたが始めから完全でそしてきめの細かい制御を与える。ビジネスモデルの快適さから、コードモデルとデータベース設計の両方のあらゆる側面を制御できます。関係、制約、および関連付けを正確に指定できます。プロパティの文字数制限とデータベースの列サイズを同時に設定できます。どの関連コレクションを積極的にロードするか、またはシリアル化しないかを指定できます。要するに、あなたはより多くのものに対して責任がありますが、あなたはあなたのアプリデザインを完全にコントロールしています。
3）データベースのバージョン管理
これは大きなものです。データベースのバージョン管理は困難ですが、コードを最初に移行し、コードを最初に移行すると、はるかに効果的です。データベーススキーマはコードモデルに完全に基づいているため、ソースコードをバージョン管理することでデータベースのバージョン管理を支援します。コンテキストの初期化を管理する責任は、固定ビジネスデータのシードなどの作業に役立ちます。また、コードの最初の移行を作成する責任もあります。
初めて移行を有効にすると、構成クラスと初期移行が生成されます。最初の移行は、現在のスキーマまたはベースラインのv1.0です。その時点から、バージョンの順序付けを容易にするために、タイムスタンプ付きの記述子でラベル付けされたマイグレーションを追加します。パッケージマネージャからadd-migrationを呼び出すと、コードモデルで自動的に変更されたものすべてをUP（）関数とDOWN（）関数の両方で含む新しいマイグレーションファイルが生成されます。 UP機能はデータベースに変更を適用し、DOWN機能はロールバックしたい場合に同じ変更を削除します。さらに、これらの移行ファイルを編集して、新しいビュー、インデックス、ストアドプロシージャなどのその他の変更を追加できます。それらはあなたのデータベーススキーマの真のバージョニングシステムになるでしょう。
コード優先は新星のようです。私はRuby on Railsをちょっと見てみました、そしてそれらの標準はデータベース移行を伴うコード優先です。
あなたがMVC3アプリケーションを構築しているなら、私はCodeが最初に以下の利点を持っていると思います：
- 簡単な属性の装飾 - あなたはバリデーション、requireなどの属性でフィールドを装飾することができます、それはEFモデリングではかなり扱いにくいです
- 奇妙なモデリングエラーはありません - EFモデリングでは、関連プロパティの名前を変更しようとしたときに、基礎となるメタデータと一致させる必要があるなど、しばしば奇妙なエラーがあります。
- マージしにくい - Mercurialなどのコードバージョン管理ツールを使用する場合、.edmxファイルをマージするのは面倒です。あなたはC＃に慣れているプログラマーであり、そこで.edmxをマージしています。コードファーストではそうではありません。
- 最初にコードと対比してみれば、隠された複雑さや対処すべき未知の要素がなくても完全に制御できます。
- パッケージマネージャのコマンドラインツールを使用することをお勧めします。スキャフォールドビューに新しいコントローラを追加するためにグラフィカルツールを使用しないでください。
- DB-Migrations - その後、Enable-Migrationsを実行することもできます。これはとても強力です。モデルをコードで変更すると、フレームワークはスキーマの変更を追跡できるため、アップグレードをシームレスに展開できます。スキーマのバージョンは自動的にアップグレードされます（必要に応じてダウングレードされます）。 （よくわからないが、これはおそらくモデルファーストでもうまくいくだろう）
更新
この質問では、code-firstとEDMX model/db-firstとの比較も求められます。 Code-firstは、これらの両方のアプローチにも使用できます。
- Model-First ：最初にPOCOを（概念モデル）コーディングし、次に生成データベース（マイグレーション）をコーディングする。または
- Database-First ：既存のデータベースを考えて、手動は一致するPOCOをコーディングします。 （ここでの違いは、POCOが自動的に生成されないことです。その場合、既存のデータベースが得られます）。ただし、 POを作成して既存のデータベースのマッピングをEntity Framework または Entity Framework 5 - 既存のデータベースからPOCOクラスを生成する方法 を使用）を使用して自動的に近づくことができます。
私は最初にEFデータベースを使用して、データベース構成に対するより高い柔軟性と制御を提供します。
最初はEFコードとモデルが最初はかっこよく見え、データベースに依存しませんでしたが、これを行う際に、非常に基本的で一般的なデータベース構成情報について検討することを指定できません。たとえば、テーブルインデックス、セキュリティメタデータ、または複数の列を含む主キーがあります。私はこれらおよび他の一般的なデータベース機能を使いたいと思うので、とにかく直接データベース設定をしなければなりません。
私は最初にDBの間に生成されたデフォルトのPOCOクラスが非常にきれいであると思います、しかし非常に有用なデータアノテーション属性、またはストアドプロシージャへのマッピングが欠けています。私はこれらの制限のいくつかを克服するためにT4テンプレートを使用しました。 T4テンプレートは、特にあなた自身のメタデータや部分的なクラスと組み合わせたときに、素晴らしいです。
モデルは最初はたくさんの可能性を秘めているように見えますが、複雑なデータベーススキーマのリファクタリング中に私にたくさんのバグを与えています。理由がわからない。
大規模モデルでの作業は、SP1以前は非常に時間がかかりました（SP1以降は試したことがありませんが、今では簡単と言われています）。
私はまだ自分のテーブルを最初にデザインし、それから私的にPOCOを生成するために自社製のツールを使っています。
ソース管理システムを使用している場合は、POCOの履歴を簡単にたどることができますが、デザイナーが生成したコードではそれほど簡単ではありません。
私は自分のPOCOのための基盤を持っています。それは多くのことを非常に簡単にします。
私はすべてのテーブルのビューを持っています。それぞれの基本ビューは私の外部キーのための基本的な情報を持っています、そして私のビューPOCOは私のPOCOクラスから派生しています。
そして最後に私はデザイナーが好きではありません。
データベースファーストアプローチの例：
コードを書かずに： ASP.NET MVC/MVC3データベースファーストアプローチ/データベースファースト
そして、私はそれがデータ損失がこのアプローチで少ないので、他のアプローチより良いと思います。
私はすべてのモデルが素晴らしい場所を持っていると思いますが、モデルファーストアプローチで私が抱えている問題はデータベースファーストアプローチを使用せずにアプリケーションを構築する柔軟性を得ないDBAのデータベースを制御する多くの大企業にあります。私は多くのプロジェクトに取り組んできましたが、それが展開になると彼らは完全な制御を望んでいました。
そのため、コード優先、モデル優先、データベース優先のすべてのバリエーションに同意する限り、実際の運用環境を考慮する必要があります。あなたのシステムが多くのユーザーとDBAがショーを運営している大きなユーザーベースのアプリケーションになるのであれば、あなたはデータベースの最初のオプションが私の意見に過ぎないと考えるかもしれません。