entity-framework - コードファーストvsモデル/データベースファースト

Question

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

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

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

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

どちらの場合も、私は不可知論者であり、から派生したコンテキストであるPOCOオブジェクトになります。ORMDbContext

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

では、これら2つのアプローチの違いは何ですか？VS2010とEnterpriseManagerの好みだけですか？

score 735 · Accepted Answer

違いは次のとおりです。

最初にコードを書く

筋金入りのプログラマーはどんな種類のデザイナーも好きではなく、EDMX xmlでのマッピングの定義は複雑すぎるため、非常に人気があります。
コードを完全に制御します（変更が難しい自動生成されたコードはありません）。
一般的な期待は、DBを気にしないことです。DBは、ロジックのない単なるストレージです。EFが作成を処理するので、EFがどのように機能するかを知りたくありません。
コードがデータベースを定義しているため、データベースへの手動変更はおそらく失われます。

データベースファースト

DBAによって設計されたDB、個別に開発されたDBがある場合、または既存のDBがある場合に、非常に人気があります。
EFにエンティティを作成させ、マッピングを変更した後、POCOエンティティを生成します。
POCOエンティティに追加機能が必要な場合は、T4でテンプレートを変更するか、部分的なクラスを使用する必要があります。
データベースがドメインモデルを定義しているため、データベースを手動で変更できます。データベースからいつでもモデルを更新できます（この機能は非常にうまく機能します）。
私はこれをVSデータベースプロジェクトと一緒に使用することがよくあります（PremiumバージョンとUltimateバージョンのみ）。

モデルファースト

あなたがデザイナーファンなら私見人気があります（=あなたはコードやSQLを書くのが好きではありません）。
モデルを「描画」し、ワークフローでデータベーススクリプトを生成し、T4テンプレートでPOCOエンティティを生成します。エンティティとデータベースの両方の制御の一部が失われますが、小さな簡単なプロジェクトの場合は非常に生産的です。
POCOエンティティに追加機能が必要な場合は、T4でテンプレートを変更するか、部分的なクラスを使用する必要があります。
モデルがデータベースを定義しているため、データベースへの手動変更はおそらく失われます。これは、データベース生成パワーパックがインストールされている場合にうまく機能します。これにより、（再作成する代わりに）データベーススキーマを更新したり、VSでデータベースプロジェクトを更新したりできます。

EF 4.1の場合、コードファーストとモデル/データベースファーストに関連する他のいくつかの機能があると思います。コードで最初に使用されるFluentAPIは、EDMXのすべての機能を提供するわけではありません。ストアドプロシージャのマッピング、クエリビュー、ビューの定義などの機能は、モデル/データベースを最初に使用するときに機能することを期待していますがDbContext（まだ試していません）、コードでは最初に機能しません。

score 139 · Accepted Answer

「ProgrammingEntityFramework」の著者であるJulieLermanによるこの単純な「意思決定ツリー」は、より自信を持って意思決定を行うのに役立つはずです。

EFでさまざまなアプローチを選択するのに役立つ決定木

詳細はこちら。

score 52 · Accepted Answer

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

最初にコードを使用する場合、レクリエーションデータベースとすべてのデータを失うことなくモデルを変更することはできません。私見ですが、この制限は非常に厳しく、本番環境で最初にコードを使用することはできません。今のところ、それは本当に使用可能ではありません。

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

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

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

score 38 · Accepted Answer

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

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

1）がらくたが少なく、膨満感が少ない

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

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

2）より優れた制御

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

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

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

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

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

score 31 · Accepted Answer

コードファーストは新星のようです。私はRubyonRailsをざっと見てみましたが、その標準はコードファーストであり、データベースの移行があります。

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

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

アップデート

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

モデルファースト：最初にPOCOをコーディングし（概念モデル）、次にデータベースを生成します（移行）。また
データベースファースト：既存のデータベースを前提として、一致するようにPOCOを手動でコーディングします。（ここでの違いは、POCOが自動的に生成されないため、既存のデータベースが提供されることです）。ただし、 Generate POCOクラスを使用して自動に近づけることができ、 EntityFrameworkまたはEntityFramework5-既存のデータベースからPOCOクラスを生成する方法を使用して既存のデータベースのマッピングを行うことができます。

score 14 · Accepted Answer

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

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

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

モデルには最初は多くの可能性があるように見えますが、複雑なデータベーススキーマのリファクタリング中に多くのバグが発生します。理由はわかりません。

score 7 · Accepted Answer

大型モデルでの作業は、SP1の前は非常に遅かった（SP1の後で試したことはないが、今は簡単だと言われている）。

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

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

私は自分のPOCOの基盤を持っているので、多くのことが非常に簡単になります。

すべてのテーブルのビューがあり、各ベースビューは外部キーの基本情報を提供し、ビューPOCOはPOCOクラスから派生します。これも非常に便利です。

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

score 7 · Accepted Answer

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

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

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

score 5 · Accepted Answer

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

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

score 3 · Accepted Answer

最初にコードの利点の1つは、Gitなどのバージョン管理システムに加えたすべての変更をバックアップできることだと思います。すべてのテーブルとリレーションシップは基本的に単なるクラスに格納されているため、過去にさかのぼってデータベースの構造を確認できます。

entity-framework - コードファーストvsモデル/データベースファースト

10 に答える 10

Related

Reference