ORMツールを使用して、2つの候補に移動しようとしています。
nHibernateまたはLLBLGenPro
特に両方の経験がある場合は、これらのツールの両方を使用する際の長所と短所を教えてください。私は他のツールにはあまり興味がありませんが、学習に時間を費やすツールを決定できるように、いくつかの注意を払う必要があります。
1つは無料で、もう1つは無料ではないことはすでに知っています。また、nHibernateにはある程度の学習が必要になる可能性があることも知っています。
どうもありがとう、リチャード
私は両方を使用しました。最初、私はnHibernateで販売され、他のオプションについて知っていたにもかかわらず、他のことを試すことを拒否しました。
LLBLGen Proでは、私は懐疑的でしたが、すぐにその利点もわかりました。私はnHibernateを完全に放棄したわけではありません。私は「ツールの箱」にintを保持し続けます。LLBLGenは、特に既存のデータベースと対話するときに、再設計する選択肢がない場合に役立つことがわかりました。nHibernateを使用してすべてを手動でコーディングし、マッピングを行う必要があるのとは対照的に、データベースからLLBLGenエンティティオブジェクトを生成するのに1時間もかかりません（もちろんデータベースのサイズによって異なります）。nHibernateには、マッピングを作成するための優れたグラフィカルインターフェイスがありません。この事実は、アプリケーションでアクセスする必要のある数千のテーブルがデータベースに含まれている場合にさらに重要になります。
LLBLGenはデータアクセス層ジェネレーターのようなものですが（私は通常DALジェネレーターのファンではありません）、「真のORM」ツールが持つであろう多くの機能を備えています。私の意見では、それは両方の長所を持っています。それを使い始めると、それが非常に柔軟で拡張可能であることに気づき始めます。私がとても気に入っている部分の1つは、生成されたエンティティオブジェクトの部分的なクラスを作成できることです。ここで、ビジネスロジックでコーディングしたり、検証したりできます。
コード生成はテンプレート化されているため、生成するコードを完全に制御できます。nHibernateを使用すると、同じ種類のコードを何度も何度も書いていることに気づきます。LLBLGenを使用すると、それを生成して、ビジネスロジックと問題にすばやく集中できます。
ORMタイプのツールを使い始めたばかりの人には、nHibernateが圧倒される可能性があるため、LLBLGenから始めることを強くお勧めします。そして最終的には同じ結果が得られます（多かれ少なかれ）。
編集＃1： LLBLGenはLINQも100％サポートするようになりました。（したがって、その理由でLINQ to SQLが好きな場合）さらにLLBLGenは多くのデータベースをサポートできますが、LINQtoSQLはMicrosoftSQLデータベース専用です。
編集＃2： Gravitonによると、 CodeSmithを使用して、nHibernate用に生成するコードの一部を実行できます。それは本当にクールですが、ORMの初心者には、LLBLGenをお勧めします。私にとっては、LLBLGenがすべてを1つのパッケージに収めているところに依存関係を追加しています。また、前に言ったように、学習曲線はそれほど急ではなく、同じ利点が得られます。これは、nHibernateに行くことにした場合にも簡単になります。
主な違いは、LLBLGenがコードジェネレーターであるのに対し、NHibernateは「真の」ORMライブラリーであるということです。
LLBLGenの利点：
LLBLGenの欠点：
NHibernateの利点：
NHibernateの欠点：
もちろん、これは私の個人的な見解です...
これがやや古い質問であることに気付く前に、私はかなり長い答えを入力しました。しかたがない。それはまだ非常に関連性があります。
リストを.NETの世界でORMに最適な2つの候補に絞り込みました。どちらかについての経験は限られていますが、両方の長所と短所について詳しく読んでいます。それらは実際には、さまざまな方法で多少異なるニーズに対応します。
今後のLLBLGenPro3.0で、FransBoumaはNHibernateマッピングを生成する機能の追加について話しました。したがって、それは必ずしもどちらかまたは両方の決定ではありません。
（「データベースファースト」デザインではなく）「クラスファースト」デザインを実行したい場合は、NHibernateが最適であり、現時点で唯一のオプションです（LLBLGenProもEntityFrameworkもこのモードをサポートしていませんが、EntityFrameworkは次のバージョンでのサポートを改善します）。
NHibernateとLLBLGenProはどちらも、変更できず、使用しなければならないレガシーデータベースとうまく連携するために一生懸命働いています。それが彼らの共通の強みです。どちらもLinqと連携します。LLBLGen Proはこの点ではるかに優れていますが、どちらもある程度のグラフィカルモデリングをサポートしています（NHibernate用のActiveWriterはVisual StudioのLinqToSqlデザイナーのように感じますが、実際には機能が豊富ではありません）。
LLBLGen Proははるかに強力なコード生成機能を備えていますが、コード生成が多すぎると、テスト容易性と保守性が損なわれる可能性があります（1つの小さな調整により、大量のコードを再テストする必要が生じる可能性があります）。
NHibernateは、クラス継承のようなかなり複雑なオブジェクト/リレーショナルマッピングシナリオの処理を支援したいと考えていますが、LLBLGen Proは、データベースをデータレイヤーおよびビジネスオブジェクトとして非常に迅速に公開しているだけです。
LLBLGen Proを購入して時間があれば、両方を試して、どちらがニーズに合っているかを確認します。どちらの場合でも、両方のORMを学習することは、履歴書に役立ちます。
ですから、結局のところ、状況に応じたものだと思います。NHibernateのコストと深刻な欠陥の欠如は、ほとんどの状況でかなり説得力のあるケースになります。
新しいバージョンのLLBLGenPro（3.0）では、NHibernateのコードを生成できるため、:)を選択する必要はありません。また、エンティティを異なるドメインに分割することもできます。
私はまだLLBLGenproランタイムを好みますが、LINQインタープリターはより完全であり、フィールドの変更追跡が優れています。
残念ながら、新しいLLBLGen Pro 3.0ランタイムには多くの新機能はありません。これは、作成者が最初に既存のフレームワークの改善よりもツールに重点を置きたいと考えていたためです。
私はnHibernate、LLBLGen Pro、コンサルティング会社のカスタムデータレイヤー、Enterprise Library、およびLINQを使用しました。LLBLGenは私のお気に入りであり、データベースの独立性を提供する同じコードを使用して、さまざまなタイプのデータベースと通信できる1つのビジネスレイヤーを作成できます。もう1つの驚くべき機能は、異なるデータベースへの複数の接続を可能にすることです。これは、大企業で1つのシステムがSQL Serverで作成されており、他のシステムがOracleで作成されている場合に非常に便利です。
LLBLGen Proは、非常にアクティブで問題の修正に懸命に取り組んでいるFransによってバックアップされた素晴らしい製品です。LLBLGenはPhotoShopのようなもので、信じられないほどのツールであり、使い方を知っている人の手に驚くべき効果をもたらすことができます。そして、多くの時間を節約する他のツールと同様に、その使用方法を学ぶのに1、2週間かかりますが、プロジェクトで数か月後に節約できます。
アプリのDAL生成側が高速化されただけでなく、ビジネスレイヤーでクエリを作成してプレゼンテーションレイヤーに送信するのも簡単です。エンタープライズクラスのアプリケーションを簡単に作成できました。
本当にnHibernateを使用したい場合は、LLBLGen Proから始めて、nHibernateコードを生成します。後であなたの部門がnHibernateからLINQに切り替えることを決定した場合、あなたはカバーされます。SQL ServerからOracleに切り替えたいですか？これはLLBLGenで可能であり、比較的簡単ですが、手動でコーディングされたnHibernateコードでは、コストを正当化することはほとんど不可能ですが、すべてを書き直す必要があります。
Fransも利用可能で、私の質問のいくつかに答えました。
Hibernateの最大のプラスポイントの1つであるHQLを忘れないでください。HQLを使用すると、SQLスキルが無駄になりません。また、Hibernateは、ネイティブクエリに対しても非常に優れたシームレスなサポートを提供します。奇妙で標準外のデータベースがある場合は、ある時点でSQLスキルが必要になることはほぼ間違いありません。そして、LLBLで頑張ってください。
私にとっては、データベース中心（LLBLGen Pro）とドメインモデル中心（NHibernate）に要約されます。
私はDDD/OOの人なので、選択はいつもとても簡単でしたが、LLBLGenProが人気がある理由はわかります。
LLBLGenを使用していますが、これは悪用されています。つまり、類似したスキーマが複数あるためですが、スキーマごとに異なるDLL /クラスライブラリが必要です。つまり、任意のスキーマをターゲットにできるコードを作成するのは面倒です。
もちろん、それは珍しい環境なので、あなたには当てはまらないかもしれません。