Один репозиторий на таблицу или один на функциональный раздел?
Я использую ASP.NET MVC 2 и C# с Платформой Объекта 4.0 для кодирования против нормализованной базы данных SQL Server. Часть моей структуры базы данных содержит таблицу записей с внешними ключами, касающимися подтаблиц, содержащих драйверы, автомобили, механизмы, шасси и т.д.
Я следую учебному руководству по Ужину Компьютерного фаната, которое открывает репозиторий на ужины, который достаточно справедлив. Я делаю один для драйверов, один для механизмов, один для автомобилей и так далее, или я делаю один большой для записей?
Который является наиболее успешной практикой для этого типа работы? Я все еще плохо знаком с этим методом кодирования.
4 ответа
Думаю, на самом деле для этого не существует единой "лучшей практики" - это зависит от вашего стиля кодирования и требований к вашему приложению. Вы определенно можете создать репозиторий для каждого типа сущности в своей системе - это будет работать нормально.
В вашем случае здесь я бы, вероятно, хотя бы подумал о создании репозитория для драйверов и, возможно, второго репозитория для автомобилей, двигателей, шасси (поскольку они относятся к одной и той же области знаний - они взаимосвязаны, они » принадлежат друг другу).
Но: конечно, если этот единый репозиторий для автомобилей, двигателей и шасси станет слишком раздуваемым, вы можете подумать о том, чтобы разбить его на три отдельных репозитория.
Я бы попытался найти баланс между количеством репозиториев - попытаться сгруппировать вместе то, что логически принадлежит друг другу - и количеством методов в этих репозиториях. Пять, десять методов - это нормально - если вы говорите о 20, 30 или 50 методах, ваш репозиторий может быть слишком большим и громоздким.
Это определенно архитектурное решение, и как таковое, на самом деле это не так много неопровержимых фактов, которыми можно было бы руководствоваться - это скорее «интуиция» и нечто вроде опыта. Если у вас еще нет необходимого опыта - выберите один подход, используйте его, а когда закончите, взгляните на него еще раз критическим взглядом и посмотрите: что сработало? Что насчет этого не сработало? а затем в своем следующем проекте попробуйте другой подход и поставьте под сомнение его обоснованность в конце проекта. Живи и учись!
Лично я считаю, что лучше всего создать отдельное хранилище для каждой таблицы.
Затем я создаю слой сервисов, где в одном классе я запускаю все команды для определенного действия (например, изменить уже существующую машину водителя на вновь добавленную). Уровень сервисов - это место, где я буду вызывать несколько хранилищ, если действие, которое мне нужно выполнить, содержит несколько взаимосвязанных объектов.
Я стараюсь сделать все возможное, чтобы мои хранилища были как можно более "глупыми", а все "умные" вещи помещаю в слой сервисов. Дополнительный слой сервисов также помогает мне избежать раздувания моих контроллеров.
Я использую общее (параметризованное) хранилище для каждой сущности. Это хранилище содержит основные функции 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.
Я обычно беру диаграмму базы данных и обрисовываю круги вокруг того, что я считаю более крупным устройством или системой.
Это дает мне что-то вроде «ProductSystem», «OrderSystem», «UserSystem», «PaymentSystem» в магазине.
Если системы становятся слишком большими, я делю их.
Если систем слишком мало, меня это не волнует: все равно все будет расти.
Если что-то каким-то образом принадлежит двум системам, я выбираю одну и больше не меняю ее, даже если на следующий день решение пошло не так: я знаю, что наступит день, когда я захочу снова это изменить.