MVC: что лучше, один большой репозиторий на дБ или один на предприятие?
На этот раз у меня есть более философский вопрос.
Большинство учебных руководств/книг MVC, кажется, предлагает ограничить объем одного репозитория к одному аспекту модели и открыть несколько репозиториев для покрытия всех образцовых классов. (Например: ProjectRep, UserRep, ImageRep, все отображающиеся на тот же дб в конечном счете.)
Я вижу, как это сделало бы unittesting более простой, но я не могу вообразить, как это работало бы в реальном мире, где большинство объектов имеет отношения друг между другом. В конце я всегда оказываюсь с одним гигантским классом репозитория на соединение с БД и одинаково arkward FakeRepository для unittesting.
Так, каково Ваше мнение? Я должен попытаться тяжелее разделить репозитории? Даже имеет значение, если ProductRep обращается к данным в UserRep и наоборот через PurchaseHistory? Как различные представители удостоверились бы, что они не запирают друг друга при доступе к единственному дб?
Спасибо, Duffy
2 ответа
Это работает в реальном мире, потому что под капотом репозиториев находится один движок. Это может быть ORM вроде NHibernate или ваше собственное решение. Этот механизм знает, как связывать объекты, блокировать базу данных, запросы кеширования и т. Д. Но бизнес-код не должен знать эти детали инфраструктуры.
То, что вы фактически делаете, когда у вас остается один гигантский репозиторий, - это вместо этого подвергать этот единственный движок реальному миру. Таким образом, вы вносите путаницу в код своего домена с деталями, специфичными для движка, которые в противном случае скрыты за интерфейсами репозитория.
S # arp Architecture - очень хорошая иллюстрация того, как реализованы и работают репозитории, о которых говорит Джош. Также прочтите статью о передовых методах работы NHibernate , которая объясняет большую часть предыстории S # arp.
И, честно говоря, я не могу представить, как ваше гигантское хранилище работает в реальном мире. Потому что сама идея выглядит плохой и неподдерживаемой.
Я обнаружил, что, используя универсальные шаблоны и интерфейс, вы можете избежать кодирования множества отдельных репозиториев. Если ваша модель предметной области хорошо структурирована, вы часто можете перемещаться по графам объектов, используя объекты предметной области, а не другое хранилище.
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
}
Это упрощает написание модульных тестов.