コード優先vsモデル/データベース優先[終了]

Entity Framework 4.1をモデル/データベース優先でEDMXダイアグラムよりコードファーストで使用する場合の長所と短所は何ですか？

EF 4.1を使用してデータアクセスレイヤーを構築するためのすべてのアプローチを完全に理解しようとしています。リポジトリパターンとを使用していますIoC。

コードファーストアプローチを使用できることを知っModelBuilderています。エンティティとコンテキストを手動で定義し、スキーマを微調整するために使用します。

EDMX図を作成し、T4テンプレートを使用して同じPOCOクラスを生成するコード生成ステップを選択することもできます。

どちらの場合も、私POCOはORM不可知論的であり、から派生するコンテキストを持つオブジェクトになりますDbContext。

Enterprise Managerでデータベースを設計し、モデルをすばやく同期し、デザイナーを使用して微調整できるので、データベースファーストが最も魅力的なようです。

では、これら2つのアプローチの違いは何ですか？それは単にVS2010対Enterprise Managerの好みについてですか？

違いは次のとおりだと思います。

最初にコード

• 筋金入りのプログラマーはどんなデザイナーも好きではなく、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のすべての機能を提供するわけではありません。ストアドプロシージャのマッピング、クエリビュー、ビューの定義などの機能は、モデル/データベースを最初に使用したときに機能し、DbContext（まだ試していませんが）コードでは最初は機能しないと思います。

「Programming Entity Framework」の作者であるJulie Lermanによるこの単純な「決定木」は、より自信を持って決定を下すのに役立つと思います。

詳細はこちら。

最初のデータベースと最初のモデルには実際の違いはありません。生成されたコードは同じであり、このアプローチを組み合わせることができます。たとえば、SQLスクリプトを使用してデータベースを変更し、モデルを更新するよりも、デザイナーを使用してデータベースを作成できます。

最初にコードを使用する場合、データベースを再作成してすべてのデータを失うことなくモデルを変更することはできません。私見、この制限は非常に厳しく、最初に本番環境でコードを使用することはできません。今のところ、それは本当に使えません。

最初のコードの2番目のマイナーな欠点は、モデルビルダーがマスターデータベースに対する権限を必要とすることです。これは、SQL Server Compactデータベースを使用している場合、またはデータベースサーバーを制御している場合には影響しません。

最初のコードの利点は、非常にクリーンでシンプルなコードです。このコードを完全に制御でき、簡単に変更してビューモデルとして使用できます。

バージョン管理なしでシンプルなスタンドアロンアプリケーションを作成し、本番環境での変更が必要なプロジェクトで最初にmodel \ databaseを使用する場合は、コードファーストアプローチを使用することをお勧めします。

http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-frameworkから関連部品を引用

Entity Frameworkでコードファーストデザインを使用する3つの理由

1）破片が少なく、膨らみが少ない

既存のデータベースを使用して.edmxモデルファイルと関連するコードモデルを生成すると、自動生成されたコードの膨大な山ができます。何かを壊したり、変更が次世代で上書きされたりしないように、これらの生成されたファイルには絶対に触れないようにしてください。コンテキストとイニシャライザは、この混乱でも一緒に詰まっています。計算された読み取り専用プロパティのように、生成されたモデルに機能を追加する必要がある場合は、モデルクラスを拡張する必要があります。これは、ほとんどすべてのモデルの要件となり、すべての拡張機能を使用することになります。

最初にコードを使用すると、手動でコード化したモデルがデータベースになります。構築している正確なファイルは、データベース設計を生成するものです。追加のファイルはなく、プロパティなど、データベースが認識する必要のないものを追加するときに、クラス拡張を作成する必要はありません。適切な構文に従う限り、それらを同じクラスに追加できます。必要に応じて、Model.edmxファイルを生成してコードを視覚化することもできます。

2）より優れた制御

最初にDBに移行するとき、アプリケーションで使用するためにモデルに対して生成されるものに翻弄されます。時々、命名規則が望ましくない場合があります。時々、関係や関連性があなたの望むものではない場合があります。また、API応答に遅延読み込みを伴う一時的でない関係が発生することもあります。

ほとんどの場合、発生する可能性のあるモデル生成の問題の解決策はありますが、最初にコードを実行すると、最初から完全で細かい制御ができます。ビジネスオブジェクトの快適さから、コードモデルとデータベース設計の両方のあらゆる側面を制御できます。関係、制約、および関連付けを正確に指定できます。プロパティの文字制限とデータベースの列サイズを同時に設定できます。どの関連コレクションを積極的にロードするか、まったくシリアル化しないかを指定できます。要するに、あなたはより多くのものに責任がありますが、あなたはあなたのアプリデザインを完全に制御しています。

3）データベースのバージョン管理

これは大きな問題です。データベースのバージョン管理は難しいですが、コードファーストとコードファーストの移行により、はるかに効果的です。データベーススキーマは完全にコードモデルに基づいているため、ソースコードをバージョン管理することで、データベースのバージョン管理に役立ちます。固定ビジネスデータのシードなどを行うのに役立つコンテキストの初期化を制御する必要があります。また、コードファーストマイグレーションの作成も担当します。

初めて移行を有効にすると、構成クラスと初期移行が生成されます。最初の移行は、現在のスキーマまたはベースラインv1.0です。その時点から、バージョンの順序付けに役立つように、タイムスタンプが付けられ、記述子でラベル付けされたマイグレーションを追加します。パッケージマネージャーからadd-migrationを呼び出すと、UP（）関数とDOWN（）関数の両方でコードモデルで自動的に変更されたすべてを含む新しい移行ファイルが生成されます。UP関数はデータベースに変更を適用し、DOWN関数はロールバックするイベントで同じ変更を削除します。さらに、これらの移行ファイルを編集して、新しいビュー、インデックス、ストアドプロシージャなど、その他の変更を追加できます。これらは、データベーススキーマの真のバージョン管理システムになります。

コードファーストは新星のようです。Ruby on Railsをざっと見てみたところ、Ruby on Railsの標準はデータベースを移行するコードファーストです。

MVC3アプリケーションを構築している場合、コードには最初に次の利点があると思います。

• 簡単な属性の装飾 -フィールドを検証、要求などの属性で装飾できます。EFモデリングでは扱いにくいです
• 奇妙なモデリングエラーなしは奇妙なエラーがよくあります。たとえば、関連付けプロパティの名前を変更しようとすると、基になるメタデータと一致する必要があるため、非常に柔軟性が。
• マージする厄介ではない -など水銀などのコードのバージョン管理ツールを使用する場合は、.edmxファイルをマージすることは苦痛です。あなたはC＃に慣れているプログラマーであり、そこで.edmxをマージしています。コードファーストではそうではありません。
• 最初にコードと比較すると、複雑な問題や不明な点をすべて処理することなく、完全に制御できます。
• パッケージマネージャーのコマンドラインツールを使用することをお勧めします。グラフィカルツールを使用して、新しいコントローラーを足場ビューに追加しないでください。
• DB移行 -次に、移行を有効にすることもできます。これはとても強力です。コードでモデルに変更を加えると、フレームワークでスキーマの変更を追跡できるため、スキーマバージョンが自動的にアップグレード（および必要に応じてダウングレード）されたアップグレードをシームレスにデプロイできます。（わかりませんが、これはおそらくモデルファーストでも機能します）

更新

この質問では、code-firstとEDMXモデル/ db-firstの比較も求められます。コードファーストは、これらの両方のアプローチにも使用できます。

• Model-First：最初にPOCOをコーディングし（概念モデル）、次にデータベースを生成します（マイグレーション）。または
• Database-First：既存のデータベースを前提として、照合するPOCOを手動でコーディングします。（ここでの違いは、POCOが自動的に生成されないことであり、既存のデータベースを提供します）。ただし、Entity FrameworkまたはEntity Framework 5-既存のデータベースからPOCOクラスを生成する方法を使用して、Generate POCOクラスと既存のデータベースのマッピングを使用すると、自動に近づくことができます。

データベース構成をより柔軟に制御するために、最初にEFデータベースを使用します。

最初にEFコードとモデルが最初はクールに見え、データベースの独立性を提供しますが、これを行うと、非常に基本的で一般的なデータベース構成情報と見なすものを指定できません。たとえば、テーブルインデックス、セキュリティメタデータ、または複数の列を含む主キーがあります。これらの一般的なデータベース機能を使用したいので、データベース構成を直接行う必要があります。

最初にDB中に生成されたデフォルトのPOCOクラスは非常にクリーンですが、非常に有用なデータアノテーション属性、またはストアドプロシージャへのマッピングが不足しています。これらの制限のいくつかを克服するためにT4テンプレートを使用しました。T4テンプレートは、特に独自のメタデータや部分クラスと組み合わせると素晴らしいです。

最初にモデルには多くの可能性があるようですが、複雑なデータベーススキーマのリファクタリング中に多くのバグを私に与えています。なぜだかわかりません。

大きなモデルでの作業は、SP1以前は非常に遅くなりました（SP1以降は試していませんが、今は簡単だと言われています）。

私はまだ最初に自分のテーブルを設計し、次に社内で構築されたツールがPOCOを生成するので、各pocoオブジェクトに対して反復的なタスクを実行する負担がかかります。

ソース管理システムを使用している場合、POCOの履歴を簡単にたどることができます。デザイナーが生成したコードではそれほど簡単ではありません。

POCOのベースがあるので、多くのことが非常に簡単になります。

私はすべてのテーブルのビューを持っています。各ベースビューは外部キーの基本情報を持ち、ビューのPOCOはPOCOクラスから派生します。これは非常に便利です。

そして最後に私はデザイナーが好きではありません。

データベースの最初のアプローチの例：

コードを記述せずに： ASP.NET MVC / MVC3データベースファーストアプローチ/データベースファースト

また、このアプローチではデータ損失が少ないため、他のアプローチよりも優れていると思います。

私見すべてのモデルは素晴らしい場所だと思いますが、モデルファーストアプローチで私が抱えている問題は、DBAがデータベースを制御している多くの大企業で、データベースファーストアプローチを使用せずにアプリケーションを構築する柔軟性を得られないことです。私は多くのプロジェクトに取り組んできましたが、デプロイメントに関しては、完全なコントロールが必要でした。

したがって、可能なすべてのバリエーションに最初に同意する限り、コードファースト、モデルファースト、データベースファースト、実際の本番環境を考慮する必要があります。したがって、システムが大規模なユーザーベースのアプリケーションで、多くのユーザーがいて、DBAがショーを実行している場合は、データベースの最初のオプションを私の意見だと考えるかもしれません。

最初にコードの利点の1つは、Gitのようなバージョン管理システムに加えたすべての変更をバックアップできることです。すべてのテーブルとリレーションシップは、本質的には単なるクラスであるものに格納されているため、時間を遡って、データベースの構造を以前の状態に戻すことができます。