Форум PHP

- эти три понятия тут встречаются чуть ли не в каждой теме про ООП. Но я их чет нигде больше не встречаю. Это из ваших книг? Можно, пока я жду книгу, вкратце описать что вы имеете ввиду под этими понятиями? Если можно, с примером.

Нет, в книгах, кстати говоря мы к нему не прибегаем (ниже объяснение почему), этот паттерн скорее ближе к десктопному ПО, Java - вообще это идеальный паттерн для десктопных редакторов, вот Word захотите писать - это самое оно. Я вообще не считаю эту модель удачной именно для Web, не говоря уже, что контроллер явно хреново отражает суть дела именно с точки зрения русского языка, "бизнес-логика" тоже ничего хорошего, но всяко лучше.

Дело в том, что совершить ошибку в ООП-программе так же просто, как в процедурной, причем ошибку именно архитектурную. Поэтому используются паттерны (термин шаблон не прижился, да и используется для обозначения другого) - удачные способы построения объектно-ориентированных программ. В процедурном подходе массивы и циклы идут рука об руку, функции возвращающие true или false, в зависимости от того правильно она сработала или нет, почти всегда используются совместно с if, числовые параметры часто оформляют в виде констант, удачные приемы можно перечислять часами. Когда разработчик не просто помнит их, а использует на практики, чувствует почему так лучше, о нем говорят как об опытном разработчики. Такие паттерны есть и в ООП, причем они делятся на чистые объектно-ориентированные паттерны и зависимые от языка. Например, в C++ стоит жуткая проблема скорости компиляции программ (сутки, неделя - это не шутка, а вполне реальные сроки), поэтому проект организуют так, чтобы его можно было компилировать по частям, т.е. работаешь с модулем, откомилировал его, а остальные части не требуется. В других языках могут быть жуткие проблемы с тем, что нет ассоциативных массивов и без них трудно работать - пожалуйста паттерн по организации таких массивов. Однако, есть чистые объектно-ориентированные паттерны, которые работают везде. MVC - это один из них.

Мы, кстати, в книгах намеренно не касались проблемы паттернов, именно из-за того, что в PHP нужно сильно пересматривать и выстраивать свою систему паттернов. Её фактически пока нет, тем более нет терминологии. Паттерн - это не FrameWork, как взбрело в голову, так и назову, все сообщество должно использовать именно это название. Вот этого не было на момент написания, ни пересмотра, ни адаптации, ни уж тем более единых названий.

На пальцах это очень просто,
1. Модель работает с базой данных, или тем, что служит базой данных: её методы позволяют добавлять, редактировать, удалять данные. Только тут допустимы SQL-запросы. Если вы видите ошибку в SQL-запросе, если база артачиться, вы знаете, что работать придется на уровне модели.
2. Контроллер - осуществляет бизнес логику, обращаясь к модели (в обход модели он в базу данных не лазит), вычислить цену, произвести парсинг, в общем любая промежуточная работа. Здесь не должно быть вообще HTML, CSS, SQL. Т.е. чистый PHP.
3. Представление - это блок, который формирует представление, будь то HTML, будь то динамическая картинка, текст.

PS Понятно, что в Web большой перекос как в сторону баз данных, так и в сторону представлений. Более того, представление очень сильно может залазить на сторону клиента: HTML, CSS, JavaScript. Это совсем другие среды, не имеющие отношения к PHP. Более того, PHP сам по природе не может создавать объекты которые разделяют несколько клиентов, отработал скрипт и привет - все удаляется, все крутые объекты и соединения. Поэтому контроллер тут явно теряется, это программа может выполнять какие-то мощные вычисления, которые потом нужно представить (причем у программы объекты живут не 30 секунд), в классическом Web-приложении, это редкость (хотя тоже бывает) - слишком мало по времени работает скрипт, работает только на одного человека, когда их тут на самом деле обращаются тысячи. Поэтому база данных, как место постоянного хранения получает огромное значение, как и методы её обработки. Так это я еще не говорю о том, что реляционная модель, она вообще плохо соединяется с объектно-ориентированной, это еще более усиливает роль SQL. С другой стороны нас ждет масса браузеров с мощнейшей системой представления, которая к PHP тоже никаким боком не относится. Поэтому лично у меня обычно очень гибкие классы моделей, позволяющие использовать SQL везде - это мощный самобытный язык, я не хочу терять его гибкость за фасадом классов, который кстати, каждый раз еще нужно строить. Так же мощные системы представления, по максимуму опирающиеся на CSS - вот это реальное представление в Web.

PPS Вообще работая с какой-либо технологией не нужно отключать голову. Если кто-то что использует и говорит, что это круто, необходимо смотреть насколько лично вам это выгодно. Слепое следование паттернам - часто лишняя бесполезная работа, которая ничего не дает. Как собственно и слепое использование ООП, от очередного класса гостевой книги без наследников пользы никому: кода и затраченного времени на его создание больше. Ну и понятно, что тут нужны паттерны, которые учитывают, что скрипты не взаимодействуют друг с другом, что они выполняются очень короткое время - этой специфики нет в других языках (её не учитывали создатели изначальных паттернов, а работа по адаптации не проделана, просто из пальца высосали примеры в попытке перенести паттерны решающие проблемы, которые в PHP отсутствуют как класс, зато паттернов, которые бы решали проблемы PHP просто нет - в других языках они не возникают). Однако, повторю, что MCV - это чистый объектно-ориентированный паттерн, его вполне можно использовать, не смотря на всю критику (однако, желательно включать голову и вспоминать в каких условиях работает PHP).

Такссс.... В закладки! )

P.S.
> PPS Вообще работая с какой-либо технологией не нужно отключать голову ... однако, желательно включать голову и вспоминать в каких условиях работает PHP)
Вот я и включаю ) Помните когда была начата тема про организацию каталога в БД? Вот с тех пор только голова и работает.... И ни одной строчки кода. И пока в голове общей картинки полностью так и не получено )))

Стоп. А физически как происходит разделение? Ведь класс нельзя разбить на 3 файла. Вот есть класс, например "элемент меню". И?... Ну модели у него может и не будет. Тогда чуть выше - класс Меню. У него будет выборка иерархии - модель, компоновка из классов "элемент меню" - контроллер, ну и Вид тоже будет. И как его поделить?

Нет-нет... элемент меню, это ни разу не класс... вернее он может выступать в качестве класса представления. Как обычно формируется меню - под него может быть выделена отдельная таблица в базе данных, оно может формироваться динамически из разделов статей или каталогов. В любом случае должен быть класс модели, скажем site_map, который выдает готовую иерархию сайта в виде многомерного массива, можно модель организовать так, что она будет выдавать лишь одномерный массив (главное меню). Заметьте карту не волнует, зачем вам данные - меню вы будете строить, или карту сайта, или sitemap для поисковой машины или еще чего задумали. Модель вообще не знает ничего про представление - её задача в таскать данные из базы данных и представлять в удобном виде.
А вот представление уже может обратиться к этому методу, чтобы вывести меню, только тут уже идет нарушение принципа модель-контроллер-вид, у нас контроллер выпал... или сместился, или нужно называть класс модели контроллером, так как модель по сути это просто SQL-уровень. Понимаете в этом и сложность, дело в том, что эта паттерн уже имеет место быть без всякого ООП, причем имеет место тут быть с 90-х, SQL - это модель, серверный язык - это контроллер, HTML+CSS+JavaScript - это представление. Дробить уровень контроллера еще раз на модель/контроллер/вид... ну искусственно это выглядит (ну можно, если вам нужно ввести пункты меню, отсутствующие в базе данных - тогда контроллеру будет чем заняться, а так он должен быть пустым - никаких доп.вычислений не производится).

Это все так. Я просто все это не расписывал. У вас скорость печати какая-то сумасшедшая ) Я походу читаю медленнее чем вы пишите ) Вопрос-то был не в том как поделить задачи, а как физически разделить. Вот класс "А". У него есть MVC. И все это в одном файле класса. В чем разделение?

Нет лучше MVC в одном классе не реализовывать - у вас будет либо мега-класс сумасшедшего размера, либо на один класс будет увязано все остальное - тоже ничего хорошего. Рубите связи. ООП для того и изобретали, чтобы было как можно меньше связей и как можно меньше хаоса, чтобы из кучи амеб начинались формироваться более или менее независимые органы большого организма. Понятно, что они будут друг на друга влиять, но не на уровне, что одна амеба возбудилась и вся колония куда-то побежала... Не надо один класс, в PHP, Java это вообще плохо работает (это в C++ хорошо) - создавайте много классов.

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

> Нет лучше MVC в одном классе не реализовывать - у вас будет либо мега-класс
> сумасшедшего размера, либо на один класс будет увязано все остальное
не, я всерн не понимаю.... Я почему взял в начале примером "элемент меню"?... Вот я не плохо помню ОО модель в Delphi. Ну вам Visual C ближе, но тоже самое. Отвлечемся от ПХП и веб... Вот втыкиваю я в форму кнопку. Это объект - экземпляр класса буттон. И у нее есть свойства, события, обработка событий и т.д. Тоже самое с классом меню, который состоит из экземпляров класса ЭлементМеню. Я мега-класса не вижу. Вот похожим образом я хочу и тут организовать. Мега-класс есть - СТРАНИЦА со своими свойствами (индех/ноиндекс, ключевики, тайтл, дескрипшн и т.д.). Она уже состоит из более маленьких классов - header, menu, leftPanel, body, footer. Мега-классы меня как раз не особо волнуют. У них будет не много настроек. В основном вид. Но каждый из них дробится дальше и так до самого простого. Вот в классе меню есть общий вид, т.е. компановка элементов меню в целое, и общая модель, т.е. формирование массива структуры меню из БД. И на что его еще дробить? В делфи я втыкал меню, настраивал его элементы и все это работало как единое целое. Надеюсь понятна мысль.....

>Отвлечемся от ПХП и веб...
Давайте, еще даже лучше... только не следует забывать, что в Delphi мы пользовались уже готовой объектно-ориентированной системой. Когда вы втыкали кнопку, под ней была уже была иерархия нескольких классов, вам и писать ничего не приходилось. Вот если вы брали класс кнопки и наследовали от неё свой, перегружая методы, а еще лучше писали свой компонент, тогда да, вам приходилось строить ООП-модель и учитывать требования нижележащих классов. Потом, когда компонент был готов, вы пользовались готовой ООП-библиотекой (могли использовать ООП, а чаще нет - VCL просто таки провоцировал на программирование на формах - поэтому в конце концов и издох - нельзя так в серьезных проектах).

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

УФФФ (((

У вас тут в скриптах есть какой-нить не особо запутанный, чтоб не 3 дня разбираться, но чтоб там наглядно это было? Я прост пока никак не могу сообразить, что мне может помешать взять класс меню из одного проекта и впихнуть в другой. Ну кроме вида.

Но самое главное, вы мне никак не ответите по какому месту водораздел проходит. То ли MVC это 3 полностью раздельных ничем не связанных класса (тогда не могу понять как это организовать, т.к. для любого "отображения" нужно знать "структуру" отображаемого), то ли класс displayMenu (вид) должен быть extends prepareMenu (контроллер), толи еще как-то....

Э... именно MVC? Не думаю, что есть чистый, мы считаем, что этот паттерн не очень выгоден в Web, лучше говорить о разделении HTML и PHP, текста и HTML, компонентах, чем о MVC. MVC - это проблема построения монолитного приложения, а сайты очень редко бывают монолитными (ну разве что какой-нибудь сайт с крутыми личными кабинетами на которые все увязано). Большинство же сайтов модульные - гораздо важнее вводить модули и убирать их. Я вообще не понимаю зачем вам именно MVC? Почему бы просто не построить удобную вам ООП-модель? Тот же VCL в Delphi - он же ни разу не MVC, они тоже контроллер схлопнули, рассовав его по моделям и представлению, из-за чего стало очень удобно делать утилиты, в которых документ и его множественное представление вообще не нужны. У сайта очень редко бывает множественное представление одной и той же информации, а когда бывает проще эту проблему решать через шаблоны - так как верстка зубодробительная: если растаскать HTML-верстку по классам, вы потом костей не соберете, важно чтобы верстка сосредотачивалась в едином файле. Я вообще не понимаю, почему все с MVC так носятся, да очень известный паттерн, но он же не единственный, да и в Web без него проблем полно, которые MVC не решает, а просто отвлекает ваше внимание от них. Более того, и Web, и PHP долгое время развивались без ООП, проблемы, которые решает MVC решали другими средствами тоже вполне себе элегантными - вводом новых языков программирования (да еще декларативных!). Декларативные языки + ООП: гремучая смесь, они решают одни и те же задачи разными способами, очень сильно можно влететь запутав их на уровне архитектуры.

Тыдышшщь!!! )))

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

Так и буду делать ) Спасибо ))

Да первом же сообщении отговаривать принялся :))), ну может не совсем четко, но не хотелось вообще напропалую критиковать, все-таки уважаемый паттерн, многими любим :)))
>Я вообще не считаю эту модель удачной именно для Web

Чем дальше в лес.....

> Нет-нет... элемент меню, это ни разу не класс...
Почему не класс? А с точки зрения администратора ресурса? Т.е. у него должны быть методы: Добавить, удалить, переместить, скрыть и т.п.... Или админ-часть тоже в отдельный класс выносить принято?

>> Нет-нет... элемент меню, это ни разу не класс...
>Почему не класс? А с точки зрения администратора ресурса?
С точки зрения MVC.

>Т.е. у него должны быть методы: Добавить, удалить, переместить, скрыть и т.п.... Или админ-
>часть тоже в отдельный класс выносить принято?
Может, но уже на другом уровне, не на уровне MVC. Т.е. при реализации представления View, можно уже заводить какое угодно количество классов, четко выполняя интерфейсный ограничения MVC, т.е. не лазя, например, за элементами меню в базу данных напрямую.

так я ж уже отказался от MVC ) Ладно, в этой теме уже путаница что к чему относится. Будут еще вопросы, буду новую тему заводить. Еще раз спасибо!

>так я ж уже отказался от MVC
Извините? Я выборочно предыдущие прочитал, но последнее меня затронуло.Допустим Объект- представление (Модель - Вид)
Объект - таблица базы, например пользователи, товары
Представление - Разные страницы для одной таблицы. Например при регистрации, авторизации, формировании списков пользователей, формировании карточки пользователя.
Важно, на мой взгляд , что если вы неудачно определите поля таблицы, то вам менять каждый раз при доработке.Второе, если у вас код php перемешан с html , дорабатывать на определенном этапе развития станет проблемой.

Еще момент. Все можно засунуть в один файл. Первое что исторически отделяют - данные.Если вам удобно развивать все в одном файле, то мир прекрасен. Дальше одним удобнее процедурное, другим классы, но всегда одно важно, как вам лично быстрее дорабатывать. Пока вы не попробуете сами, вы сами не узнаете. А не попробуете, пока не будете чувствовать проблемы при доработках и изменениях под разные задачи. Так, для наглядного примера, в фильме Укрощение огня показано, что монолитный проект ракеты , без ступеней, не жизнеспособен для будущего. Потом оказалась, что последовательная схема ступеней у ракеты хуже параллельной. Я привел пример, что в процессе вашего развития личные взгляды могут меняться и любой человек начинает ходить кругами в поисках оптимального способа.Истина где-то посередине, но она вокруг да около ходит

>>так я ж уже отказался от MVC
>Извините? Я выборочно предыдущие прочитал, но последнее меня затронуло.Допустим Объект-
>представление (Модель - Вид)
>Объект - таблица базы, например пользователи, товары
>Представление - Разные страницы для одной таблицы. Например при регистрации,
>авторизации, формировании списков пользователей, формировании карточки пользователя.
Куда контроллер то потеряли? Где он у вас?

>Истина где-то посередине, но она вокруг да около ходит
Конечно, но ракету с кучей параллельных двигателей, не обязательно всегда называть мотодвительным движетелем... речь ровно об этом, что не нужно весь ООП называть MVC - это не так, MVC часть ООП, а не наоборот.

Я просто хотел подсказать и не навязываюсь.
Провел аналогию. Не строгую аналогию, как отображение элементов признаков.
А нет, получилась строгая аналогия.

Наглядный вариант реализации MVC в файле
Есть IDE, которые работают с MVC. Так или не так?