リポジトリパターンを正しく使用するにはどうすればよいですか？

リポジトリをどのようにグループ化する必要があるのでしょうか。asp.net mvcや私の本で見た例のように、基本的にデータベーステーブルごとに1つのリポジトリを使用します。しかし、それは多くのリポジトリのように思われるため、後でモックなどのために多くのリポジトリを呼び出す必要があります。

だから私はそれらをグループ化する必要があると思います。ただし、それらをグループ化する方法がわかりません。

今、私はすべての登録を処理するための登録リポジトリを作成しました。ただし、更新する必要があるテーブルが4つあり、これを行うために3つのリポジトリがあります。

たとえば、テーブルの1つはライセンステーブルです。彼らが登録するとき、私は彼らの鍵を見て、データベースに存在するかどうかを確認します。登録以外の場所で、このライセンスキーまたはそのテーブルの何かを確認する必要がある場合はどうなりますか？

1つの場所はログインである可能性があります（キーの有効期限が切れていないかどうかを確認してください）。

それで、私はこの状況で何をしますか？コードを書き直します（DRYを破ります）？これらの2つのリポジトリを一緒にマージして、他の時点でメソッドが不要になることを期待してください（userNameが使用されているかどうかをチェックするメソッドがあるかもしれませんが、別の場所で必要になるかもしれません）。

また、それらをマージする場合、サイトの2つの異なる部分のすべてのロジックが長くなり、ValidateLogin（）、ValdiateRegistrationForm（）のような名前が必要になるため、同じリポジトリに2つのサービスレイヤーを配置する必要があります。 、ValdiateLoginRetrievePassword（）など。

または、とにかくリポジトリを呼び出して、奇妙な名前を付けますか？

アプリケーションの多くの場所で使用できるように、十分に一般的な名前のリポジトリを作成するのは難しいようですが、それでも意味があります。リポジトリ内の別のリポジトリを呼び出すことは良い習慣ではないと思いますか？

リポジトリパターンをいじってみたときに間違ったことの1つは、あなたと同じように、テーブルはリポジトリ1：1に関連していると思いました。ドメイン駆動設計からいくつかのルールを適用すると、リポジトリのグループ化の問題がなくなることがよくあります。

リポジトリは、テーブルではなく、集約ルートごとに配置する必要があります。つまり、エンティティが単独で存在するべきではない場合（つまりRegistrant、特に参加してRegistrationいるエンティティがある場合）、それは単なるエンティティであり、リポジトリは必要ありません。集約ルートのリポジトリを介して更新/作成/取得する必要があります。所属しています。

もちろん、多くの場合、リポジトリの数を減らすこの手法（実際には、ドメインモデルを構造化する手法です）は適用できません。これは、すべてのエンティティが集約ルートであると想定されているためです（ドメインに大きく依存します。私は盲目的な推測のみを提供できます）。あなたの例Licenseでは、Registrationエンティティのコンテキストなしでそれらをチェックできる必要があるため、集約ルートのようです。

しかし、それは私たちをカスケードリポジトリに制限するものではありません（RegistrationリポジトリはLicense必要に応じてリポジトリを参照することができます）。これはLicense、Registrationオブジェクトから直接リポジトリを参照する（IoCを介して）ことを制限するものではありません。

テクノロジーによってもたらされる複雑さや何かの誤解によって設計を推進しないようにしてください。ServiceX2つのリポジトリを構築したくないという理由だけでリポジトリをグループ化するのは良い考えではありません。

固有名詞を付ける方がはるかに良いでしょう-RegistrationServiceすなわち

しかし、サービスは一般的に避けるべきです-それらはしばしば貧血ドメインモデルにつながる原因です。

編集：
IoCの使用を開始してください。依存性を注入する手間を本当に軽減します。
書く代わりに：

var registrationService = new RegistrationService(new RegistrationRepository(),  
      new LicenseRepository(), new GodOnlyKnowsWhatElseThatServiceNeeds());

あなたは書くことができるでしょう：

var registrationService = IoC.Resolve<IRegistrationService>();

Psいわゆる共通サービスロケーターを使用する方が良いでしょうが、それは単なる例です。

これに対処するために私が始めたことの1つは、N個のリポジトリをラップするサービスを実際に開発することです。うまくいけば、DIまたはIoCフレームワークがそれを簡単にするのに役立つでしょう。

public class ServiceImpl {
    public ServiceImpl(IRepo1 repo1, IRepo2 repo2...) { }
}

それは理にかなっていますか？また、このマナーでのサービスについて言えば、実際にはDDDの原則に準拠している場合と準拠していない場合があることを理解しています。

私がしているのは、次のように定義された抽象基本クラスがあることです。

public abstract class ReadOnlyRepository<T,V>
{
     V Find(T lookupKey);
}

public abstract class InsertRepository<T>
{
     void Add(T entityToSave);
}

public abstract class UpdateRepository<T,V>
{
     V Update(T entityToUpdate);
}

public abstract class DeleteRepository<T>
{
     void Delete(T entityToDelete);
}

次に、抽象基本クラスからリポジトリを派生させ、たとえば一般的な引数が異なる限り、単一のリポジトリを拡張できます。

public class RegistrationRepository: ReadOnlyRepository<int, IRegistrationItem>,
                                     ReadOnlyRepository<string, IRegistrationItem> 

等....

一部のリポジトリには制限があり、これにより最大限の柔軟性が得られるため、個別のリポジトリが必要です。お役に立てれば。

私はこれをリポジトリクラスとして持っており、そうです、テーブル/エリアリポジトリで拡張しますが、それでも時々DRYを壊さなければなりません。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MvcRepository
{
    public class Repository<T> : IRepository<T> where T : class
    {
        protected System.Data.Linq.DataContext _dataContextFactory;

        public IQueryable<T> All()
        {
            return GetTable.AsQueryable();
        }

        public IQueryable<T> FindAll(Func<T, bool> exp)
        {
            return GetTable.Where<T>(exp).AsQueryable();
        }

        public T Single(Func<T, bool> exp)
        {
            return GetTable.Single(exp);
        }

        public virtual void MarkForDeletion(T entity)
        {
            _dataContextFactory.GetTable<T>().DeleteOnSubmit(entity);
        }

        public virtual T CreateInstance()
        {
            T entity = Activator.CreateInstance<T>();
            GetTable.InsertOnSubmit(entity);
            return entity;
        }

        public void SaveAll()
        {
            _dataContextFactory.SubmitChanges();
        }

        public Repository(System.Data.Linq.DataContext dataContextFactory)
        {
            _dataContextFactory = dataContextFactory;
        }

        public System.Data.Linq.Table<T> GetTable
        {
            get { return _dataContextFactory.GetTable<T>(); }
        }

    }
}

編集

public class AdminRepository<T> : Repository<T> where T: class
{
    static AdminDataContext dc = new AdminDataContext(System.Configuration.ConfigurationManager.ConnectionStrings["MY_ConnectionString"].ConnectionString);

    public AdminRepository()
        : base( dc )
    {
    }

Linq2SQL.dbmlクラスを使用して作成されたデータコンテキストもあります。

これで、AllやFindなどの標準呼び出しを実装する標準リポジトリができ、AdminRepositoryに特定の呼び出しがあります。

とは思いませんが、DRYの質問には答えません。

これは、 FluentNHibernateを使用した一般的なリポジトリ実装の例です。マッパーを作成したクラスを永続化することができます。マッパークラスに基づいてデータベースを生成することもできます。

リポジトリパターンは悪いデザインパターンです。私は多くの古い.Netプロジェクトで作業していますが、このパターンは通常、「分散トランザクション」、「部分ロールバック」、および「接続プールの枯渇」エラーを引き起こしますが、これは回避できます。問題は、パターンが接続とトランザクションを内部で処理しようとしますが、それらはコントローラー層で処理する必要があることです。また、EntityFrameworkはすでに多くのロジックを抽象化しています。共有コードを再利用するには、代わりにサービスパターンを使用することをお勧めします。

私はあなたが見てすることをお勧めシャープアーキテクチャ。彼らは、エンティティごとに1つのリポジトリを使用することを提案しています。私は現在私のプロジェクトでそれを使用していて、結果に満足しています。