Как правильно использовать паттерн репозиторий?

Одна вещь, которую я сделал неправильно, когда играл с шаблоном репозитория - как и вы, я думал, что эта таблица относится к репозиторию 1: 1. Когда мы применяем некоторые правила из Domain Driven Design - проблема группировки репозиториев часто исчезает.

Репозиторий должен быть для совокупного корня, а не для таблицы. Это означает - если сущность не должна существовать одна (то есть - если у вас есть Registrant, который участвует в конкретном Registration) - это просто сущность, ей не нужен репозиторий, она должна обновляться / создаваться / извлекаться через репозиторий совокупности корень ему принадлежит.

Конечно - во многих случаях этот метод уменьшения количества репозиториев (на самом деле - это больше метод структурирования вашей модели домена) не может быть применен, потому что каждый объект должен быть совокупным корнем (что сильно зависит от вашего домена, Могу только догадываться вслепую). В вашем примере - License кажется совокупным корнем, потому что вам нужно иметь возможность проверять их без контекста объекта Registration.

Но это не ограничивает нас каскадными репозиториями (Registration репозиторий может ссылаться на License репозиторий, если это необходимо). Это не ограничивает нас ссылками на репозиторий License (предпочтительно - через IoC) непосредственно из объекта Registration.

Просто постарайтесь не доводить свой дизайн до усложнений, связанных с технологиями, или непонимания чего-либо. Группировать репозитории в ServiceX только потому, что вы не хотите создавать 2 репозитория, - не лучшая идея.

Гораздо лучше было бы дать ему собственное имя - RegistrationService, т.е.

Но в целом следует избегать сервисов - они часто становятся причиной, которая приводит к анемичной модели домена.

РЕДАКТИРОВАТЬ:
Начните использовать IoC. Это действительно облегчает внедрение зависимостей.
Вместо того, чтобы писать:

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

вы сможете написать:

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

P.s. Было бы лучше использовать так называемый общий локатор служб, но это всего лишь пример.

Одна вещь, которую я начал делать, чтобы решить эту проблему, - это фактически разрабатывать сервисы, которые обертывают 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 есть определенные вызовы.

Не отвечает на вопрос о СУХОМ, хотя не думаю.

Вот пример общей реализации репозитория с использованием FluentNHibernate. Он способен сохранять любой класс, для которого вы написали картограф. Он даже способен сгенерировать вашу базу данных на основе классов сопоставления.

Я предлагаю вам взглянуть на Sharp Architecture. Они предлагают использовать один репозиторий для каждой сущности. В настоящее время я использую его в своем проекте и очень доволен результатами.

Шаблон репозитория - плохой шаблон проектирования. Я работаю со многими старыми проектами .Net, и этот шаблон обычно вызывает ошибки «Распределенные транзакции», «Частичный откат» и «Исчерпание пула подключений», которых можно было избежать. Проблема в том, что шаблон пытается обрабатывать соединения и транзакции изнутри, но они должны обрабатываться на уровне контроллера. Также EntityFramework уже абстрагирует большую часть логики. Я бы предложил использовать шаблон Service вместо повторного использования общего кода.