The Phantom of the MVC is dead
inside my mind!..
//вместо эпиграфа
Это компиляция из более ранней статьи, дополнений и лирических отсутплений. Я не ставлю целью очередной холивар, я своё уже отспорил. Так что не обессудьте за возможное отсутствие ответов к вашим гневным ;) комментариям. Да, и я не буду к каждому предложению добавлять imho; вся эта статья является выражением моего собственного скромного мнения.
Утверждение «MVC не существует» звучит весьма резко и вызывающе, и многие сразу начинают с ним спорить.
На самом деле, это краткая форма более полного утверждения: «В настощее время на текущем этапе развития научно-технического прогресса, теории и практики алгоритмизации и программирования в объектном и функциональном подходе, реализация теоретического обоснования идеи MVC (Model-View-Controller — разделения программы на Данные, их Представление и Управление ими) в полной мере невозможна». Ещё раз: речь идёт о невозможности реализации, соответствующей теоретическему обоснованию идеи.
Возможны лишь некоторые приближения. После некоторых допущений.
А теперь по порядку:
а) МВЦ так и не имеет канонического описания. И каждый вправе думать про него что хочет.
б) МВЦ не имеет канонического описания по факту своего появления. Его придумали и начали использовать программисты SmallTalk в программировании (исключительно!) пользовательских интерфейсов.
в) Причём, если мы будем фанатично следовать триразделённости МВЦ в проектировании приложений, забывая о пункте б), что часто бывает, может возникнуть примерно такая ситуация:
Это нереализуемая патовая ситуация.
Любой другой вариант является отклонением от исходного разделения и удаляет нас от МВЦ.
Очень хороший пример именно такой ситуации был выдвинут в качестве аргумента в несостоявшемся споре юзером olegchir. Линк и ответ «на пальцах» будут ниже.
г) В свете вышесказанного особенно опасно говорить о МВЦ в приложениях, которые фактически не имеют тесной связи с клиентской частью. На мой взгляд, это все веб-приложения, за исключением, может быть, ява-апплетов.
д) Все виденные мною «реализации МВЦ» для пхп (все берут корни из phptemplates.org когда он был ещё жив; не ходите туда сейчас – там чей-то пустой блог) не являются МВЦ, это плохие эмуляции. Хотя бы потому, что классический МВЦ утверждает независимость трёх компонентов. Которая отсутствует в этих эмуляциях.
Дополнение: Скорее всего, некое подобие независимости может быть эмулировано на активных паттернах подобных Actor, Beholder, Command или архитектуре Event-Handler. Но это опять-таки решения не для скриптовых языков вроде пхп, в котором реальная польза только от Wrapper.
е) Даже полная «объектизация» языка программирования не помогает в реализации МВЦ.
Я видел больше одного пхп-проекта, написанного через принудительное разделение на классы, ну вы поняли, какие. Подобный подход даёт неплохой старт, но в конечном итоге приводил к экстенсивному наращиванию килобайт кода практически копипастой. Для работы с кодом приходилось включать GodMode. В противовес могу сказать, что я видел килобайты и совсем другого кода, написанного гением. Ни тот, ни другой случай не поддерживаемы. Да, в каждом случае это были, хм, миллионные проекты.
Нет ничего плохого, если вы используете какой-либо из ранее найденных на просторах интернета шаблонов якобы МВЦ, или даже придумали свою реализацию %) Присмотритесь к ней внимательней, и вам захочется рефакторить её и рефакторить. Не надо называть МВЦ то, что МВЦ не является.
На мой взгляд, о МВЦ нельзя думать как о шаблоне (pattern) реализации или разработки, и даже говоря о МВЦ как о шаблоне проектирования, не надо закладывать в схему (в проект) эти три буквы %) Лучше уж «проект пишем, МВЦ в уме».
===
на том был конец статьи
Злое дополнение:
Мало кто помнит, да чего уже там! Мало кто вообще знает, что изначально в MVC было две буквы M — MMVC: одна M для «бизнес-логики», а другая M — для приложения.
Так как человекам свойственно всё упрощать, вот и доупрощались: сначала букву потеряли, а затем и смысл. Свалили всё в кучу, пересказали школьникам, которые, разумеется, всё и понять-то не могли.
В результате, в отрасли мы имеем: в начальниках и «тимлидах» — тупые двадцатилетние студенты, выгнанные из бауманки, гении на всю голову, коллайдера на них нет, под чьим «руководством» криативятся миллионные проекты и десятки тысяч строк кода, там где при нормальном проектировании и архитектуре можно было бы обойтись лишь сотнями. Как следствие — проблемы с тестированием и поддержкой, и поток килорублей, текущий мимо. Мимо всего.
===
А теперь пример «объектизации». Вот здесь камент habrahabr.ru/blogs/about_cms/56271/#comment_1507929, на который я не ответил. А почему не ответил, сейчас я вам проиллюстрирую:
Мне смешно, а вам?
===
Хабралюдям, уже готовых излить потоки возмущения, ещё раз повторю: основная цель поста — свести материал, и напомнить, что MVC является образцом проектирования, но не шаблоном реализации. Не надо впихивать нивпихуемое. Незачем пыжиться и повсюду совать паттерны и объекты. Зачем добиваться результата «тяжким трудом и извращениями»(Цитата), когда нужно всего лишь выбрать правильную среду разработки и подумать об архитектуре, расширяемости и поддержке проекта заранее, до того, как будет написана первая строчка кода?
inside my mind!..
//вместо эпиграфа
Это компиляция из более ранней статьи, дополнений и лирических отсутплений. Я не ставлю целью очередной холивар, я своё уже отспорил. Так что не обессудьте за возможное отсутствие ответов к вашим гневным ;) комментариям. Да, и я не буду к каждому предложению добавлять imho; вся эта статья является выражением моего собственного скромного мнения.
Утверждение «MVC не существует» звучит весьма резко и вызывающе, и многие сразу начинают с ним спорить.
На самом деле, это краткая форма более полного утверждения: «В настощее время на текущем этапе развития научно-технического прогресса, теории и практики алгоритмизации и программирования в объектном и функциональном подходе, реализация теоретического обоснования идеи MVC (Model-View-Controller — разделения программы на Данные, их Представление и Управление ими) в полной мере невозможна». Ещё раз: речь идёт о невозможности реализации, соответствующей теоретическему обоснованию идеи.
Возможны лишь некоторые приближения. После некоторых допущений.
А теперь по порядку:
а) МВЦ так и не имеет канонического описания. И каждый вправе думать про него что хочет.
б) МВЦ не имеет канонического описания по факту своего появления. Его придумали и начали использовать программисты SmallTalk в программировании (исключительно!) пользовательских интерфейсов.
в) Причём, если мы будем фанатично следовать триразделённости МВЦ в проектировании приложений, забывая о пункте б), что часто бывает, может возникнуть примерно такая ситуация:
предположим, контроллер получает сигнал о необходимости изменений представления данных, обращается в модель за данными, модель (как достаточно высокоуровневая система) обращается к подсистеме хранения данных. И, следуя идее МВЦ, обращается она к контроллеру подсистемы, который запрашивает собственную модель, и т.д. вглубь…
Это нереализуемая патовая ситуация.
Любой другой вариант является отклонением от исходного разделения и удаляет нас от МВЦ.
Очень хороший пример именно такой ситуации был выдвинут в качестве аргумента в несостоявшемся споре юзером olegchir. Линк и ответ «на пальцах» будут ниже.
г) В свете вышесказанного особенно опасно говорить о МВЦ в приложениях, которые фактически не имеют тесной связи с клиентской частью. На мой взгляд, это все веб-приложения, за исключением, может быть, ява-апплетов.
д) Все виденные мною «реализации МВЦ» для пхп (все берут корни из phptemplates.org когда он был ещё жив; не ходите туда сейчас – там чей-то пустой блог) не являются МВЦ, это плохие эмуляции. Хотя бы потому, что классический МВЦ утверждает независимость трёх компонентов. Которая отсутствует в этих эмуляциях.
Дополнение: Скорее всего, некое подобие независимости может быть эмулировано на активных паттернах подобных Actor, Beholder, Command или архитектуре Event-Handler. Но это опять-таки решения не для скриптовых языков вроде пхп, в котором реальная польза только от Wrapper.
е) Даже полная «объектизация» языка программирования не помогает в реализации МВЦ.
Я видел больше одного пхп-проекта, написанного через принудительное разделение на классы, ну вы поняли, какие. Подобный подход даёт неплохой старт, но в конечном итоге приводил к экстенсивному наращиванию килобайт кода практически копипастой. Для работы с кодом приходилось включать GodMode. В противовес могу сказать, что я видел килобайты и совсем другого кода, написанного гением. Ни тот, ни другой случай не поддерживаемы. Да, в каждом случае это были, хм, миллионные проекты.
Нет ничего плохого, если вы используете какой-либо из ранее найденных на просторах интернета шаблонов якобы МВЦ, или даже придумали свою реализацию %) Присмотритесь к ней внимательней, и вам захочется рефакторить её и рефакторить. Не надо называть МВЦ то, что МВЦ не является.
На мой взгляд, о МВЦ нельзя думать как о шаблоне (pattern) реализации или разработки, и даже говоря о МВЦ как о шаблоне проектирования, не надо закладывать в схему (в проект) эти три буквы %) Лучше уж «проект пишем, МВЦ в уме».
===
на том был конец статьи
Злое дополнение:
Мало кто помнит, да чего уже там! Мало кто вообще знает, что изначально в MVC было две буквы M — MMVC: одна M для «бизнес-логики», а другая M — для приложения.
Так как человекам свойственно всё упрощать, вот и доупрощались: сначала букву потеряли, а затем и смысл. Свалили всё в кучу, пересказали школьникам, которые, разумеется, всё и понять-то не могли.
В результате, в отрасли мы имеем: в начальниках и «тимлидах» — тупые двадцатилетние студенты, выгнанные из бауманки, гении на всю голову, коллайдера на них нет, под чьим «руководством» криативятся миллионные проекты и десятки тысяч строк кода, там где при нормальном проектировании и архитектуре можно было бы обойтись лишь сотнями. Как следствие — проблемы с тестированием и поддержкой, и поток килорублей, текущий мимо. Мимо всего.
===
А теперь пример «объектизации». Вот здесь камент habrahabr.ru/blogs/about_cms/56271/#comment_1507929, на который я не ответил. А почему не ответил, сейчас я вам проиллюстрирую:
<?php
/* Тезисы всё те же: «всё есть объект», «всё есть MVC». */
class Object extends MVC{}
class Model exteds Object{}
class View exteds Object{}
class Controller exteds Object{}
class MVC exteds Object{
protected _model = new Model();
protected _controller = new Controller();
protected _view = new View();
}
?>
* This source code was highlighted with Source Code Highlighter.Мне смешно, а вам?
===
Хабралюдям, уже готовых излить потоки возмущения, ещё раз повторю: основная цель поста — свести материал, и напомнить, что MVC является образцом проектирования, но не шаблоном реализации. Не надо впихивать нивпихуемое. Незачем пыжиться и повсюду совать паттерны и объекты. Зачем добиваться результата «тяжким трудом и извращениями»(Цитата), когда нужно всего лишь выбрать правильную среду разработки и подумать об архитектуре, расширяемости и поддержке проекта заранее, до того, как будет написана первая строчка кода?
