Я начинаю с ДДД. Меня немного смущает взаимодействие между несколькими уровнями, участвующими в приложении DDD.
Могу ли я вызвать свои репозитории из моего уровня представления? Если нет, нужно ли мне копировать функции CRUD, предоставляемые репозиториями на моем сервисном уровне (который, конечно, в свою очередь будет использовать репозиторий для этих функций)? Как лучше всего это сделать?
Что именно вы подразумеваете под уровнем представления? Если вы имеете в виду Контроллер/Ведущий, то все в порядке. Эмпирическое правило, которое я использовал, заключается в том, что если действие контроллера состоит из 4 строк кода или более, я должен рассмотреть рефакторинг для класса службы приложения, но все же - оба находятся на уровне приложения, и вы, безусловно, можете использовать там репозитории.
То, как вы сформулировали свой вопрос - и я, безусловно, мог неправильно это истолковать - звучало подозрительно, как будто вы думали сослаться на репозиторий со своего представления или кода программной части. В таком случае я бы сказал нет! нет! нет!
Безусловно, вы можете вызвать репозиторий из уровня представления. Мой единственный совет состоит в том, чтобы ваш уровень представления зависел от абстракции репозитория, а не от реализации, т. е. UserSession зависит от интерфейса IPersonRepository, а не от класса PersonRepository. Это не только хорошее разделение задач, но и упрощает тестирование.
Действуй!
Обычно я использую сервисный уровень, но использование вашего репозитория не повредит.
Как говорит Кевин, использование контроллера или ведущего дает вам много преимуществ.
К ним относится четкое разделение проблем, а также возможность тестирования.
Лично я в настройках ASP.NET предпочел бы «пассивный просмотр» Fowler .
Вы просто проектируете свои страничные контракты как интерфейсы, которые имеют конкретные реализации в виде веб-форм, а затем вы просто заглушаете/издеваетесь над ними при тестировании своих докладчиков.
Единственный недостаток, который приходит на ум, заключается в том, что вы получаете больше кода, чем в «традиционном» решении для веб-форм.
