Model
И View
независимы друг от друга.
Не думайте об этом Controller
как о мозгах структуры MVC. Думайте об этом как о диспетчере, который обрабатывает запросы от браузера и отправляет их в Model
. Затем он берет данные из Model
и упаковывает их в виде шаблона , а затем отправляет их в View
.
Model
Является мозг в структуре MVC, и это, где вы должны положить ваши бизнес - правила. Бизнес-правила являются общими для нескольких контроллеров . Таким образом, контроллер документа и контроллер отчетов могут использовать модель пользователя, чтобы увидеть, кто имеет доступ к этим вещам. Вы не хотели бы повторять эти правила в обоих контроллерах.
View
Следует использовать шаблон HTML , чтобы представить данные определенным образом без источника данных. Он не должен быть тесно связан со схемой вашей базы данных. Чтобы показать заголовок документа, у вас должно быть представление, выводящее содержимое переменной шаблона с именем document_title
, и только Controller
знает, как была установлена эта переменная, и только Model
знает, почему этот документ имеет этот заголовок.
Первоначально MVC был определен для облегчения программирования настольных приложений. Представление подписывалось на события модели, обновляя представление при изменении модели. Контроллер просто переводил события пользовательского интерфейса (например, нажатие кнопки) в вызовы модели. Таким образом, контроллер и вид зависят от модели, но не зависят друг от друга. Модель не зависит от обоих. Это позволило нескольким представлениям и контроллерам работать на одной модели.
Архитектура "MVC", используемая для приложений web 1.0 (полное обновление страницы, без AJAX), несколько отличается. Веб-запрос отправляется на контроллер. Контроллер каким-то образом изменяет состояние модели, а затем отправляет одну или несколько моделей для визуализации представлением. Контроллер и вид зависят от модели, но контроллер также зависит от вида.
С приложениями web 2.0 мы возвращаемся к классической архитектуре MVC на стороне клиента . Модель, представление и контроллер находятся на стороне клиента как объекты Javascript. Контроллер переводит пользовательские события в действия модели. Действия модели могут приводить или не приводить к запросу AJAX на сервер. Опять же, представление подписывается на события модели и соответственно обновляет презентацию.
источник
Представление должно подписываться на изменения в модели. Существует богатство подписок, поскольку они могут быть подробными (показать изменения инвентаря для этого конкретного элемента) или общими (модель изменилась); представление может запросить модель в ответ на уведомление об изменении. Представление представляет желаемый набор элементов модели на экране, обновляя экран, как при обработке уведомлений об изменениях.
Контроллер должен выдвигать изменения в модели в зависимости от направления пользователя (например, ввод клавиатуры, команды мыши и меню).
Модель поддерживает модель и список подписок и должна уведомлять представления о применимых изменениях через свои подписки.
Также должен быть механизм для создания новых представлений и контроллеров (поскольку в MVC вы должны иметь возможность иметь два или более представлений одной и той же модели (это могут быть одинаковые представления (точки) или разные представления (точки)). Логически мы можем считать, что контроллер должен работать или иметь доступ к фабрике представления и контроллера (пары), которая может быть частью контроллера или другого компонента.
источник
Models
не сообщайViews
.Controllers
запроситеModel
изменения, а затемViews
выполните рендеринг, чтобы представить эти изменения.MVC больше похож на шаблон модульности. Его цель заключается в том, что всякий раз, когда вы хотите изменить макет пользовательского интерфейса (представление), вам не нужно изменять прикладную логику (контроллер) или внутреннюю обработку данных (модель).
Чтобы добиться этого, шаблон должен изолировать логику реализации каждого компонента MVC. Тем не менее, совершенно нормально, что компоненты знают интерфейсы друг друга .
Что я часто видел, так это то, что контроллер создает или вызывает модель и представление (таким образом, он знает их интерфейс), а модель или представление могут уведомлять контроллер в ответ (больше похоже на обратный вызов или шаблон наблюдателя). Важной частью является то, что контроллер не знает о структуре макета.
источник