Как контроллеры MVC вызывают несколько разных сущностей (компонентов, элементов, модулей)?

#веб_программирование #mvc #проектирование #php

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

Ответы

Ответ 1

Класическое mvc это когда представление по событию модели берет из неё положенное
интерфейсом, диспатчит контроллеру, а контроллер меняет модель. Стоит заострить внимание,
что контроллер не меняет представление вообще ( хотя в классике это ДОПУСКАЕТСЯ ),
а модель меняет так, что решение меняться или нет остается за моделью. И такая модель
называется "активной" и при ней контроллер "тонким", что является единственно верным
вариантом. ВСЁ!
Остальное это неправильно и ложно. Но чья-то глупость распространилась так, что даже
гуру не верят в первоисточник, хотя wiki и "gof" об это говорят прямо (и причиной такой
mvc-ериси, как я считаю, стало опускание из контекста статьи контроллера).
Обновление
Контроллер служит связующим звеном между представлением и модель. Но дело в том,
что в wiki и всяких статейках приводятся (если и правильные реализации) минимальные
примеры, которые в жизни не существуют. И ещё уясните одну маленькую и ускользающую
от всех деталь - представление не имеет ссылку на модель, представление имеет ссылку
на реализацию интерфейса. То есть, по ооп, структура строится на интерфейсах, модель
это абстракция, а не живой объект. И когда все слюнями плюются и говорят, что представление
имея ссылку на модель, нарушает концепцию о разделении логики от отображения, то просто
говорящие не углублялись в mvc сильно, а используют навязываемые фраймворки, которые
делают люди, но их концепцию обожествляют и выставляют эталоном.


Ответ 2

MVC была разработана в 1979 году, когда дела шли немного по-другому (меня тогда еще
не было на этом свете, но, подозреваю, каждое окно ограничивалось ровно одной функцией),
и предназначалась она не для веба. MVC используют просто потому, что она позволяет
избавиться от загаживания кода, следуя простому паттерну, и многие вещи делаются в
обход парадигмы, например, каждый виджет (например, меню страниц) должен был бы получить
данные от контроллера, но наверняка подтягивает их сам из модели. Скажем так, это нестрогое MVC.
HMVC и мне импонирует больше MVC.
"предназначалась она не для веба" = не то чтобы она плохо подходит вебу, просто когда
концепция была озвучена, никто и не думал, подойдет ли это для php-фреймворка.


Ответ 3

Ну, насколько я понимаю: при заходе на страничку контроллер получает набор инструкций,
(вывести меню, вывести контент и т.д.), он посылает эти инструкции по своим модулям,
те, в свою очередь, обрабатывают инстукции, из вьювок берут инфу о том, КАК нужно вывести,
и выводят каждый по отдельности.
Но чаще всего все пишут так: контроллер получает функции, и контроллер САМ работает
с модулями и вьюхами, т.е. модуль выступает в роли класса определенной сущности, где
с помощью методов контроллер получает необходимую инфу, сам загружает вьюху и сам их
соединяет.