Концепция
Курс статей, призванный рассказать новичку о том, как же на самом деле устроены такие страшные гиганты, как PHP MVC Фреймворки.
Курс ни в коем случае не претендует на звание «Всеобъемлющее пособие: „Сделай сам все то, что уже давно изобретено“», но поможет понять самым маленьким и только начинающим программистам мира веб, каким образом все это написано, да еще и работает. Но прежде чем загружать вас тоннами кода, необходимо разобраться с самим понятием MVC. Что это такое?
И вот, PHP профи уже не могут терпеть, не вставив: "Опять эта банальщина про азы, паттерны и прочее..." Успокойтесь, дорогие мои, не забывайте, что когда-то и вы не понимали половину того, что сейчас у вас вызывает неудержный смех, когда-то и вам приходилось сидеть с полными горем глазами после очередного "@include( );" и именно вы когда-то также не знали про повседневное "Модель-Представление-Контроллер". Поэтому давайте не будем глумиться над маленькими и только начинающими PHPшниками и позволим им почувствовать себя такими же художниками, или даже творцами своего кода, какими уже являетесь вы! А также не забывайте, дорогие гуру, что повторение — это мать учения.
Теперь о насущном. MVC — это всего лишь набор шаблонов проектирования(паттернов) вашего приложения, который подразумевает разделение вашего кода на три составляющие: Model(Модель), View(Представление), Controller(Контроллер). Проще говоря, MVC — это набор паттернов, позволяющий разделять может быть немного сумбурный код, на три независимые части — данные-вид-логика. Вот и все! Быть может вы уже давным-давно использовали такую архитектуру приложений, но не знали такого красивого названия. Но вот теперь вы можете немного распрямить плечи, надуть грудь колесом и задрать голову вверх со словами: "А я еще ничего!".
Но этого пока мало, следует немного разобраться с каждым из этих трех китов, поэтому давайте быстренько расчистим поле для представлений и развернем красочную и яркую картину мироздания MVC.
Итак, все что мы видим на странице, что можно потрогать, подвигать — это и есть представление. Оно может включать HTML разметку, скрипты, стили и прочие элементы пользовательского интерфейса. Но представление — это всего лишь сцена нашего театра, которая не имеет ничего более, чем красивое оформление. Да, сцена может быть красиво-оформленной, с хорошей постановкой света, декорации могут быть исполнены из потрясающих материалов, но без актеров она никому не нужна, она — шуршащая обертка.
Действующими лицами нашего театра выступают актеры, которые задолго до премьеры готовятся к своей роли; часами репетируют монологи, ставят речь, играют бровями. Актеры, как никто другой знают о своем персонаже все. Эти актеры и есть модели концепции MVC. У каждой модели есть набор данных, которыми можно оперировать, используя определенные методы.
Вот у нас есть сцена, есть актеры…, казалось бы, что еще нужно для увлекательного спектакля? Думаю, не хватает оригинального сценария. Сценаристы должны поставить все по своим местам: указать актерам где им играть, расставить гармонично декорации, поддерживать логическую цепочку событий на протяжении всего спектакля. Вы, наверное, уже поняли, что речь идет о контроллерах, на плечах которых лежит поддержка связи пользователя с приложением.
Вот теперь наш спектакль готов принимать аплодисменты зрителей, находящихся в восторге от постановки.
Но на практике, добиться такого эфемерного успеха получается не сразу, потому что концепция MVC выходит далеко за пределы этих трех букв, также далеко как реализация и применение этого набора шаблонов проектирования. По началу сложно связать трех китов, а тем более лаконично описать контроллер, который не был бы похож на отдельный модуль, содержащий бескрайнее число бизнес-логики, кучи проверок и валидаторов. Добавьте ко всему этому шепотку "умелых ручек" при работе с моделями, и вуаля — свежеиспеченный кусочек "толстого контроллера" подали к столу. В этом нет ничего страшного, и даже обидного, дорогие программисты, ведь если вы это увидели — значит вы растете!
Да и кстати, что же такое толстый контроллер? Термин "Толстый Тупой Уродливый Контроллер" появился в знак протеста против ярого желания программистов свалить все операции с данными на контроллеры. Да, да, взвалить неподражаемую игру актеров на плечи сценаристов.
Впервые опубликованная концепция MVC гласила, что контроллеры должны выступать в роли "прослойки между моделями, представлениями, и входными запросами". Однако, в последствие, в 90-х годах термины трех китов были переосмыслены, после выхода книги Ивара Якобсона "Object-Oriented Software Engineering: A Use Case Driven Approach", в которой была описана система, схожая с MVC, но реализующая абсолютно иные цели. Так, например, контроллер Якобсона должен выступать в роли контейнера для других объектов подсистемы. Чувствуете разницу? Поэтому, дорогие малыши, воспряньте духом, если по началу у вас будут получаться именно толстые контроллеры. Вы можете легко парировать ситуацию, сложив руки на груди со словами: "Я просто придерживаюсь другой концепции".
Тонкость и изящность хороших же контроллеров заключается именно в возможности выступать посредником между двумя другими китами.
Теперь вернемся к нашим "актерам". Представьте спектакль, в котором все актеры только занимаются тем, что читают заученные роли, не украшая эмоциями всю яркость счастья или глубину трагедии происходящих событий. Уныло, не правда ли?.. А теперь давайте представим модели, которые только этим и занимаются, что выступают в роли унылых актеров, не производя никаких действий с данными, кроме как реализуя примитивный доступ к базе данных. Как вы думаете, если кто-то возложит свои обязанности на другого, хорошо ли это будет?
Правильный ответ: ТТУК.
Необходимо просто подкормить модели до нужного состояние, вырезая лишнее из контроллеров, для того чтобы каждый занимался своим делом.
Что же касается декораций нашей сцены, дороги программисты, то давайте-ка на секунду вспомним реплику из доброго советского мультфильма: "Вы что же, за меня и есть будете?"… Не стоит перекладывать на представление разносольные работы, никак не связанные с его натурой.
Конечно же, дробить концепцию MVC можно с точностью до каждого применяющегося шаблона во фреймовике, главной же целью этой статьи было легкое и ненавязчивое донесение краткой, но красочной информации о такой повседневной концепции как Модель-Представление-Контроллер.
Комментарии (11)
igordata
02.06.2015 16:27Вводный курс в буквы как раз на geektimes очень красиво смотрелся бы, и даже возможно кому-то был бы полезен.
Fesor
03.06.2015 23:02-1маленькими и только начинающими PHPшниками
Ну да ну да, а заставлять их сходу осозновать MVC без должного фундамента это типа не глумление, с учетом того что классического MVC на сервере нет и не будет, не нужно оно там, это UI-ая архитектура. В контексте WEB-а намного важнее осознать концепцию request/response. А перед тем как рассказывать байки про MVC и т.д. нужно вообще рассказать о причинах, лежащих в разделении приложения на слои, слабой связанности и таких вещах как разделение ответственности. Без понимания зачем, рассказывать что это такое смысла нет вообще. Только хуже будет.
немного сумбурный код, на три независимые части
Не совсем на три независимые части, а на две. Модель, содержащая бизнес объекты и описывающая их взаимодействие (модель предметной области) и слой представления, который отвечает за перевод данных из формата модели, в формат, который хочет от нас клиент (человек или машина, в зависимости от того кто использует приложение). Контроллер в этом случае вводится как раз таки посредником между двумя слоями, что бы они действительно стали независимы друг от друга. На этом роль контроллера заканчивается и это именно та причина, по которой контроллеры должны быть максимально тонкими. Иначе у нас часть модели перетекает в контроллер, что сами понимаете, ломает всю красоту.
Словом… грусть печаль…SerafimArts
04.06.2015 19:02Не, ну на сервере почти что MVC с пассивными моделями (которые не воздействуют напрямую на вьюху) и применяется в основном. Отличие только в том, что экшн (нажатие кнопки, например) — прилетает в метод сквозь роутинг, а не благодаря айдишнику, например WinForms элемента с эвентом внутри. Разве нет? Почему на сервере нет MVC?
Arik
04.06.2015 09:04Иногда кажется, что чем больше узнаешь, тем сложнее программировать и пользоваться сторонними библиотеками, вырабатывается какой-то перфекционизм. Раньше простую гостевую делали по учебниками и статьям и было приятно, было в кайф, все было просто и понятно. Сейчас подключаешь либы ко всему и надеешься что все будет работать как надо, и не нужно будет лезть в исходники, чтоб не ужаснуться и не ловить себя на мысли переписать с нуля под себя; Чтоб открывая код ты чувствовал себя дома.
Вот я не дружу с JS и совсем не было мыслей переписать jQuery или какой плагин к нему. PHP знаю лучше, но вот использовать что-то стороннее прям иногда бесит, интереснее изучить либы и написать все по своему. Как бороться с этим не знаю =/FractalizeR
04.06.2015 15:17Раньше простую гостевую делали по учебниками и статьям и было приятно, было в кайф, все было просто и понятно.
И каждый раз каждый из нас писал гостевую с нуля. Потом прикручивал к ней статические страницы, потом динамические, потом новости, потом блоги, потом галереи картинок, форумы и… ВУАЛЯ! Так рождались самописные лапшеобразные фреймворки-велосипеды :)Arik
04.06.2015 15:22Рабочие и опубликованные «самописные лапшеобразные фреймворки-велосипеды».
Очень много народу, которые сделали все задания, но были недовольны результатом потому что появилась новая технология, а гостевая на старой технологии это полный бардак, надо все переписать!
TimTowdy
04.06.2015 15:05+5Как обычно, 95% статей вида «ХХХ для новичков» на самом деле являются «ХХХ для новичков, от новичков».
Проще говоря, MVC — это набор паттернов, позволяющий разделять может быть немного сумбурный код, на три независимые части — данные-вид-логика.
Смешно видеть такое утверждение, а затем рассуждение о Fat Stupid Ugly Controller. Ведь именно такой подход и приводит к FSUC.
Вы бы почитали откуда взялся термин FSUC, прежде чем других учить.velvetcat
04.06.2015 19:17Кстати, перевод этой замечательнейшей статьи на хабре: M в MVC: почему модели непоняты и недооценены
TheShock
Серьезно, вся тема — это расшифровка аббревиатуры MVC?!!!