Организация классов с использованием шаблона проектирования хранилища

Question

Я начал обновление одного из наших внутренних программных приложений, написанных в веб-формах ASP.NET, и перешел на ASP.NET MVC.

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

У меня есть следующие объекты:

• Тема
• Тема Комментарии (Тема может иметь несколько комментариев)
• Ревизии тема (Каждый раз, когда тема редактируется, пересмотр записывается)
• Подписка на темы (позволяет пользователям подписаться на изменения для определенного Тема)

В настоящее время у меня есть интерфейс для ITopicRepository и класс под названием TopicRepository, который обрабатывает все основные CRUD для темы. Сейчас я готов добавить код для комментариев, изменений и подписки.

Мне интересно, ВСЕ ли это вписываются в TopicRepository ИЛИ я создаю репозиторий для каждого из объектов, например, ThreadRevisionRepository и т. Д.

Answer 1

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

Большинство образцов, которые вы увидите для ASP.Net MVC, являются лишь небольшим шагом за пределы ActiveRecord, используя объекты репозитория на сущность. То, что они на самом деле реализуют, является своего рода табличным шлюзом данных и использует слово «репозиторий» вместо «шлюз».

Нет ничего плохого в этом отношении для многих приложений, и я вообще начал создавать новые приложения с тем же подходом, пока не смогу доказать, что мне нужно что-то другое. Тем не менее, принципы разработки Driven Design, из которых, как правило, заимствована идея репозитория, должны были бы идентифицировать Aggregate Roots и консолидировать доступ к данным для этих дочерних объектов через репозиторий суммарного корня.Это позволяет размещать границы вокруг изменений состояния в вашем хранилище данных и, кроме всего прочего, может помочь в совершении транзакционных изменений.

Отредактировано для добавления: В вашем примере представляется маловероятным, что вы изменили бы любой из этих дочерних объектов изолированно от родителя, поэтому у меня возникнет соблазн сказать, что «тема» представляет собой совокупный корень для ваш домен.

Answer 2

На мой взгляд, она должна идти в его собственном хранилище ...

Edit:

посредничает между доменом и данными отображения слоев, используя интерфейс сбора, как для доступа к домену объектов.

Repository Pattern

Это позволяет, если ваш интерес использовать общий репозиторий, как this example, что означает меньше кода ...

Answer 3

Глядя на NerdDinner tutorial, они, кажется, идут с respository в сущности.

Когда вы думаете об этом, это имеет смысл. Будут случаи, когда вы хотите иметь контроль над загрузкой суб-объектов.

Answer 4

Я думаю, это зависит от того, как вы собираетесь получать доступ к своим данным. Изменения вы всегда будете смотреть на тему с ее комментариями и наоборот для подобных (32) комментариев элементов пользовательского интерфейса.

Поэтому ваша тема становится Aggregate Root, и вам нужен только один репозиторий для этого подхода.

Одна вещь, которую следует учитывать, если у вас много мелких вещей, вам нужен только очень узкий доступ к списку параметров для выпадающего меню, которое вам действительно не нужно для полного выпадающего хранилища. Проблема заключается в том, что после того, как вы пройдете 20 объектов, вы получите 20 интерфейсов и 20 репозиториев, о которых стоит подумать в своем решении.

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

Наконец, вы на этапе вашего проекта были проблемами с производительностью, которые не имеют значения, и получение всего графа объектов для «темы», вероятно, не так уж плохо. Держите вещи простыми, если вы используете ORM mapper, он должен уметь обрабатывать задание темы каждый раз, когда вам это нужно, при этом все его дочерние сущности лениво загружаются.