MVC: Что лучше: один большой репозиторий на дБ или один на бизнес-объект?

Question

На этот раз у меня есть более философский вопрос.

Большинство учебных пособий / книг по MVC, по-видимому, предлагают ограничить область действия одного репозитория одним аспектом модели и настроить несколько репозиториев, чтобы охватить все классы модели. (Например: ProjectRep, UserRep, ImageRep, все в конечном итоге отображаются на один и тот же БД.)

Я вижу, как это упростит тестирование юнитов, но я не представляю, как это будет работать в реальном мире, где большинство сущностей имеют отношения друг с другом. В конце концов, я всегда оказываюсь с одним гигантским классом репозитория на соединение с БД и столь же неудобным FakeRepository для тестирования юнитов.

Итак, что ты думаешь? Должен ли я стараться отделить хранилища? Имеет ли значение, что ProductRep ссылается на данные в UserRep, и наоборот, через PurchaseHistory? Как разные представители будут уверены, что они не блокируют друг друга при доступе к единой базе данных?

Спасибо, Duffy

Answer 1

Это работает в реальном мире, потому что под капотом хранилищ находится один движок. Это может быть ORM как NHibernate или ваше собственное решение. Этот механизм знает, как связывать объекты, блокировать базу данных, запросы кеша и т. Д. Но бизнес-код не должен знать этих подробностей инфраструктуры.

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

S # arp Architecture - очень хорошая иллюстрация того, как репозитории, о которых говорит Джош, реализованы и работают. Также прочитайте статью о лучших практиках NHibernate *, которая объясняет большую часть истории S # arp.

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

Answer 2

Я обнаружил, что с помощью обобщений и интерфейса вы можете избежать необходимости кодировать множество отдельных репозиториев. Если ваша доменная модель хорошо продумана, вы часто можете перемещаться по графам объектов, используя доменные объекты, а не другой репозиторий.

public class MyDomainObject : IEntity //IEntity is an arbitrary interface for base ents
{
     public int Id { get; set;}
     public List<DiffObj> NavigationProp { get; set;}
     //... and so on...
}

public interface IRepository<T> where T : IEntity, class, new()
{
     void Inert(T entity);
     T FindById(int id);
     //... and so on
}

Использование довольно простое, и с помощью IoC вы можете полностью отделить реализацию от остальной части вашего приложения:

public class MyBusinessClass
{
     private IRepository<SomeDomainObject> _aRepo;
     public MyBusinessClass(IREpository<SomeDomainObject> aRepo)
     {
          _aRepo = aRepo;
     }
     //...and so on
}

Это делает написание модульных тестов очень простым делом.