Entity Framework 4対NHibernate [終了]

Entity Frameworkの最初のバージョンがWebでも（stackoverflowでも）話題になっていますが、NHibernateのようなより良い代替案がすでにある場合は、それが適切な選択肢ではなかったことは明らかです。しかし、Entity Framework 4とNHibernateの良い比較を見つけることができません。今日、NHibernateはすべての.NET ORMのリーダーであると言えますが、Entity Framework 4がこの位置からNHibernateを置き換えることが期待できます。MicrosoftがEF4に非常に優れた機能を実際に注入した場合、Visual Studioとの統合があり、扱いやすく、ほとんどのショップで常にMS製品が優先されるため、NHibernateに良い競争をもたらすことができると思います。

EF4には、「自己追跡エンティティ」のn層開発に関して、すぐに使える回答があります。NHibに相当するコードは誰もリリースしていません。

NHibには、EF4の一部として言及されていない多くの機能があります。これには、2次キャッシュの統合が含まれます。また、継承マッピングの柔軟性が高まり、ストアドプロシージャ/データベース関数/カスタムSQL /トリガーとの統合が向上し、式のプロパティのサポートなどが提供されます。IMOそれは基本的にORMとしてより成熟しています。

更新：バージョン4.0以降、Entity Frameworkを使用していないので、私の回答は古くなっている可能性があります。プロジェクトではまだNHまたは純粋なADO .NETを使用しています。また、NHは完全に機能するため、4.0以降のEFの新機能についても見たくありません。

実際に両方を使用した場合、それらを比較するのはかなり簡単です。EF4にはいくつかの深刻な制限があります。自分が遭遇したものをいくつか挙げます。

EF4の問題：

• 熱心なロードと結果の形成：EF4熱心なロードシステム（Include（ "Path"））は不適切なSQLを生成し、ループするJOINを使用します。実質的に使用できません）。
• マテリアライザは関連するエンティティを具体化できません：独自のSQLクエリを提供することで以前の問題を克服できると考えることができる場合は、誤りです。EF4は、JOIN SQLクエリから関連付けられたエンティティを実体化（マップ）できず、1つのテーブルからのみデータをロードできます（したがって、Order.Productがある場合、SELECT * FROM order LEFT JOIN ProductはOrderオブジェクトのみを初期化し、Productはnullのままです。必要なすべてのデータがクエリでフェッチされ、初期化されると考えられました）。これはEFExtensionsコミュニティアドオンを使用することで克服できますが、このために作成する必要があるコードは本当に醜いです（私は試しました）。

• 自己追跡エンティティ：多くの人は、このスレッドのトップアンサーを含め、セルフトラッキングエンティティはN層開発に最適だと言っています。私は彼らに試しさえしていなかったとは思いますが、私はそうではないと言えるでしょう。すべての入力は偽造される可能性があり、ユーザーがあなたに送信した変更をデータベースに適用するだけでは、ユーザーに直接データを与えないのはなぜですかではベースアクセス？ユーザーがDBから変更しようとしているデータをロードする必要があるすべての方法、それが存在することを確認します|存在しないことを権限チェックなどを実行します。サーバーに送信しているエンティティの状態でユーザーを信頼することはできません。とにかくこのエンティティをDBからロードして状態などを決定する必要があるため、この情報は役に立たない。内部追跡用のプライベートな信頼できるn層システムを使用しない限り、この情報はセルフトラッキングエンティティと同様に役に立たない。 DBアクセス。

• ロギング、イベント、ビジネスロジックの統合： EF4はブラックボックスのようなものであり、何かを実行し、何を実行するのかまったくわかりません。イベントが発生する前に実行する必要があるビジネスロジックを配置できるOnSavingChangesのイベントは1つだけです。何かが発生する前にビジネスオブジェクトに変更を適用する必要がある場合は、ObjectStateManagerを掘る必要があり、これは本当に醜いです。 、コードが巨大になる可能性があります。たとえば、Repositoryパターンを使用していて、クリーンなオブジェクトの方法でDBに加えられた変更について通知を受ける場合、EFでこれを行うのは困難です。

• 拡張性：すべてのEFコードはプライベートで内部的なものであり、何かが気に入らない場合（EFの使用に真剣に取り組んでいる場合はLOTが気に入らない場合）、これを簡単に変更する方法はありません。自分でORMを最初から作成して（私が作成しました）、必要に応じてEFを機能させる方が簡単です。例として、EFExtensionsのソースを見てみましょう。これは拡張メソッドに基づいており、EFを少し使いやすくするためのさまざまな「ハック」であり、コードはかなり醜いです（そして、EF内のすべてがプライベートである場合、これは唯一の問題です。それを拡張する方法）。

私はEFについて悪いことを書き続けることができますし、20ページのようにEFで作業するのがどれほど苦痛だったか、おそらく私はそうするでしょう。

NHibernateはどうですか？それはまったく異なるレベルであり、PHPをC＃と比較するようなものです。EF4はStone-ageのようなものであり、EFは開発の進行においてNHibernateから10年遅れているようです。実際、Hibernateは2001年に開始されました。 Nhibernateを学習してオンにするには、それを実行してください。

つまりね。私の考えでは、NHibernateとEntity Frameworkは実際には2つの異なる対象者向けです。NHibernateは、複雑なマッピング、式、および制約（基本的にはあらゆる企業）を備えたシステムを構築する上で私の選択です。単純なデータアクセスですぐに実行したい場合は、Entity FrameworkまたはLINQ-to-SQLを使用します。NHibernateは、EFのような明確な「ドラッグアンドドロップ」エクスペリエンスを備えていません。どちらにも長所と短所があります。それらを比較すると、正直に言って、どこにも行きません。

Monoでコードを実行したい場合は、機能チェックリストの内容に関係なく、NHibernateを選択することをお勧めします...

編集、2012年8月13日：

Entity Frameworkはオープンソースであり、2.11.3の時点でMonoに含まれています。この回答は古くなっているため、信頼してはなりません。

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx

私の見解では、EF4.0は1.0以降、長い道のりを歩んできており、Nhibernateの機能に追いついていますが、まだすべてではありません。

しかし、それはマイクロソフトであり、箱から出して、アプリケーションの95％が実行する必要があることの100％を実行します。ただし、NHibernateは何年も同じことをしています。バージョン5.0または6.0が追いつくか、NHibernateを超える可能性があります。

これが私のアドバイスです-あなたが両方を学ぶ時間があるなら、それをしてください。どちらかを選択する理由はいくつかあります。企業向けのコードを書いている場合、EFに精通している従業員がすべての本と子供たちが大学で学ぶものであるため、EFに精通していると期待することが現実的です。EFが要件を満たす場合（これについて「はい」と答える前に長くて難しいことを考えてください）、それは今のところ完全に優れたソリューションであり、数年後には、NHibernateを超える可能性があります。

NHibernateは、EFで数年を経た非常に成熟した製品であり、あなたがしたいことすべてを実行し、その後いくつかを実行する可能性が最も高いでしょう。しばらくの間、それは最高のORMであり、多くの人々がそれを使用しています。

EF 4がPOCOを使用できるようになり、遅延遅延読み込みが非常に大きくなると思います。新しいリリースでそれが勢いを増しているのをはっきりと見ることができました。

NHibernateよりEFの人気が高まるという明らかな傾向があります。図を参照してください。

私の2セント：いくつかのキャッシュなどのためにデスクトップクライアントでefを使用します-hiロードはありません。サーバー側のNHib-ステートレスセッション、HILO ID生成、およびバッチを利用します。3k以上のメッセージをdb /秒で挿入するのは非常に高速です。また、非常に柔軟性があり、多くのデータベースをサポートします。これは、当社の製品にとって非常に重要です。

論理層のLinqを組み合わせてストアドプロシージャに直接マッピングするのが最も簡単なアプローチのようです。XMLはありません。使用頻度が低いか、ストアドプロシージャに適さない興味深いクエリに対してのみSQLを生成します。

オブジェクトは、標準のSPを通じて読み込まれ、保存されます。このアプローチでは、2つのSQLログインを使用できます。1つはSP（実行専用権限）を介したクラスアクセス用で、もう1つはテーブルへの直接アクセスを可能にする論理linqモジュール用です。

人気によってORMを選択することは、最良の方法ではありません。私は過去2年間EFに移動しようとしましたが、言えることは、なぜ私がまだ地獄にいるのですか？

ATM EFについての私の見解は、「関係が1未満（0がより良い）で、テーブルが3つ以下の非常に小さなかなり小さなビットシステム用に作られています」です。

そして、なぜ私はそのように思いますか？1.切断されたグラフを更新して、モデルのスクラッチを確認します。

1. 深い継承ツリーでTPHを作成しようとすると、単一の階層に束縛されているか、システムが壊れていることに気づくでしょう。

2. より面倒なクエリを作成して、システム全体がスタックを食い尽くすのを確認してください：D ...オーバーフローが頻繁に発生します。

3. Map XMLデータ型は、拡張機能または最も「憎悪された」NotMappedプロパティに基づいています...そしてそれはさらに悪いことです。

4. より詳細なクエリを行うには、SQLクエリをLinqに混合してみてください。

5. 最後に、最も重要なことは、EFはプロパティ式（「NHがレガシーデータベースのために持っている素晴らしいリソース」）をサポートせず、同じテーブルと関連テーブルの複雑な型マッピングをサポートしないことです。

それは私の10ccです。