この問題については、同様の質問がいくつかあります。どちらに進むかを決定する十分な理由がまだ見つからないためです。
本当の問題は、Repository パターンを使用して NHibernate を抽象化するのが合理的かどうかです。
抽象化の背後にある唯一の理由は、必要に応じて NHibernate を別の ORM に置き換えるオプションを自分自身に残すためのようです。しかし、リポジトリを作成してクエリを抽象化することは、さらに別のレイヤーを追加し、配管の多くを手作業で行うように思えます。
1 つのオプションはIQueryable<T>、ビジネス レイヤーに公開して LINQ を使用することですが、私の経験では、LINQ サポートはまだ NHibernate に完全には実装されていません (クエリは常に期待どおりに機能するとは限らず、フレームワークのデバッグに時間を費やすのは嫌いです)。
ビジネス層で NHibernate を参照すると目が痛いですが、それ自体がデータ アクセスの抽象化のはずですよね?
これについてどう思いますか？
良い質問。私も数日前にそれらについて考えていました。
実際、NHibernate 3.0 alpha (または現在のトランク) を試してみてください。その新しい LINQ プロバイダーは以前のものよりもはるかに優れています。(これまでのところ、機能していない方法は 1 つしか見つかりませんでしたが、デフォルトでサポートされていない方法に遭遇した場合は、独自のメカニズムをフックすることができます。) 現在のトランクの使用に (まだ?) 問題はありませんでした。 . http://www.hornget.net/packages/サイトで「ナイトリー」ビルドと、それに対する FluentNHibernate ビルドを見つけることができます。Fluent の使い方を知っていれば、生産性が大幅に向上します。SO コミュニティもそれを助けてくれました。
ビジネス層が NHibernate に直接依存していても構わない場合、またはこの種の抽象化を行わなくても保守可能な小さなアプリケーションを作成している場合は、リポジトリ パターンを使用しなくても問題ありません。ただし、正しく行えば、冗長なコーディングを大幅に削減できます。
それを抽象化する理由は、後で NHibernate を別の ORM に置き換えることができるという理由だけではありませんが、懸念の分離と呼ばれる概念のために良い習慣です。ビジネス ロジック層は、処理するデータへのアクセス方法を気にしたり、知ったりする必要はありません。これにより、アプリケーションまたはそのさまざまなレイヤーの保守が容易になり、チームワークも容易になります。X がデータ アクセス レイヤーを作成し、Y がビジネス ロジックを作成する場合、お互いの作業を詳細に知る必要はありません。
を公開することIQueryable<T>は非常に良い考えであり、それはまさに多くのリポジトリ実装が現在行っていることです。(私もそうですが、私はそれを静的クラスで作成することを好みました。) もちろん、必要に応じて、エンティティを挿入または更新するためのメソッド、またはトランザクションを開始およびコミットするためのメソッドをいくつか公開する必要があります。(BeginTransaction はIDisposable、NHibernate インターフェースのリークを避けるために を返すだけで十分です。)
私はあなたにいくつかの指示を与えることができます.SharpArchitectureまたはFubuMVC Contribの実装をチェックして、それを正しく行う方法についていくつかのアイデアを得ることができます.これが私が解決した方法です.
私は単に大きなイエスと言うでしょう！リポジトリパターンを持ち、物事を抽象化してください!
個人的には、NHibernate をリポジトリ パターンに抽象化することを引き続き好みます。その理由は、キャッシング、単体テストのモックなどのためにリポジトリの他の実装をまだ持っている可能性があるためです。また、リポジトリで IQueryable も使用しますが、IQueryable タイプの IRepository でプロパティを公開するのではなく、IRepository で IQueryable を拡張します。
別のリポジトリ ポイント。ジェネリックにせず、メソッド レベルで型を識別することを提案する人もいます (つまり、repository.Load)。ただし、これは、すべてのタイプを処理する方法を知っている単一のリポジトリがあることを前提としています。私は、単一のモノリシック リポジトリというこの概念の大ファンではありません。複数のデータベースを扱っている場合はどうなりますか? または、複数の永続化メカニズムですか? または、一部のデータ型はかなり静的なままで、キャッシュできますが、他の型はできません。これが、タイプごとに個別のリポジトリ インスタンスが好きな理由です。