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

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 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>.

Answer 4

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

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

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

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

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