Проектное решение шаблона репозитория MVC
Я имею asp приложение .net MVC и недавно начал реализовывать шаблон репозитория с сервисным слоем проверки, во многом как это.
Я создавал один репозиторий/сервис для каждой модели, которую я создаю. Это излишество? Вместо этого я должен создать один репозиторий/сервис для каждой логической сферы бизнеса, которая обеспечивает CRUD для многих различных моделей?
Мне кажется, что я или создаю помехи дереву проекта многими файлами или создаю помехи классу многими методами. 6 один путей полдюжины другой. Можно ли думать о каких-либо хороших аргументах так или иначе?
2 ответа
Как правило, если вы используете «настоящий» шаблон репозитория, в отличие от других уровней сохраняемости (например, ActiveRecord или DAO), вы должны стремиться идентифицировать агрегаты вашего домена и создать один репозиторий для каждого агрегата.
Что это значит? Что ж, это во многом зависит от вашего приложения, но обычно есть объекты, которые естественным образом являются «родителями» других объектов или являются частью связанной транзакции.
Я думаю, что каноническим примером является система электронной торговли, в которой у вас есть концепция заказа, а в заказе у вас есть строки заказа, каждая строка заказа - это какой-то продукт, количество и так далее.
В этом случае объект Order является одним из агрегированных корней системы, и создается OrderRepository.
В этом случае следует помнить, что существует некоторая связь (подразумеваемая или нет) между заказом и его строками заказа и так далее.Таким образом, части C-UD «CRUD» в репозитории, как правило, должны быть только одним методом каждая, и обычно должны просто принимать экземпляр этого совокупного корневого объекта и работать с ним (например, repo.Save (order)). Могут быть и другие возможные параметры, но это зависит от вашего impl.
Фактически, вы часто можете решить большую часть части C-UD с наследованием (т.е. создать RepositoryBase, который реализует их, используя некоторую известную логику о том, что происходит для вашей конкретной схемы сохранения).
Итак, остается R-часть CRUD. В этом случае вы можете получить массу методов запроса (GetById; GetByName; GetByCustomerName и т. Д.), Если вы выберете маршрут метода запроса. Некоторые люди предпочитают, особенно для простых приложений, предоставлять интерфейс на основе linq (например, IQueryable GetAll ()), к которому затем могут применяться предложения Where. YMMV в зависимости от вашей базовой настойчивости, но это хороший шанс для простых приложений, особенно. если вы ожидаете, что ваш поставщик постоянства будет поддерживать linq напрямую.
Наконец, многие люди фактически отделяют часть запроса с помощью той или иной реализации шаблона разделения ответственности командного запроса, в котором говорится, что интерфейсы для сохранения и запросов должны быть разными. В этом случае у вас будет репо, в котором есть только базовые операции CRUD (GetById, GetAll, Save, Delete) и какой-то другой класс, который запрашивает вещи в зависимости от намерений вашего приложения.
Надеюсь, что это поможет.
Пол
Это вопрос, который я недавно задал, и, несмотря на несколько хороших ответов, в конце концов пришел к собственному выводу - правильного ответа нет. Это не означает, что нет неправильного ответа, на самом деле существует множество неправильных ответов, но правильный ответ всегда будет зависеть от вашего личного случая.
Я получил четыре репозитория и частичное расширение класса моей модели сущностей EF4 для стандартных действий CRUD для дочерних сущностей (адреса, номера телефонов, коды состояния и т. Д.), Поэтому они были реализованы один раз и доступны во всех репозиториях. .Тем не менее, я все еще дорабатываю его по ходу дела, поэтому, возможно, я еще не нашел лучшего решения.
Я бы посоветовал попробовать это и посмотреть, подходит ли он, и посмотреть, кажется ли это правильным. Обычно, если не кажется правильным, то все равно это неправильно.
Если вы действительно боитесь загромождать дерево исходного кода, вы всегда можете выделить часть модели в ее собственную библиотеку и включить ее в качестве зависимости.