オブジェクトごとに特定のリポジトリではなく、一般的なリポジトリを作成する利点は何ですか？

ASP.NET MVCアプリケーションを開発しており、現在、リポジトリ/サービスクラスを構築しています。すべてのリポジトリが実装する汎用のIRepositoryインターフェイスを作成することには、各リポジトリが独自のインターフェイスとメソッドのセットを持っているのに対して、大きな利点があるのか​​と思います。

たとえば、汎用のIRepositoryインターフェイスは次のようになります（この回答から取得）。

public interface IRepository : IDisposable
{
    T[] GetAll<T>();
    T[] GetAll<T>(Expression<Func<T, bool>> filter);
    T GetSingle<T>(Expression<Func<T, bool>> filter);
    T GetSingle<T>(Expression<Func<T, bool>> filter, List<Expression<Func<T, object>>> subSelectors);
    void Delete<T>(T entity);
    void Add<T>(T entity);
    int SaveChanges();
    DbTransaction BeginTransaction();
}

各リポジトリはこのインターフェースを実装します、例えば：

• CustomerRepository：IRepository
• ProductRepository：IRepository
• 等

以前のプロジェクトで従った代替案は次のとおりです。

public interface IInvoiceRepository : IDisposable
{
    EntityCollection<InvoiceEntity> GetAllInvoices(int accountId);
    EntityCollection<InvoiceEntity> GetAllInvoices(DateTime theDate);
    InvoiceEntity GetSingleInvoice(int id, bool doFetchRelated);
    InvoiceEntity GetSingleInvoice(DateTime invoiceDate, int accountId); //unique
    InvoiceEntity CreateInvoice();
    InvoiceLineEntity CreateInvoiceLine();
    void SaveChanges(InvoiceEntity); //handles inserts or updates
    void DeleteInvoice(InvoiceEntity);
    void DeleteInvoiceLine(InvoiceLineEntity);
}

2番目のケースでは、式（LINQまたはその他）は完全にリポジトリ実装に含まれます。サービスを実装している人は、呼び出すリポジトリ関数を知る必要があるだけです。

サービスクラスにすべての式の構文を記述してリポジトリに渡すことの利点はわかりません。これは、多くの場合、使いやすいLINQコードが複製されていることを意味しませんか？

たとえば、以前の請求システムでは、

InvoiceRepository.GetSingleInvoice(DateTime invoiceDate, int accountId)

いくつかの異なるサービス（顧客、請求書、アカウントなど）から。複数の場所で次のように書くよりも、はるかにきれいに見えます。

rep.GetSingle(x => x.AccountId = someId && x.InvoiceDate = someDate.Date);

特定のアプローチを使用することで私が目にする唯一の欠点は、Get *関数の多くの順列が発生する可能性があることですが、これは式ロジックをServiceクラスにプッシュするよりも望ましいようです。

何が欠けていますか？

これは、リポジトリパターン自体と同じくらい古い問題です。IQueryableクエリの統一表現であるLINQの最近の導入により、このトピックについて多くの議論が生じています。

一般的なリポジトリフレームワークを構築するために一生懸命働いた後、私は特定のリポジトリを自分で好みます。どんなに巧妙なメカニズムを試しても、いつも同じ問題が発生しました。リポジトリはモデル化されるドメインの一部であり、そのドメインは一般的ではありません。すべてのエンティティを削除できるわけではなく、すべてのエンティティを追加できるわけではなく、すべてのエンティティにリポジトリがあるわけではありません。クエリは大きく異なります。リポジトリAPIはエンティティ自体と同じくらいユニークになります。

私がよく使用するパターンは、特定のリポジトリー・インターフェースを持つことですが、実装の基本クラスです。たとえば、LINQ to SQLを使用すると、次のことができます。

public abstract class Repository<TEntity>
{
    private DataContext _dataContext;

    protected Repository(DataContext dataContext)
    {
        _dataContext = dataContext;
    }

    protected IQueryable<TEntity> Query
    {
        get { return _dataContext.GetTable<TEntity>(); }
    }

    protected void InsertOnCommit(TEntity entity)
    {
        _dataContext.GetTable<TEntity>().InsertOnCommit(entity);
    }

    protected void DeleteOnCommit(TEntity entity)
    {
        _dataContext.GetTable<TEntity>().DeleteOnCommit(entity);
    }
}

DataContext選択した作業単位に置き換えます。実装例は次のようになります。

public interface IUserRepository
{
    User GetById(int id);

    IQueryable<User> GetLockedOutUsers();

    void Insert(User user);
}

public class UserRepository : Repository<User>, IUserRepository
{
    public UserRepository(DataContext dataContext) : base(dataContext)
    {}

    public User GetById(int id)
    {
        return Query.Where(user => user.Id == id).SingleOrDefault();
    }

    public IQueryable<User> GetLockedOutUsers()
    {
        return Query.Where(user => user.IsLockedOut);
    }

    public void Insert(User user)
    {
        InsertOnCommit(user);
    }
}

リポジトリのパブリックAPIでは、ユーザーを削除できないことに注意してください。また、公開IQueryableはワームの完全な他の缶です-そのトピックにはへそと同じくらい多くの意見があります。

私は実際にはブライアンの投稿に少し同意しません。私は彼が正しいと思います。最終的にはすべてが非常にユニークである、などです。しかし、同時に、それらのほとんどは設計時に明らかになります。モデルの開発中に汎用リポジトリを取得して使用すると、アプリを非常にすばやく起動でき、見つけたときに特定性を高めるためにリファクタリングできます。そうする必要があります。

そのため、そのような場合は、CRUDスタック全体を備えた汎用のIRepositoryを頻繁に作成しました。これにより、APIをすぐに利用できるようになり、UIを使って人々がプレイできるようになり、統合とユーザー受け入れテストを並行して行うことができます。次に、レポなどで特定のクエリが必要であることがわかったので、必要に応じて特定の依存関係とその依存関係を置き換え、そこから移動します。1つの基礎となる実装。作成と使用は簡単です（インメモリdbや静的オブジェクト、モックオブジェクトなどにフックすることもできます）。

とは言っても、私が最近始めたのは行動を壊すことです。したがって、IDataFetcher、IDataUpdater、IDataInserter、およびIDataDeleter（たとえば）のインターフェイスを実行する場合、インターフェイスを介して要件を定義するために組み合わせて、それらの一部またはすべてを処理する実装を持つことができます。それでも、アプリを構築しているときに使用するdo-it-all実装を注入します。

ポール

オーバーライド可能なメソッドシグネチャを使用して、ジェネリックリポジトリ（または正確な動作を指定するためのジェネリックリポジトリのリスト）から派生する特定のリポジトリを好みます。

特定のリポジトリーによってラップされた汎用リポジトリーを用意します。そうすれば、パブリックインターフェースを制御できますが、汎用のリポジトリを使用することでコードを再利用できるという利点があります。

パブリッククラスUserRepository：リポジトリ、IUserRepository

インターフェイスの公開を避けるために、IUserRepositoryを注入するべきではありません。人々が言っ​​たように、完全なCRUDスタックなどは必要ないかもしれません。