MVC на сервере не бывает -7


image MVC в наше время не использует только ленивый. Да и ленивый тоже, использует CMS которая реализует этот подход.
Но MVC ли это?

Архитектура именуемая MVC появилась в исследовательской лаборатории Xerox PARC, при разработке программ с графическим пользовательским интерфейсом (ГПИ). Стоит отметить что программы с ГПИ появились там же, и появившись, сразу же явили миру программирования новую проблему. Дело в том, что ГПИ, в отличие от интерфейса командной строки, отображает множество разной информации, отдельные части которой могут быть связаны и самое главное — позволяет с этой информацией взаимодействовать.

При взаимодействии пользователя с данными, они могут измениться, а это значит что могут измениться и связанные с ними данные. Например, одна и та же строка показывается в текстовом поле и в заголовке окна. Переписываем строку — заголовок должен измениться. Решение «в лоб»: когда мы понимаем что строка в текстовом поле изменилась, мы меняем строку в заголовке. Но что если одни и те же данные показываются в пяти разных местах (данные имеют пять представлений), в каждом из которых они могут измениться? Тогда придётся в каждом обработчике события изменения данных писать код, который обновляет четыре другие представления, в которых отображаются данные. Если же что-то изменится хоть в одном представлении, то вносить правки придётся во все обработчики. Код получается слишком связанным.

Для решения этой проблемы и была придумана архитектура MVC.

Суть решения:
От кода, который изменяет представление при изменении данных никуда не деться. Он должен быть. Но в одном экземпляре. Значит его надо выделить в функцию. И эту функцию вызывать из всех обработчиков. Но постойте. Слова «при изменении данных» явно дают понять, что нам неважно какое событие произошло. Значит можно вызов функций обновления представлений тоже вынести в функцию, которая будет вызываться при любом событии изменяющем данные. В итоге код обновляющий представление сам по себе, а для добавления нового представления этих же данных, достаточно добавить вызов функции в функцию изменения данных.

Программисты. а точнее исследователи из Xerox PARC любили ООП. А значит и любили то, что я называю «подъём управления» — перенос решения о вызове некоторого кода вверх по потоку управления. В основном это делается через передачу объекта, у которого потом будет вызван метод. Вместо того, чтобы делать условие в функции, можно сделать условие перед вызовом функции, в зависимости от него создать один или другой объект, и вызвать функцию, передав туда получившийся объект в виде аргумента. Что это даёт? А то, что можно будет изменить поведение функции, передавая в неё разные объекты. Сама же функция не будет изменена.

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

Это и есть классическая MV* архитектура. Насчёт контроллера ещё можно поспорить, но во всех вариантах есть данные, представления и изменение этих представлений при изменении данных.

Что в итоге: MVC решает проблему сильной связности кода, позволяя разделить модель и представления с помощью применения некоторой архитектуры.

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

UPD: здесь под веб приложениями я понимаю такие приложения, всё мнимое MVC которых сосредоточено на сервере. Например вот такая простая MVC система на PHP5

Но постойте. Грамотное применение ООП в любом случае нам даст систему, разделённую на слабо связанные части.
В веб приложениях вообще нет событий. Протокол HTTP обязывает нас убивать приложение после ответа на запрос, или делать вид что мы его убили. Так что единственным событием веб приложения является его запуск с некоторым набором параметров.

А если нет событий, то и представления обновлять не надо. Они и так отрисуются при создании.

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

UPD: jigpuzzled указал на то что подобное отдельное название для серверной архитектуры уже существует: Action-Domain-Responder

Нужно ли для серверного MVC другое название, или же различия несущественны и никого не путают?

Проголосовало 183 человека. Воздержался 101 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.




К сожалению, не доступен сервер mySQL