nhibernate - ORMを選択する場合、LINQtoSQLまたはLINQtoEntitiesはNHibernateよりも優れていますか？

Question

Linq toEntitiesやlinqtoSQLよりも、NHibernate、さらにはCastleでより多くのことができることがわかりました。

私は夢中ですか？

Answer 1

いいえ、あなたは狂っていません。nHibernate は完全な OR マッパーです。Linq to SQL および Linq to Entities は、OR マッパーに期待されるすべてを実装するわけではなく、わずかに異なる開発者グループを対象としています。

しかし、だからと言って linq から離れてはいけません。Linqはまだかなり良いアイデアです..LinqをnHibernateに試し​​てみてください:-)

Answer 2

NHibernate、Castle などの大きな欠点は、軽量ではないことです (特に NHibernate)。

Linq to SQL は、軽量で用途が限定された ORM に適しています。

Answer 3

NHibernate と LINQ to SQL の両方を使用しました。私の観点からは、それはプロジェクトによって異なります。何か手っ取り早く必要な場合は、L2S を選択します。dbml マッピングを作成して使い始めるのはとても簡単です。より高度なエンタープライズ ソリューションを開発している場合は、実績のある信頼できる ORM である NHibernate を使用します。ロギングとトランザクションの機能は使いやすいと思います。

LINQ to SQL の学習曲線は比較的短く、NHibernate の学習曲線ははるかに急です。

LINQ to SQL は SQL Server のみをサポートするため、Oracle データベースを使用している場合は、NHibernate を選択することが既に決定されています。

NHibernate の学習に関する優れたスクリーンキャストについては、http: //www.summerofnhibernate.com/をチェックすることをお勧めします。

Answer 4

心に留めておくべきことの 1 つは、NHibernate は構成するための絶対的なブタになる可能性があるということです。特に、元の Hibernate がルートであるため、主に XML 構成ファイルに基づいているためです。

Fluent NHibernateは、この問題を軽減するために何らかの方法を採用しています。

Linq は確かに、.NET が動作する一般的な「方法」に適合します。

Answer 5

Blockquote Linq は確かに、.NET が動作する一般的な「方法」に適合します。

うーん、こういう感情は怖いです。.net に組み込まれている RAD のものは、ドット ネットがどのように機能するかではなく、プロトタイプを作成するための単なるツール セットです。.NET を使用すると、完全な DDD アプリケーションを実行でき、高度な凝集性と関心の分離を実現できます。また、ms が物事を結合しようとするすべての試みにもかかわらず、分離されたコードを記述することができます。私は、.net が結合されることを好み、特定のツールが結合されることを好むことに強く反対します。この争いに linq to sql を含めます。linq to sql は、別個のドメイン モデルを持つという考えを破壊します。データベース スキーマを基礎となるモデル オブジェクトとして使用することを考えると、うんざりします。適切な ORM ツールを使用すると、最初にドメインをモデル化し、次にリレーショナル データベースをこれらのモデルにリンクできます。その逆ではありません。

Answer 6

私は Entity Framework を試したことはありませんが、Linq よりも NHibernate を SQL に使用することを強くお勧めします。私が与えることができる最大の理由は、単にコントロールです。Linq to SQL は、オブジェクトをロードし、オブジェクトに関するあらゆる種類の追跡情報を維持しながら、すべてをより詳細に制御することを好みます。シリアライズ/デシリアライズすると、追跡情報が失われ、再保存時に奇妙なことが起こる可能性があります。NHibernate は、リポジトリとしてより機能します。必要なオブジェクト (もちろん、理解できるように構成したもの) を渡すと、何を行ったかに関係なく、データベースに格納されます。