Гуру, я не знаю что такое MVC в PHP, хоть и считаю себя опытным программистом. Объясните наконец!

[igortik]

1. Классами код нагляднее реализуется, что подходит как для реализации "C", так и "M", ну и и "V"
2. Наследование? В моем понимании мне нечего наследовать из bootstrap, например, разве что использовать статические свойства с массивом конфига, например.
Модели нечего наследовать от контроллера, его задача получить ряд переменных и их значений, чтобы вернуть результат в исходную точку (контроллер), хотя, может зависеть от реализации, возможно, кто-то будет наследовать, но я пока смутно вижу в этом смысл :/

Т.е. я для себя понимаю так: моя задача при написании CMS разделить и сделать независимыми данные разного характера, но иметь возможность к ним в любой момент обратиться (настройки, данные из URI и т.д.).

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

p.s. Духовность™ прекрасно показал на примере ТТУК и чистый контроллер в реализации на пхп, код читабелен и не загружен работой с данными для примера с отделенной моделью.

Так что я все же склоняюсь к тому, что MVC - это скорее стиль программирования.
Но как его не окрести, суть заложена здесь:

Шаблон MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента

 

[igortik]

к теме:

сделай настолько просто, на сколько это возможно, но не проще. (с) Эйнштейн

 

[fixxxer]

Че-то разговор как во всех тредах про application design ушел во все стороны.

Давайте лучше вот че обсудим

Вот есть такой язык Scala, и на нем есть фреймворк Lift. Паттерн, который они используют, они сами назвали "view first". Вот так выглядит код (тут надо одновременно смотреть на шаблон):

 class Show {
    def myForm(xhtml: Group) = {
      var name = ""
      def handleYear(year: String) {
        // the form's been submitted... do something
      }
      bind("f", xhtml, 
        "name" -> SHtml.text(name, name = _),
        "year" -> SHtml.select((1900 to 2007).toList.reverse.map(
          v => (v.toString, v.toString)),Empty, handleYear _)
      )
    }
  }

Они это противопоставляют тому, что они понимают под MVC, но для тех, кому особо хочется, предлагают такую реализацию оного. Из чего что следует - то, что они под "C" понимают некое подобие Front Controller, что, кстати, уже весьма близко к классическому MVC с поправкой на stateless веба.

Короче, это я к чему - термин "Page Controller" это фигня, высосанная из пальца. (Я, кстати, никогда не употреблял этот термин без слов "как это некоторые называют"). А архитектура, к которой я пришел, это как раз близко к View First (и в вырожденном виде она и есть - просто у меня связь с моделями обычно не напрямую, а через сервисный слой), за исключением того, что элементы шаблона я четко не разделяю на методы, а наоборот, этим элементам делаю bind в какую-то переменную вьюхи; по сути разница только в том, с какой стороны подойти, а так, те же яйца. Примерно то же решение предлагается для отказа от упомянутых "ТТУК" автором статьи об оных.

 

[grigori]

Лет так 5 назад я писал, что строю систему по принципу N-Tier. Потом все выучили слово MVC, и мне тоже пришлось использовать его при общении с клиентами.

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

А ведь роль контроллеров отлично выполняют скрипты на 10 строк. Дебажить и дорабатывать их удобней, чем классы контроллеров - они так просты, что их не надо дебажить вообще. Причем это реально View - контроллеры, этакие маленькие active view - контроллеры, которые дергают нужные модели и подгружают шаблон.

Вот смотрю я на классы контроллеров, и вижу: метод getModel(), метод проверки пермиссий и пачка actionXXX с одним вызовом render в каждом. Это все.
Зачем это называть MVC и собирать в отдельный класс обработку разных вызовов - я не знаю. Кому-то так захотелось.

 

[fixxxer]

Причем это реально View-контроллеры.

О.

 

[grigori]

MVC-приложение на PHP построить несложно
например, веб-чат с phpDaemon на сервере, AJAX-интерфейсом в браузере, и COMET-соединением

 

[Alien85]

Мне больше интересно смотреть на людей с пеной у рта говорящих о ООП, контроллерах, видах, front и т.п., а сами создают сайты на чьей-то CMS маленьким фирмочкам с будущей посещаемостью 10 - 100 человек.

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

И ведь никто не хочет понять, что ajax запрос на проверку занятости Login-а или выдачи контента должен быть в несколько строчек.

А лично мое мнение, что все эти примочки для php должны использоваться в узких местах или настоящих CMS, ну или где над проектом работает несколько человек, а не в тех местах, когда человек из-за всего этого не может шаблонизатор написать.

Кстати, заметьте, многие кто писал в этом топике, сначала погуглили, о чем говорит их знания по теме

 

[Koc]

Кстати, заметьте, многие кто писал в этом топике, сначала погуглили, о чем говорит их знания по теме

возможно просто людям сложно грамотно сформулировать мысль.

Я собрал уже 60+ сайтов за жизнь, которые кормят меня профитом от рекламы

можно примеры? можно в личку. Че-то как-то дофига.

Духовность™
немного напрягает, что через сообщение вставляешь ссылки на уютненькое. Луркоебство какое-то


По сабжу: ну да, все дураки, компания-производитель языка в том числе.

 

[Mols]

Я вообще мало понимаю, что в этом топике творится.
Такое впечатление, что все под MVC понимают что-то своё.
MVC - это шаблон проектирования.
Основная ценность шаблонов именно то, что они применимы в совершенно различных условиях.
В том числе как к веб, так и к десктопным приложениям.
Безусловно со своими оговорками и т.п.
Вики на мой взгляд довольно точно дает определение

Model-view-controller (MVC, «Модель-представление-поведение», «Модель-представление-контроллер») — архитектура программного обеспечения, в которой модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента, так, что модификация одного из компонентов оказывает минимальное воздействие на другие компоненты.

Внимательно читаем определение
1. модель данных - реализуема в PHP
2. логика - реализуема в PHP
3. пользовательский интерфейс - реализуем посредством браузера. Браузер выступает в роли посредника которому выданы инструкции сформированные в PHP.

Цель паттерна - минимизация зависимости 1, 2, 3 друг от друга достигается.
В чем противоречие?

вот это например что значит ?

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

Почему нет факторов? Действие пользователя - это фактор.
Для их обработки идут запросы на сервер... ну да.
Ну вместо перерисовки на канве( в GUI ) приходят новые инструкции (которые созданы PHP) для браузера и всё равно происходит перерисовка (в браузере).
Да используются километры проводов для передачи информации, а не сантиметры шины на материнской плате....
Но смысл же один и тот же.
Действие пользователя (внешний фактор) привело к выполнению логики, работе с моделью данных и изменению вида.

Фиг его знает... ещё и в теорию программирования перенесли...

 

[grigori]

Есть разница между автоматизацией выполнения приложений с разными параметрами, как в shell-скриптах линукса, и взаимодействием с работающим приложением.
Действия пользователя обрабатывает только OS, браузер и Javascript. Иногда эти приложения инициируют запуск удаленного консольного приложения на php.
Мы все еще просто вызываем cgi-приложение, как ls или rm из консоли, и оно просто возвращает результат работы - некоторый текст.

Привязывать к php действия пользователя в виде событий - как корове седло. Это желание людей мыслить привычными шаблонами, потребность в кумирах, в возможности сослаться на Банду 4х.
А еще это хороший маркетинг, об MVC и паттернах круто писать клиентам - сам это делаю.

 

[Активист]

Хорошо, вот духовность привел нам нечто-то такое "модное", а котором четко разделил логику входящих данных и исходящих данных. Его задача - вывести заметки (какой-то контент).

Теперь.

<?php
//
//  У нас есть единая точка входа и загрузчик и вот этот модуль, назовем его news, загрузчик сам определеяет какой модуль подключать
// 
switch($application->requestFiles) {
case "index.html": // здесь можно применить паттерн стратегия
$newsId = isset($_REQUST['news']) && (int)$_REQUST['news'] > 0 ? $_REQUST['news'] : 0;

$aggregator = $application->modules->news->createAggregator();
$aggregator->appendById($newsId);
if ($aggregator->sizeof() !== 1) throw new applicationException("News Not Found", 404);
$news = $aggregator->fetch();

$application->content()->setContentSection($application->render("news.tpl.php", $news));
$application->content()->setTitle($news->title)
break;
}

?>

Здесь нет никаких сложных слов, здесь есть основной загрузчик - application, который и контроллер, и виевер в Вашем понимании MVC, но ведь ведь MVC здесь и не пахнет.

И в добавок, все, кто восхваляет большую четверку (не удосужившись купить их книгу и поучиться) и доказывают здесь, что MVC - не ООП - ошибаетесь, MVC - это ООП, но "MVС" в PHP - это стиль кодинга, не более. Хотя можно конечно написать приложение на PHP, работающее долго (демон) и внедрить туда уже правильный MVC, но в Вебе не может быть MVC вообще.

Вот пруфы:

 

[Adelf]

Активист
http://en.wikipedia.org/wiki/Model–View–Controller#Architecture_vs._Frameworks

"Although MVC is typically associated with frameworks, it is essentially an architecture.[5] This means that it can be implemented even without an object-oriented language or a specific class hierarchy."

 

[grigori]

"чтобы изменить численность слонов в Африке достаточно изменить статью в википедии" (С)

многие люди в принципе не способны мыслить - у них только шаблоны, афоризмы и цитаты авторитетов

 

[Mols]

Есть разница между автоматизацией выполнения приложений с разными параметрами, как в shell-скриптах линукса, и взаимодействием с работающим приложением.
Действия пользователя обрабатывает только OS, браузер и Javascript.

это все понятно.
но не совсем так.
Действия пользователя обрабатывает ещё и железо.
Кроме того база вполне может быть на другой машине и может быть использована ОС той маширы для получения данных.
То есть между GUI приложением и пользователем есть туева хуча посредников в виде железа, ОС, транспотных протоколов и т.п.

Здесь внимание.
Если мы рассматриваем веб_приложение то просто на некоторых этапах добавляются дополнительные посредники (в виде железа - сетевые карты, сервер и т.п, в виде софта на сервере и т.д.)
И часть (или вся) логики исполняется в другой ОС (на сервере).
Это вся разница.
да - это специфика веба.
Но скажите мне... какое значение эта специфика имеет при реализации MVC ?
Просто на определённых этапах между пользователем и приложением не 10 "посредников" а 20. И что?

Привязывать к php действия пользователя в виде событий - как корове седло. Это желание людей мыслить привычными шаблонами, потребность в кумирах, в возможности сослаться на Банду 4х.
А еще это хороший маркетинг, об MVC и паттернах круто писать клиентам - сам это делаю.

От уж придрался так придрался)))
Конечно действия не надо привязывать к PHP. (мне вообще не понятно, что значит "привязывать действия к PHP").
Важно, что это по сути внешний фактор для вашего веб_приложения
Ещё раз повторю именно веб_приложения.
А на чем оно там у вас написано... это пофигу.
И именно приложение должно корректно отработать это действие и вернуть ответ(через чуть большее число посредников чем в десктопном варианте).

Поэтому я не согласен с постановкой вопроса в принципе.
PHP вполне подходит для реализации MVC (с учетом особенностей веб)

 

[grigori]

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

 

[Mols]

grigori
Какой поток сознания?
Поток сознания (а скорее эмоций) - это стартовый пост.
В котором в кучу замешаны и ООП и MVC и какие-то сугубо личные примеры M , V и C
+ добавлено что-то вроде "дикие фреймворки" и "все заблуждаются"
И Вы (в том числе) участвуете в обсуждении этой каши вроде как с серьёзным видом.

Когда у некоторых участников появляется проблеск здравого смысла и предлагается хотя бы определится "что же в этой дискуссии понимать под MVC? "
И предлагаются формулировки определений с линками на вполне вменяемые ресурсы - им тут возражают в стиле "не умеют мыслить" "стереотипы".
Это полезно чтоли?

Mols, твое согласие мне безразлично,

А уж это просто ппц какая полезная информация.
Просто кладезь пользы)))

как твое сообщение поможет кому-то в реализации проектов - не вижу, значит, доля полезной информации в твоем сообщении стремится к нулю

Как поможет Ваше?
Я писал по теме. И только.
Здесь нет ни одного вменяемого поста который бы показывал, что MVC не может быть использован в PHP.
И основной аргумент, который некоторые похоже считают догмой "MVC только для GUI" - как раз и есть стереотип.
Это основная мысль моего предыдущего поста.

[update]
Кстати то, что я не согласен с постановкой вопроса это не лично к Вам.
Это просто моё мнение по теме дискуссии.

 

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

"MVС" в PHP - это стиль кодинга, не более ... внедрить туда уже правильный MVC... Вот пруфы:

Жесть)) "Правильный MVC". Что такое правильный MVC? То, что написано в "Банде Четырех"? Так там явно написано:

MVC состоит из объектов трех видов. Модель – это объект приложения, а вид – экранное представление. Контроллер описывает, как интерфейс реагирует на управляющие воздействия пользователя

В чем проблема на PHP написать эти три объекта? В этом что ли:

Что такое MVC - это паттерн GUI приложений, которые работают сколь угодно долго, а не как скриптовый язык, живущий доли секунд.

Вот это - пестец. Ты привязываешь концепцию к среде программирования! Все равно, что привязать правила дорожного движения к марке автомобиля. Да, управлять легковушкой нужно сдав на категорию B, управление другими ТС требует несколько иных правил, но суть поведения на дороге для 90% водителей неизменна.

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

 

[Mols]

И в добавок, все, кто восхваляет большую четверку (не удосужившись купить их книгу и поучиться) и доказывают здесь, что MVC - не ООП - ошибаетесь, MVC - это ООП, но "MVС" в PHP - это стиль кодинга, не более. Хотя можно конечно написать приложение на PHP, работающее долго (демон) и внедрить туда уже правильный MVC, но в Вебе не может быть MVC вообще.

Вы бы перед тем как такое писать посмотрели бы сами эту книжку и поучились.
Первое, что Вам стоит посмотреть это список паттернов в этой книге.
У меня это главы 3, 4, 5 - стр. 89-332.
Попытайтесь найти там паттерн MVC.
Хочу сразу огорчить Вас... его там нет.
Почему нет? Потому что книжка называется "Приемы объектно-ориентированного проектирования"
И авторы этой книги достаточно компетентны, чтобы понимать, что MVC сам по себе таким (объектно-ориентированным) приемом (паттерном) не является.
А те "пруф" линки касаются именно "Паттерны проетирования в схеме MVC в языке Smalltalk"
Даже не "Паттерн проетирования MVC в языке Smalltalk"
Читайет пожалуйста всё, а не только то, что хочется.
То есть в книге о приёмах объектного проектирования, описывается реализация архитектуры MVC именно в Smalltalk.
И таки да... там речь идет о объектах. Было бы странно если бы в такой книге была иная реализация. Не?

Но это никоим образом не делает тождества MVC === OOP
И потому все выводы построенные на предположении, что MVC === OOP - ошибочны.

[update]
Я хочу сразу заметить.
Я это всё пишу не ради "поумничать" Или что-то доказать.
Мне думается, что Вы просто не очень точно формулиете, что же именно Вы хотите понять.
Потому как вы посмешивали действительно не очень связанные вещи.

Паттерн MVC - это абстакция.
OOP реализация - наверное самая распространённая но это только реализация.
То что Вам не нравится ООР в конкретных фреймворках... ну это вообще к MVC не относится.

Вы это всё в кучу скинули и "доказали" самому себе что MVC в вебе нет.
Но я так понял ответа на свой вопрос всё таки не получили..
Иначе не было бы топика..
Дык может таки сформулируем четко в чем проблема то?

 

[itprog]

из цитируемых цитат у каждого свои термины. Кто-то говорит что это 3 компонента, кто-то - 3 объекта, другие 3 класса. Я всегда под MVC понимал слои приложения. Но если придерживаться официальной терминологии из истории, то MVC описывается как объекты/классы и в контексте Smalltalk. Значит без ООП не было бы MVC, потому можно утверждать MVC === ООП %)

Mols
Смотря на какую часть названия смотреть. Контраргумент - книга о "Design Patterns: Elements of Reusable Object-Oriented Software". А MVC не паттерн , а парадигма, как тут уже говорилось.

 

[Mols]

itprog
ы))) принимается)))
Вот сразу же контр аргумент.
http://martinfowler.com/eaaCatalog/modelViewController.html
Читаем... опа... MVC таки паттерн.
Так что давайет не будем играть словами парадигма/паттерн и т.п.
Одно ясно MVC !== OOP
Хоть там паттерн.. хоть парадигма(честно говоря слово парадигма вообще редко использую и не уверен, что понимаю его правильно в этом конексте).
Ну а то, что он был создан(изобретён) в контексте Smalltalk это же не делает его менее абстрактным правда?
Какая разница в каком языке был впервые реализован какой либо паттерн?