Один репозиторий на таблицу или один на функциональный раздел?

Я использую ASP.NET MVC 2 и С# с Entity Framework 4.0 для кодирования нормализованной базы данных SQL Server. Часть моей структуры базы данных содержит таблицу записей с внешними ключами, относящуюся к подтаблицам, содержащим драйверы, автомобили, двигатели, шасси и т.д.

Я следую учебнику Nerd Dinner, который устанавливает репозиторий для ужинов, который достаточно справедлив. Я делаю это для драйверов, один для двигателей, один для автомобилей и т.д. Или я делаю один большой для записей?

Какая наилучшая практика для такого рода работ? Я все еще новичок в этом методе кодирования.

Ответ 1

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

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

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

Я попытался бы найти баланс между количеством репозиториев - попытаться объединить вместе то, что логически принадлежит вместе, - и количество методов в этих репозиториях. Пять, десять методов в порядке - если вы говорите 20, 30 или 50 методов, ваш репозиторий может быть слишком большим и громоздким.

Это, безусловно, архитектурное решение, и, как таковое, на самом деле они не очень много трудных фактов, которые помогут вам - это скорее "ощущение кишки" и опыт. Если у вас еще нет необходимого опыта - пойдите с одним подходом, используйте его, и когда вы закончите - посмотрите на это снова с критическим взглядом и посмотрите: что с этим работало? Что с этим не получилось? а затем в вашем следующем проекте, попробуйте другой подход и задайте вопрос о его действительности, также в конце проекта. Живи и учись!

Ответ 2

Лично я считаю, что лучше всего создать отдельный репозиторий для каждой таблицы.

Затем я создаю services layer, где в одном классе я буду запускать все команды для определенного действия (например, измените уже существующий автомобиль-водитель на недавно добавленный автомобиль). Уровень сервисов - это место, где я буду называть несколько репозиториев, если какое-либо действие, которое мне нужно сделать, содержит несколько взаимосвязанных объектов.

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

Ответ 3

Я использую общий (параметризованный) репозиторий для каждого объекта. Этот репозиторий содержит базовую функцию CRUD. Помимо этого, у меня есть сервис для каждой функциональности. Каждая служба создает необходимые репозитории. ObjectContext является общим для всех из них, и для каждого запроса есть один. Это мой интерфейс репозитория:

public interface IRepository<T>
{
    //Retrieves list of items in table
    IQueryable<T> List();
    IQueryable<T> List(params string[] includes);

    //Creates from detached item
    void Create(T item);
    void Delete(int id);
    T Get(int id);
    T Get(int id, params string[] includes);
    void SaveChanges();
}

У меня также есть общая реализация, которая длинна, но проста в реализации. Вам не нужно создавать класс репозитория для каждого типа, просто создайте экземпляр Repository<Type>.

Ответ 4

Я обычно беру диаграмму базы данных и рисую круги вокруг того, что я собираю больше единицы или системы.

Это дает мне что-то вроде "ProductSystem", "OrderSystem", "UserSystem", "PaymentSystem" в магазине.

Если системы становятся слишком большими, я их разделяю.

Если систем слишком мало, я не забочусь: все будет расти.

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