Model-View-Controller: взаимодействует ли пользователь с View или с Controller? [закрыто]

Недавно я узнал о шаблоне проектирования MVC. Я учусь на книге Head First Design Pattern.

Согласно этой книге (если я правильно понимаю):

Модель - это большая часть логики и данных приложения.

Представление - это в основном графический интерфейс, который представляет модель визуально для пользователя.

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

Тем не менее, многие места в Интернете противоречат тому, что я понимаю из этой книги. Они утверждают, что обычно пользователь взаимодействует с контроллером, а не с представлением.

Какой из них является верным или более распространенным? Взаимодействует ли пользователь с контроллером напрямую или напрямую с представлением? Являются ли оба подхода приемлемыми? Что чаще встречается?

Пользователь взаимодействует с представлением , но представление должно сообщить действия контроллеру . Контроллер может обновить модель , но это не требуется при каждом / какие - либо изменения.

Описание, которое я предоставляю, основано на моем личном опыте реализации .NET в MVC. Ваша реализация может быть разной.

Контроллер , где действия обрабатываются, в основном бизнес - слой. Простой контроллер не сделает ничего, кроме как получить данные от Модели для подачи в Представление. Сложный контроллер будет выполнять все виды действий, вплоть до управления безопасностью, аутентификации, авторизации, регистрации и, возможно, многого другого.

View должен быть только отвечает за отображение информации таким образом , что пользователь может понять. Здесь могут быть некоторые пересечения как с Контроллером, так и с Моделью, поскольку такие вещи, как одностраничные приложения (SPA), будут иметь обратную связь для проверки данных для пользователя. Любые другие переходы сильно осуждаются.

Модель имеет дело с данными. Это включает в себя проверку данных (где это применимо). Хранение и поиск данных также обрабатываются на этом уровне.

ОБНОВИТЬ

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

MVC - это попытка создать шаблон проектирования Разделение проблем для разработки программного обеспечения. Он был в основном реализован в веб-приложениях (насколько мне известно).

View обрабатывает все взаимодействия с пользователем. Если ваш пользователь нажимает на кнопку, представление определяет, является ли щелчок взаимодействием с пользовательским интерфейсом или чем-то, что его не касается (взаимодействие с контроллером). Если кнопка выполняет что-то вроде копирования значений из одного поля в другое, ваша реализация определит, относится ли это к представлению View или контроллеру. Скорее всего, вы столкнетесь с этой проблемой только при работе с одностраничным приложением (SPA).

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

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

В Википедии есть статья о MVC .

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

Из обзора Microsoft MVC .

• Модели. Объекты модели - это части приложения, которые реализуют логику для предметной области приложения. Зачастую объекты модели извлекают и хранят состояние модели в базе данных. Например, объект Product может извлекать информацию из базы данных, работать с ней, а затем записывать обновленную информацию обратно в таблицу Products в базе данных SQL Server.

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

• Взгляды. Представления - это компоненты, которые отображают пользовательский интерфейс приложения. Как правило, этот пользовательский интерфейс создается из данных модели. Примером может служить представление редактирования таблицы «Продукты», в котором отображаются текстовые поля, раскрывающиеся списки и флажки в зависимости от текущего состояния объекта «Продукт».

• Контроллеры. Контроллеры - это компоненты, которые обрабатывают взаимодействие с пользователем, работают с моделью и, в конечном счете, выбирают представление для отображения, отображающее пользовательский интерфейс. В приложении MVC представление отображает только информацию; контроллер обрабатывает и реагирует на пользовательский ввод и взаимодействие. Например, контроллер обрабатывает значения строки запроса и передает эти значения в модель, которая, в свою очередь, может использовать эти значения для запроса базы данных.

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

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

Кроме того, не все приложения, даже веб-приложения MVC, имеют графический интерфейс. Вы можете взаимодействовать с контроллером через API - просто, url-routesнапример, в самом контроллере .

Контроллер должен быть местом , которое получает и Рукоятки запросов пользователей. Так что если вы каким-то образом обращаетесь к Модели напрямую из View - неважно, как, то это больше не MVC .

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

В музыкальном приложении на iPhone функцией высокого уровня является воспроизведение плейлиста. «Воспроизвести список воспроизведения» - это функция контроллера приложения.

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

Отзывы в каждом представлении также различны. Сири скажет вам, что играет ту музыку, которую вы просили. Музыкальное приложение покажет вам визуальную информацию о том, что оно воспроизводит плейлист.