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

Question

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

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

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

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

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

Мне интересно, ВСЕ ли это входит в TopicRepository ИЛИ я создаю хранилище для каждой из сущностей, например TopicRevisionRepository и т. Д.

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

Глядя на учебник NerdDinner , они, похоже, идут с репозиторием для каждой сущности.

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

Answer 4

По-моему, это должно войти в собственный репозиторий ...

Edit:

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

Шаблон репозитория

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