コードファーストとモデル/データベースファースト [終了]
https://stackoverflow.com/questions/5446316
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
EDMX 図でモデル/データベース ファーストではなく Entity Framework 4.1 コード ファーストを使用することの長所と短所は何ですか?
私は、EF 4.1 を使用してデータ アクセス レイヤーを構築するためのすべてのアプローチを完全に理解しようとしています。私はリポジトリパターンを使用していますが、 IoC.
コードファーストアプローチを使用できることはわかっています。エンティティとコンテキストを手動で定義して使用します ModelBuilder スキーマを微調整します。
を作成することもできます EDMX 図を作成し、T4 テンプレートを使用して同じコードを生成するコード生成ステップを選択します。 POCO クラス。
どちらの場合も、最終的には次のようになります POCO オブジェクト ORM 不可知論的であり、そこから派生するコンテキスト DbContext.
Enterprise Manager でデータベースを設計し、モデルを迅速に同期し、デザイナーを使用して微調整できるため、データベースファーストが最も魅力的に思えます。
では、これら 2 つのアプローチの違いは何でしょうか?それは単に VS2010 と Enterprise Manager の好みの問題でしょうか?
解決
違いは次のとおりだと思います。
最初にコードを書く
- 筋金入りのプログラマーはどんなデザイナーも好まないことと、EDMX XML でのマッピングの定義が複雑すぎるため、非常に人気があります。
- コードを完全に制御します (変更が難しい自動生成コードはありません)。
- 一般的には、DB を気にする必要はないと考えられます。DB はロジックを持たない単なるストレージです。EF は作成を処理しますが、EF がどのように仕事をするのか知りたくありません。
- コードでデータベースが定義されているため、データベースへの手動による変更はおそらく失われます。
データベースが先
- DBA によって設計された DB がある場合、別個に開発された DB がある場合、または既存の DB がある場合に非常に人気があります。
- EF にエンティティを作成させ、マッピングの変更後に POCO エンティティを生成します。
- POCO エンティティに追加機能が必要な場合は、T4 でテンプレートを変更するか、部分クラスを使用する必要があります。
- データベースはドメイン モデルを定義するため、データベースを手動で変更することができます。いつでもデータベースからモデルを更新できます (この機能は非常にうまく機能します)。
- 私はよくこれを VS Database プロジェクトと一緒に使用します (プレミアム バージョンとアルティメット バージョンのみ)。
最初にモデルを作成する
- 私の意見では、デザイナーのファン (= コードや SQL を書くのが好きではない人) に人気があります。
- モデルを「描画」し、ワークフローでデータベース スクリプトを生成し、T4 テンプレートで POCO エンティティを生成します。エンティティとデータベースの両方に対する制御の一部が失われますが、小規模で簡単なプロジェクトの場合は非常に生産性が高くなります。
- POCO エンティティに追加機能が必要な場合は、T4 でテンプレートを変更するか、部分クラスを使用する必要があります。
- モデルがデータベースを定義しているため、データベースへの手動による変更はおそらく失われます。データベース生成パワーパックがインストールされている場合、これはより効果的に機能します。これにより、VS でデータベース スキーマを (再作成する代わりに) 更新したり、データベース プロジェクトを更新したりできるようになります。
EF 4.1 の場合、Code First と EF 4.1 に関連する機能が他にもいくつかあると思います。最初にモデル/データベース。Code first で使用される Fluent API は、EDMX のすべての機能を提供するわけではありません。ストアド プロシージャ マッピング、クエリ ビュー、ビューの定義などの機能を期待しています。最初にモデル/データベースを使用する場合に機能し、 DbContext (まだ試していませんが)、最初はコードにはありません。
他のヒント
「Programming Entity Framework」の著者 Julie Lerman による次のシンプルな「意思決定ツリー」は、より自信を持って意思決定を行うのに役立つはずだと思います。
より詳しい情報 ここ.
データベースファーストとモデルファーストには実際の違いはありません。生成されるコードは同じなので、このアプローチを組み合わせることができます。たとえば、SQL スクリプトを使用してデータベースを変更し、モデルを更新するよりも、デザイナーを使用してデータベースを作成できます。
最初にコードを使用すると、再作成データベースがなければモデルを変更できず、すべてのデータが失われます。私の意見では、この制限は非常に厳格であり、運用環境で最初にコードを使用することはできません。今のところ、本格的には使えません。
コード ファーストの 2 番目の小さな欠点は、モデル ビルダーがマスター データベースに対する権限を必要とすることです。SQL Server Compact データベースを使用している場合、またはデータベース サーバーを制御している場合、これは影響しません。
コード ファーストの利点は、コードが非常にクリーンでシンプルであることです。このコードは完全に制御でき、簡単に変更してビュー モデルとして使用できます。
バージョン管理を行わずに単純なスタンドアロン アプリケーションを作成し、運用環境で変更が必要なプロジェクトで最初にモデル\データベースを使用する場合は、コード ファースト アプローチを使用することをお勧めします。
から該当部分を引用すると、 http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework
Entity Framework でコード ファースト設計を使用する 3 つの理由
1) 粗末で膨らみが少ない
既存のデータベースを使用して.edmxモデルファイルと関連するコードモデルを生成すると、自動生成コードの巨大なパイルが得られます。あなたが何かを壊さないように、これらの生成されたファイルに触れないように懇願されたり、あなたの変更が次世代に上書きされます。コンテキストと初期イザーもこの混乱で一緒に詰まっています。計算された読み取り専用プロパティなど、生成されたモデルに機能を追加する必要がある場合、モデルクラスを拡張する必要があります。これは、ほぼすべてのモデルの要件になり、すべての拡張機能になります。
コードファーストを使用すると、手動でコード化されたモデルがデータベースになります。構築する正確なファイルは、データベース設計を生成するものです。追加のファイルはなく、プロパティやデータベースが知る必要がない他のものを追加する場合、クラス拡張機能を作成する必要はありません。適切な構文に従う限り、それらを同じクラスに追加することができます。ちなみに、必要に応じてコードを視覚化するモデル.edmxファイルを生成することもできます。
2) より優れた制御
最初にDBに行くとき、あなたはあなたのアプリケーションで使用するためにあなたのモデルのために生成されるものに翻弄されています。時折、命名規則が望ましくありません。関係や協会はあなたが望むものではないことがあります。他の場合、怠zyなロードとの非一時的な関係は、API応答に大混乱をもたらします。
ほとんどの場合、モデル生成の問題の解決策がありますが、最初にコードを行うと、最初に完全で細かいコントロールが得られます。ビジネスオブジェクトの快適さから、コードモデルとデータベース設計の両方のあらゆる側面を制御できます。関係、制約、および関連性を正確に指定できます。同時に、プロパティ文字制限とデータベース列サイズを設定できます。どの関連コレクションを熱心にロードするか、まったくシリアル化しないかを指定できます。要するに、あなたはより多くのものを担当しますが、あなたはあなたのアプリのデザインを完全に制御しています。
3)データベースのバージョン管理
これは大きなことです。バージョンのデータベースは難しいですが、最初にコードとコードの最初の移行を使用すると、はるかに効果的です。データベーススキーマはコードモデルに完全に基づいているため、ソースコードを制御するバージョンによって、データベースのバージョンを制御します。シード固定ビジネスデータのようなことを行うのに役立つコンテキストの初期化を制御する責任があります。また、コードの最初の移行を作成する責任があります。
最初に移行を有効にすると、構成クラスと初期移行が生成されます。最初の移行は、現在のスキーマまたはベースラインv1.0です。その時点から、バージョンの注文を支援するために、タイムスタンプが付けられ、記述子でラベル付けされた移行を追加します。パッケージマネージャーからADD移行を呼び出すと、UP（）とdown（）関数の両方でコードモデルで変更されたすべてのものを含む新しい移行ファイルが生成されます。UP関数はデータベースに変更を適用し、ダウン関数はロールバックするイベントでそれらの同じ変更を削除します。さらに、これらの移行ファイルを編集して、新しいビュー、インデックス、ストアドプロシージャなどの変更を追加することができます。これらは、データベーススキーマの真のバージョンシステムになります。
コードファーストが新星のように見えます。Ruby on Rails をざっと見たところ、標準はコードファーストでデータベース移行が行われていました。
MVC3 アプリケーションを構築している場合、Code first には次の利点があると思います。
- 簡単な属性装飾 - フィールドを検証、必須などで装飾できます。属性、EF モデリングでは非常に扱いにくい
- 奇妙なモデリングエラーがない - EF モデリングには、関連付けプロパティの名前を変更しようとすると、基礎となるメタデータと一致する必要があるなど、奇妙なエラーがよく発生します。非常に柔軟性がありません。
- 合併してもおかしくない - mercurial などのコード バージョン管理ツールを使用する場合、.edmx ファイルをマージするのは面倒です。あなたは C# に慣れているプログラマーで、.edmx をマージしています。コードファーストの場合はそうではありません。
- まずコードに戻って比較すると、隠れた複雑さや未知の事柄に対処する必要がなく、完全に制御できるようになります。
- パッケージ マネージャー コマンド ライン ツールを使用することをお勧めします。スキャフォールディング ビューに新しいコントローラーを追加する場合もグラフィカル ツールは使用しないでください。
- DB移行 - 次に、移行を有効にすることもできます。これはとても強力です。コードでモデルに変更を加えると、フレームワークがスキーマの変更を追跡できるため、スキーマ バージョンが自動的にアップグレード (および必要に応じてダウングレード) してアップグレードをシームレスに展開できます。(よくわかりませんが、これはおそらくモデルファーストでも機能します)
アップデート
この質問では、code-first と EDMX モデル/db-first の比較も求められています。コードファーストは、次の両方のアプローチにも使用できます。
- モデルファースト:最初に POCO (概念モデル) をコーディングしてから、 生成する データベース (移行);または
- データベースファースト:既存のデータベースがあるとすると、 手動で 一致するように POCO をコーディングします。(ここでの違いは、POCO が既存のデータベースから自動的に生成されないことです)。ただし、使用すると自動に近づくことができます Entity Framework を使用して POCO クラスと既存のデータベースのマッピングを生成する または Entity Framework 5 - 既存のデータベースから POCO クラスを生成する方法.
データベース構成をより柔軟に制御できるようにするために、私は最初に EF データベースを使用します。
EF コード ファーストとモデル ファーストは、最初はクールに見え、データベースの独立性を提供しますが、これを行うと、非常に基本的で一般的なデータベース構成情報と私が考えるものを指定することはできません。たとえば、テーブル インデックス、セキュリティ メタデータ、または複数の列を含む主キーがあります。これらおよびその他の一般的なデータベース機能を使用したいと考えているため、とにかくデータベース構成を直接行う必要があります。
DB ファースト中に生成されたデフォルトの POCO クラスは非常にクリーンですが、非常に便利なデータ注釈属性やストアド プロシージャへのマッピングが欠けていることがわかりました。これらの制限の一部を克服するために、T4 テンプレートを使用しました。T4 テンプレートは、特に独自のメタデータや部分クラスと組み合わせた場合に優れています。
モデルには最初は多くの可能性があるように見えますが、複雑なデータベース スキーマのリファクタリング中に多くのバグが発生します。理由はわかりません。
SP1 より前は、大規模なモデルの操作が非常に遅かったです (SP1 以降は試していませんが、今は速くなったと言われています)。
私は今でも最初にテーブルを設計し、次に社内構築ツールが POCO を生成するため、poco オブジェクトごとに反復的なタスクを実行する負担がかかります。
ソース管理システムを使用している場合、POCO の履歴を簡単に追跡できますが、デザイナーが生成したコードの場合はそれほど簡単ではありません。
私は POCO のベースを持っているので、多くのことが非常に簡単になります。
すべてのテーブルのビューがあり、各ベース ビューは外部キーの基本情報をもたらし、ビュー POCO は POCO クラスから派生しており、これもまた非常に便利です。
そして最後に、私はデザイナーが好きではありません。
データベースファーストアプローチの例:
コードを何も書かずに:ASP.NET MVC / MVC3 データベースファーストアプローチ / データベースファースト
また、このアプローチではデータ損失が少ないため、他のアプローチよりも優れていると思います。
私の意見では、すべてのモデルが優れた点を持っていると思いますが、モデルファーストアプローチに関して私が抱えている問題は、DBA がデータベースを管理している多くの大企業では、データベースファーストアプローチを使用せずにアプリケーションを構築する柔軟性が得られないことです。私は多くのプロジェクトに取り組んできましたが、展開に関しては完全なコントロールが必要でした。
したがって、コードファースト、モデルファースト、データベースファーストという考えられるすべてのバリエーションには同意しますが、実際の運用環境を考慮する必要があります。したがって、システムが多数のユーザーと DBA が実行する大規模なユーザー ベース アプリケーションになる場合は、データベースを最初に選択するという選択肢を検討することをお勧めします。これは単なる私の意見です。
コードファーストの利点の 1 つは、Git などのバージョン管理システムに加えたすべての変更をバックアップできることだと思います。すべてのテーブルとリレーションシップは本質的に単なるクラスに格納されるため、時間を遡ってデータベースの以前の構造を確認することができます。
