MVC: Lean контроллер против внедрения хранилища?

Question

В идеале контроллер должен быть свободен от логики домена?
Как это соотносится с введением в него класса репозитория, как во время обеда с ботаником?

Если вы один из тех, кто этого не делаетвнедрить репозиторий в контроллер, как вы называете классы уровня приложения / домена, которые содержат код, который ссылается на средства доступа к репозиторию и работает с классами модели?Или ты разделил это дальше?Как?

Добавлено к вопросу:

По приведенному выше вопросу, не могли бы вы рассмотреть эти три сценария:

1. Извлечение модели и возвращение представления
2. Получение редактирования формы для проверки и сохранения в базе данных
3. Обработка заказа

Надеюсь, это дополнение может прояснить вопростак что мы можем ссылаться на распространенные типы сценариев.

Answer 1

Мы внедряем репозиторий интерфейсов в наши контроллеры, поэтому наш контроллер не заботится о реализации логики домена.Наш контейнер IoC заботится о том, чтобы определить, какой класс использовать в качестве реализации для каждого интерфейса репозитория.

Answer 2

логика доступа к данным! = Логика домена

Впрыск контроллера с репозиторием - это нормально, если вы пытаетесь выполнить DDD.

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

---

Мне было бы очень интересно увидеть приложение MVC, которое не получало доступ к уровню репозитория / службы / dal из контроллера. ;)