Терминология: MVC в вебе

[Фанат]

Встречает как-то как-то Боромир хоббита, гнома, орка и тролля.
- вы кто такие?
- мы хоббиты, просто из разных переводов!

Нету, наверное, другой такой столь удивительной технологии, как MVC.
При том, что большая часть девелоперов утверждает, что исправно использует сию баснословную парадигму, представления их о ней разнятся больше, чем представления средневековых учоных о лунной поверьхности.
Для большинства пыхохомячков MVC - это фронт-контроллер, синоним рерайта - почти всегда на вопрос о рерайте увидишь на форуме ответ в стиле "используй MVC!"
Для кого-то это приложение к фреймворку, и отличить, где собственно MVC, а где собственные заморочки фреймворка - очень затруднительно.
Кто-то пытается реализовать каноническую схему с одним контроллером, одной моделью и одним вью.
Кто-то пытается делить эти составные части на куски, но не все.

И в довершение каждый(!) ещё и толкует эти три термина по-своему!
Если контроллер понимают все более-менее одинаково, то с моделью и вью - полный разброд и шатание.

Давайте, однако, делиться своим пониманием парадигмы, а точнее - собственными реальными реализациями!

Заявления в стиле "ты лох, все давно знают, один ты тормоз, для тупых вот ссылка на 1000-страничный мануал по ZF" - уж извините, будут удаляться.
Ссылки, на безводное толковое описание, снабжённые собственными комментариями - приветствуются.

 

[Фанат]

Мои текущие представления о парадигме состоят в том, что по схеме MVC строится скорее не всё приложение целиком, а каждый отдельный модуль.
Соответственно, на уровне приложения мы имеем

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

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

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

Например, приходит запрос вида /news/fashion/page/2/
Роутер наш ищет метод fashion в модуле ньюс, не находит, и запускает поэтому дефолтный экшен list (дефолтность берется из глобальной "модели"), оставляя все остальные фильтры нетронутыми.
Экшен лист просматривает фильтры, понимает, что page/2 это пагинатор, а fashion - тег.
Используя эти параметры, запрашивает у модели данные.
Получив - форматирует их и возвращает ядру, которое запускает вью

 

[ksnk]

Если контроллер понимают все более-менее одинаково,

Это как это?

Модель - некая операция, возвращающая данные. Результатом работы операции будет единая сущтьность - массив или объект с этими самыми данными. По дороге модель имеет право в некоем глобальном объекте (регистри) оставить некие следы своей жизнедеятельности. Для удобства и mvc-правоверности модель оформляют отдельным объектом.
View - это некая операция, которая по данным, выданным нам моделью строит их графическое представление. Возможно, при этом оно (view) использует данные глобального объекта (регистри). Для правоверности - view оформляется в виде отдельного объекта.
Все остальное - это контроллер в терминах MVC.

 

[Духовность™]

Я дам ссылку на подраздел в википедии, т.к. я его писал: http://ru.wikipedia.org/wiki/Model-View-Controller#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.80_.D0.BA.D0.BE.D0.BD.D1.82.D1.80.D0.BE.D0.BB.D0.BB.D0.B5.D1.80.D0.B0_MVC_.D0.B2_.D1.80.D0.B0.D0.BC.D0.BA.D0.B0.D1.85_PHP5

Если кратко:
Контроллер - это обработчик, который имеет некоторый код, отвечающий за дальнейшее поведение программы при запросе.
Допустим, у нас есть контроллер, который отвечает за вывод данных пользователя.
Минимальная обязанность контроллера:
- проверить присутствие ID, проверить его "на число". Если проверка провалилась - что-то сделать, например, произвести переадресацию.
- запустить МОДЕЛЬ, которая возвратит данные или что-то сделает.
- предать полученные от модели данные в ВИД.

МОДЕЛЬ - это такой код, который является самой сутью приложения. Это мозги, кишки и скелет предметной области. Это объекты данных, это классы с вычислениями и т.п.
Требования к модели:
- Модель может составлять 90% кода проекта.
- Модель ничего не знает о виде и о том, как данные модели будут выведены, куда и в каком размере
- Модель не знает кто и откуда её вызывает, фактически модель бесправна и "тупа".

ВИД - в рамках php - это что-то вроде класса, в который мы собираем данные, полученные в процессе выполнения программы и запускающего шаблонизацию.

 

[AmdY]

У меня очень простое понимание MVC - приложение нужно делить на отдельные обработчики, которые минимально зависят друг от друга. Чётких определений этих обработчиков нет и быть не может, так как в зависимости от ситуации их компетенция может меняться в ту или иную сторону.

У нас на проекте которому 8 лет есть как минимум 3 подхода к MVC в разных модулях, несколько реализаций виьх, 2 больших решения к построению форм, даже поисковая форма это отдельный компонент с двумя разными реализациями. При работе приходится переключать внутренне понимание подходов и следовать заданному в модуле вектору.
При этом среди всего этого добра нет серебрянной пули, всё паршиво, но работает и приносит компании большие деньги.

p.s. Сейчас готовится новый Zend Framework, там коренным образом переделывают MVC и приходят к помеси MVC-AOP. Мне очень даже импонирует идея.

 

[флоппик]

 

[varan]

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

 

[Mols]

Парни... ептель.
MVC - это шаблон проектирования (кому так легче - парадигма).
Это абстрактное итить колотить решение.
Абстрактное.
Имеет перед собой более менее конкретную цель - разделение кода на логически обособленные слои и обеспечение минимальной связанности между этими слоями.
И, внимание !
Нет абсолютно ничего страшного в том, что абстрактное решение имеет несколько(сколь угодно много) различных имплементаций.

Код постить лень.
И свои велосипеды были и фреймворки юзал.
ИМХО надо просто знать для чего этот паттерн и юзать то, что есть.
З.Ы.
А вопрос какой код в какой слой определить возникает довольно часто.
Думать придётся по любому))) Абсолютно исчерпывающих правил нет.

 

[Фанат]

Это абстрактное итить колотить решение.

Это всё хорошо, но есть два вопроса.
1. Всё-таки, интересно посмотреть на то, как разные люди реализуют на практике эту итить-колотить теоретическую парадигму.
То есть, понятно, что единого решения нет и не должно быть.
Тем интереснее смотреть на имеющиеся.
2. Как выяснилось, существуют фатальные разночтения в терминологии. и хотя бы её, мне кажется. можно привести к более-менее одному знаменателю

 

[melo]

Для меня простое и классическое MVC - это:
1. Одна точка входа в приложение, которой обычно является index.php
2. Парсинг входных параметров и подключение соответствующего контроллера, который является частью какого-то модуля. Тут мы можем дополнять пропущенные значения, либо отсылать на 404.
3. Контроллер имеет метод, который мы вызываем на основе входных данных, в этом методе мы можем ничего не делать, можем подключать модель, брать из неё данные, можем записывать их в шаблон.
4. Модель, набор методов, которые каким угодно способом работают с бд.
5. Вид - это темплейт, которые содержит только хтмл, и примитивную логику. Не бизнес логику.

Мы можем реализовать систему, работающую по схеме: одна страница - один контроллер. Но на практике, нам приходится реализовывать схемы с множеством контроллеров. Получается что-то наподобие иерархической системы контроллеров, которые накапливают вывод и в конце выдают в браузер общий результат работы.

 

[A1x]

у меня такие размышления - можно выделить три момента в работе веб-приложения:

1. выбор действия - анализ uri, возможно проверка и получение данных модели
2. действие - работа с данными (моделью), построение отображения (view)
3. вывод отображения

проблема терминологии MVC в мутности понятия "контроллер" - фактически он выступает в двух или трех лицах - это Front Controller (или Router) на этапе 1 и Page Controller и/или View Controller на этапе 2.

тогда как в существующих реализациях MVC то что называют контроллером это только Page/View Controller

 

[grigori]

Мне кажется, что контроллер еще делает анализ контекста вызова.

Пример: из шаблона вызывается хелпер/виджет/плагин, который выводит форму для комментариев.
Комментировать можно страницы разных видов, данные для которых хранятся в разных таблицах, и соответственно id этих сущностей не уникален.
Т.е. в этой форме надо указать вид комментируемой сущности, а определение вида - это работа контроллера.