一般的な方法の単一リポジトリ...悪い考えですか？

Question

私はこのような何か、現在私が働いているプロジェクトで、リポジトリを実装するためのいくつかの異なる方法を試し、現在はその上に、一般的なメソッドを持つ単一のリポジトリを持っている：私ができる

public interface IRepository 
{ 
    T GetSingle<T>(IQueryBase<T> query) where T : BaseEntity; 

    IQueryable<T> GetList<T>(IQueryBase<T> query) where T : BaseEntity; 

    T Get<T>(int id) where T : BaseEntity; 

    int Save<T>(T entity) where T : BaseEntity; 

    void DeleteSingle<T>(IQueryBase<T> query) where T : BaseEntity; 

    void DeleteList<T>(IQueryBase<T> query) where T : BaseEntity; 
} 

その方法単一のリポジトリをクラスに挿入し、それを使用して必要なものを取得します。

これは私のために働くようだ

を（ちなみに、私はセッションごとのWeb要求パターンで、私のORMとして流暢NHibernateはを使用して、とのStructureMapを使用して、私のリポジトリを注入しています） - メソッド私はこのリポジトリに必要なすべてを行うことを定義しました。しかし私のウェブ検索では、このアプローチを使って他の人が見つからなかったので、何か不足していると思います...私のアプリケーションが成長するにつれて、これは問題を引き起こしますか？

ルートエンティティごとにリポジトリを持っていることについて多くの人が読んでいますが、ルートエンティティを特定のインターフェイスで識別し、そのインターフェイスを実装するクラスのみを許可する汎用メソッドを制限すると、 ？

ありがとうございます。

Answer 1

よりもインターフェイスでwhere T :を入れている私は現在、両方の一般的なリポジトリ（IRepository<T>）とカスタム（ICustomRepository）のミックスを使用しています。私はIQueryableまたはIQueryOverを私のリポジトリから公開していません。

また、リポジトリはクエリインターフェイスとしてのみ使用しています。私は自分のリポジトリに注入しているセッション（作業単位）オブジェクトを通じて、私のすべての保存、更新、削除を行います。これにより、私は異なるリポジトリ間でトランザクションを行うことができます。

私はジェネリックリポジトリからすべてを行うことはできませんが、いくつかのケースでは間違いありません。

あなたの質問に答えるには、私がそれを得ることができれば単一の汎用リポジトリを持つことは悪い考えではないと思います。私の実装ではこれはうまくいかないでしょうが、それがうまくいくなら、それは素晴らしいことです。私はそれがあなたのために最も効果的なものになると思う。あなたの状況に完全に対応する解決策を今までに見つけられるとは思わない。私はハイブリッドソリューションが私のためには最高に機能することを発見しました。

Answer 2

私はいくつかのプロジェクトでこのアプローチをうまく使いました。多くのIRepository<T>では、各BaseEntityのサービスレイヤに負担がかかりますが、機能します。私が変わってしまうことの一つは、むしろ方法

public interface IRepository<T> where T : BaseEntity 

Answer 3

私は自分のプロジェクトで同様のことをしました。 1つの欠点は、選択したn + 1バグを作成しないように注意する必要があることです。私は熱心に取得するためのプロパティの別のリストを渡すことでその周りにいた。

このようにORMをラップすると聞く主な議論は、漏れた抽象であるということです。あなたはまだselect n + 1のようないくつかの "gotchas"をコード化しなければならず、NHのキャッシングサポート（少なくとも余分なコードなしではない）のようなものをフルに活用することはできません。

ここでは、Ayendeのブログでこのアプローチの賛否両論についてはgood threadです。彼は多かれ少なかれパターンに反対しているが、いくつかの反論もある。

Answer 4

私はNHibernateのような種類のリポジトリを実装しました。例hereが表示されます。

この実装では、熱心な読み込みとフェッチを行うことができます。落とし穴は、NHで、QueryOverまたはCriteria APIを使用してデータにアクセスできる必要があることがしばしばあります（残念ながら、LINQプロバイダはまだ完全ではありません）。そしてそのような抽象化によって、漏れた抽象化につながる問題となる可能性があります。

Answer 5

私は実際にリポジトリパターンから離れ、作業単位のインターフェイスを作成しました。

データストアの変更、つまりDBからテキストファイルまたはXMLへの変更が予想されない限り、私にとってこれまでになかったことですが、あなたはISessionを使うのが最良です。あなたはデータアクセスを抽象化しようとしており、これはNHibernateが行うこととまったく同じです。リポジトリ制限を使用すると、Fetch（）、FetchMany（）先物などの本当にクールな機能です.ISessionはあなたの作業単位です。

NHibernateを受け入れて、直接ISessionを使用してください！