MVC: просмотр и моделирование взаимодействия в отношении доступа к данным и т. Д.

Question

Должна ли модель быть просто структурой данных? Где находятся сервисы (доступ к данным, бизнес-логика) в MVC?

Предположим, у меня есть представление, которое показывает список заказов клиентов. У меня есть класс контроллера, который обрабатывает щелчки на элементах управления представлением (кнопки и т. Д.).

Должен ли контроллер сбросить код доступа к данным? Подумайте, нажмите кнопку, перезагрузите запрос заказа. Или это вообще должно пройти через слой модели?

Любой пример кода был бы великолепен!

Answer 1

Обычно я реализую MVC следующим образом:

Просмотр - получает данные от контроллера и генерирует выходные данные. Обычно здесь должна отображаться только логика отображения. Например, если вы хотите взять существующий сайт и создать его версию для мобильных устройств / iPhone, вы можете сделать это, просто заменив представления (при условии, что вам нужна та же функциональность).

Модель - Оберните доступ к данным в моделях. В моих приложениях все SQL живут на уровне модели, прямой доступ к данным в представлении или контроллере запрещен. Как указывает Эли в другом ответе, идея в том, чтобы (хотя бы частично) изолировать ваши контроллеры / представления от изменений в структуре базы данных. Модели также являются хорошим местом для реализации логики, такой как обновление даты «последнего изменения» при изменении поля. Если основным источником данных для вашего приложения является внешний веб-сервис, подумайте, стоит ли включать его в класс модели.

Контроллеры - Используются для склейки моделей и видов. Реализуйте здесь логику приложения, проверяйте формы, передавайте данные из моделей в представления и т. Д.

Например, в моих приложениях при запросе страницы контроллер извлекает все данные, которые требуются от моделей, и передает их в представление для создания страницы, которую видит пользователь. Если эта страница была формой, форма может быть отправлена, контроллер выполняет проверку, создает необходимую модель и использует ее для сохранения данных.

Если вы будете следовать этому методу, в конечном итоге Модели будут достаточно универсальными и пригодными для повторного использования. Ваши контроллеры имеют управляемый размер и сложность, потому что доступ к данным и их отображение были удалены для моделей и представлений соответственно, и ваши представления должны быть достаточно простыми, чтобы дизайнер (с небольшим обучением) мог их понять.

Answer 2

Я бы не стал вводить код доступа к данным в контроллер.

Чтобы опираться на то, что уже было сказано, важно подумать о наслоении ВНУТРИ слоев. Например, у вас, скорее всего, будет несколько слоев в самой модели - уровень доступа к данным, который выполняет любой доступ к ORM и базе данных, и более абстрактный уровень, представляющий бизнес-объекты (без знания того, как получить доступ к их данным).

Это позволит вам более легко тестировать компоненты вашей системы, поскольку она поддерживает моделирование.

Answer 3

Мне нравится сохранять "контракты" или интерфейсы для сохранения модели или доступа к сервису на уровне домена (модели). Я помещаю реализации доступа к данным или вызовов служб в другой слой.

Контроллеры создаются с помощью конструкторов, которые принимают интерфейсы для служб, например, ISomeService, как параметры. Сами контроллеры не знают, как реализованы сервисные уровни, но они могут получить к ним доступ. Тогда я могу легко заменить SqlSomeService или InMemorySomeService.

Я также был довольно доволен конкретной реализацией службы, которая использует репозиторий уровня домена (модели) в качестве параметра для своего конструктора. Например: ICatalogRepository с SqlServerCatalogRepositry: ICatalogRepository передается CatalogService (ICatalogRepository, ISomeOtherDependency).

Этот тип разделения проще с инфраструктурой внедрения зависимостей.

Answer 4

Представление будет передавать то, что должно происходить при щелчке в пользовательском интерфейсе, на уровень управления, который будет содержать ВСЕ бизнес-логики, и в свою очередь вызывать уровень модели, который будет выполнять только вызовы базы данных. Только уровень модели должен выполнять вызовы из базы данных, иначе вы не добьетесь цели шаблона проектирования MVC.

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