EntityFrameworkを使用していくつかの引数は何ですか？[閉まっている]

現在作成しているアプリケーションは、ストアドプロシージャと手作りのクラスモデルを使用してデータベースオブジェクトを表現しています。一部の人々はEntity Frameworkの使用を提案しており、私はプロジェクトにそれほど遠くないので、それに切り替えることを検討しています。私の問題は、EFを主張する人々が悪い面ではなく、良い面だけを教えてくれると感じていることです:)

私の主な懸念は次のとおりです。

• DataAnnotationsを使用してクライアント側の検証が必要であり、とにかくクライアント側のモデルを作成する必要があるように思えるので、EFがそのようなコーディング時間を節約するかどうかはわかりません
• ネットワークを経由するときにクラスをできる限り小さくしたいのですが、EFを使用すると、多くの場合、不要な追加データが含まれることがあります
• 複数のデータベースにまたがる複雑なデータベースレイヤーがあり、EFがこれを処理できるかどうかはわかりません。ユーザー、ステータスコード、タイプなどを含む共通データベースと、アプリケーションの異なるインスタンス用のメインデータベースの複数のインスタンスがあります。SELECTクエリは、データベースのすべてのインスタンスに対してクエリを実行できますが、ユーザーは、現在作業しているデータベース内のオブジェクトのみを変更できます。アプリケーションをリロードせずにデータベースを切り替えることができます。
• オブジェクトモードは非常に複雑で、多くの場合、多くの結合が関係します

EFの引数は次のとおりです。

• 並行性。各保存の前にレコードが更新されたかどうかを確認するためにチェックをコーディングする必要はありません。
• コード生成。EFは私のために部分クラスモデルとPOCOを生成できますが、検証といくつかのカスタム解析メソッドのためにクライアント側モデルを作成する必要があると思うので、これは本当に多くの時間を節約するだろうと確信しています。
• すべてのデータベースオブジェクトに対してCRUDストアドプロシージャを作成する必要がないため、開発の速度

現在のアーキテクチャは、パラメーター化されたストアドプロシージャを介してデータベース呼び出しを処理するWPFサービス、WCFサービスとWPFクライアントとの間でやり取りされるPOCOオブジェクト、および検証のためにPOCOをクラスモデルに変換するWPFデスクトップクライアントで構成されますデータバインディング。

私の質問は、EFはこれに適していますか？EFについて私が知らない落とし穴はありますか？

私は最近Entity Frameworkを評価していましたが、問題や欠落している機能を見つけた最適な場所は次のとおりです。http： //data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

投票数が最も多いアイテム：

1. 列挙型のサポート。これはかなり大きいですが、現在いくつかの回避策があります
2. SQL生成の改善。特にエンタープライズレベルのアプリケーションでは速度が非常に重要ですが、EF4では大幅に改善されたようです
3. 複数のデータベースのサポート。大規模なアプリケーションの要件。

ユーザー音声リストにはさらに多くの問題があります。

補足として、コードファーストアプローチを含むEF 4.1の今後のリリースについて非常に興奮しています... http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4 -1-release-candidate-available.aspx

これにより、実稼働アプリケーションでEFを試してみることになります。

EFでバグごとのブランチ/機能を実行すると、マージ時に非常に苦痛になる可能性があります。2つのブランチAとBがデータベースに変更を加えることを想像してください（これはおそらく新しいプロジェクトの初期段階で頻繁に行われます）。

すべての「通常の」ファイル（csファイルなど）をマージします。次に、Model.edmxをマージします。突然、オブジェクトモデルとデータベース間の論理マッピングだけでなく、エンティティダイアグラム内のテーブルの位置もマージします。

Model.edmxのマージは非常に苦痛なので、かなり厄介なWay That Worksを採用しました。

• マージ中に、1つの親からすべてのマージを選択するだけです。どちらでもかまいません。とにかくすぐにファイルを乾杯します：
• Model.edmxをいずれかの親に戻します。
• データベースを新しいマージ状態に移行します。
• Model.edmxを開き、「データベースからモデルを更新」します。
• マージ中にトーストされたすべてのナビゲーションプロパティの名前を変更します。

EFには他にもいくつかの利点があります。

• エンティティスパンテーブルを持つことができます
• テーブルを多くのタイプのエンティティに分割できます
• データベースからエンティティを生成できます（つまり、マスターアプローチとしてのデータベース）
• エンティティからデータベースを生成できます（つまり、マスターアプローチとしてのコード）
• LINQクエリはSQLクエリに変換され、パフォーマンスが向上します。

欠点（特に検証を使用している場合）：

• 適切な検証属性で検証するプロパティを持つ別のクラスを指す[MetadataClass]属性を作成する必要があります。すべてのプロパティはobjectタイプであるため、メタデータを読み取るためだけにあります。まだ多くの余分な非アクティブなコード。
• EntityFrameworkの使用は、NHibernate（および親Javaバージョン）のようなものが機能するように設計されている方法とは異なる概念です。EntityFrameworkはで最も得意添付オブジェクトはすべての回でのライブ接続を使用しているモード。NHibernateおよび同様のORMツールは、データのロード/保存時にのみ接続が使用される分離モードで最適に機能します。

これらは、私が抱えている最大の不満です。多くの利点がありますが、NHibernateから同じ利点を得ることができるかもしれません。EntityFrameworkがテーブルにある場合は、チームにNHibernateもチェックアウトさせ、プロジェクトの長所/短所をすばやく確認してもらいます。

メタデータクラスの問題は頭痛の種ですが、ありがたいことに、検証タグを必要とするエンティティが非常に多くあります。

オブジェクトに真の分離モードがないと、Web環境でできることは制限されます。添付モードはデスクトップアプリケーションに適しています。デスクトップアプリケーションは、マイクロソフトの多くの革新が始まった場所です。分離モードは可能ですが、非常に苦痛です。この場合、代替ツールを使用することをお勧めします。

Microsoftはで非常に良いではないことの一つは、後方で比較可能性、それは新しい技術に来る場合は特に、互換性

具体的には、EF1（.net 3.5）はEF4（.net 4.0）とは大きく異なります。次のバージョンでも同じことが起こる可能性があります。

私はしばらく待って、テクノロジーがどのように成熟するかを確認します。

それまでは、nHibernateの使用を検討してください。同等ではありませんが、成熟しており、広く使用されています。

• 単純に...ドメインモデルがデータベース内のリレーショナルモデルのレプリカになることはめったにありません。そのため、いくつかのテーブルをクラスにマッピングし、それをワイヤ上に投げるのは、単なる怠です。データベースは3つの異なるテーブルですが、テーブルは1つのオブジェクトにローカルにマッピングされる場合があります。データベースをインテリジェントに設計します。
• 2番目に、このEFのものは特定のクエリを生成できないため、とにかくそれらを記述する必要があります。
• 3番目のドメインモデルはサービスに直接マッピングされません。特に、モバイルアプリと通信する場合は、最も最小限のデータセットをDTOとしてネットワーク上にプッシュするだけです。
• 5番目のテスト能力...コードの変更に対して十分な回帰を提供する十分な粒度のテストを作成できない...簡単に
  破れる...

10ページのdiatribeを作成できます。しかし、もしあなたが会社Xのためのスローアウェイアプリを書いているだけなら.. しかし、ソフトウェア製品を開発している場合は...もっとアナルにならなければなりません

これをチェックしてください：http : //efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

主なポイントは次のとおりです。

• 遅延読み込みの欠如
• 執persistな無知の欠如
• エンティティモデルの保存に使用されるファイル形式には視覚化要素の両方が含まれており、エンティティモデル自体がチーム環境でマージの問題を引き起こします。

上記のリンクはEF1について述べていることに注意してください。

また、このリンク：http : //ormeter.net/は、パフォーマンスとLINQサポートにおいて、EFが他のORMと比較して最良ではないことを示しています。