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

no_santa

Снегур
Стоит ли делать как в ZF инклуд файлов с поиском по заведомо заданным базовым путям, если сами разработчики указывают на оптимизацию очередности этих путей, чтобы не возникало "задержек"?
Мотать мой лысый череп! Этот человек говорит про ООП? Я бы его даже к автобусной остановке за километр не подпустил.

Я не претендую изобрести что-то новое и рвать стереотипы
P.S. Надеюсь, я разрядил немного тему споров "есть или нет MVC" :)
Нет, вы просто попытались порвать мозг читающих, возможно не безуспешно.


P.S. Вообще, я бы с радостью поучаствовал в каком-то совместном открытом проекте по реализации нечто такого минималистического, не нагруженного переизбытком умственного потенциала, где понятие "это нужно" обосновывается, а не впихивается клочками кода "про запас", а допустим лишь рост библиотеки хелперов и прочего функционала :)
Не стоит...
 

atv

Новичок
Ну раз пошло такое массовое прозрение про суть MVC в PHP, а также понимание, что 3-х!!! слоёв приложения маловато, предлагаю обратить свои взоры на Событийно-Ориентрованное Программирование :D, а так же на фрэймворки, которые не вписали в свои дескрипшины эти позорные три буквы :D
 

igortik

Новичок
no_santa
Мне жаль, что мое сообщение порвало твой мозг :/

И еще: не вижу связи "работы с файловой системой" и "ООП", может это ты форумом ошибся? :)

P.S. Вопрос про пути звучал не из воздуха, а исходя из туториала: http://zendframework.ru/articles/tutorial-building-basic-site-on-zend-framework-1-5
Но это для тебя, как и википедия тоже пустой звук, увы.
 

craz

Нестандартное звание
- Стоит ли делать как в ZF инклуд файлов с поиском по заведомо заданным базовым путям, если сами разработчики указывают на оптимизацию очередности этих путей, чтобы не возникало "задержек"?
если вы про этот вопрос - то 1) почему не стоит 2) почему как в ZF 3) у нас всегда должен быть определен пул путей в приложении, писать что-то типа автолоадера для поиска по всей папке приложения затратно.
 

igortik

Новичок
если вы про этот вопрос - то 1) почему не стоит 2) почему как в ZF 3) у нас всегда должен быть определен пул путей в приложении, писать что-то типа автолоадера для поиска по всей папке приложения затратно.
я про это и спрашивал, но некоторые развели пузыри вокруг ООП почему-то на счет этого вопроса :/
мне думается, что автолоадер немного не оправдывает себя, т.к. можно юзать, например, $inc->sysClass(array or single value or values separated with comma) и для конкретного метода будет своя область поиска.

Сходства с include (или require):
1. Один оператор
2. Способ передачи параметров

Преимущества:
1. Не думаем о путях (выигрываем в скорости поиска файла)
2. Внятность (метод трактует что загружается)

Минус:
1. Уступает в удобстве разработки ООП-приложения (если сравнивать с ZF автолоадером)
2. Два оператора для создания объекта класса.

В ZF там на этот счет все круто - автолоад класса при попытке создать его объект, т.е. упрощается на 1 оператор, вроде как гибко, но страдает производительность:

То есть, в коде например пишем $news = new Text_News_Home();

Символ "_" используется как разделитель, Zend_Loader будет пытаться найти указанный класс по адресу Text/News/Home.php. (В рассматриваемом примере в index.php я указал относительно каких директорий будет происходить поиск)

Для автоматической загрузки можно использовать метод Zend_Loader::loadClass() или же выполнять Zend_Loader::registerAutoload(); что бы не писать каждый раз Zend_Loader::loadClass(). Правда registerAutoload() требует наличие модуля spl_autoload. С другими подходами к автозагрузке классов вы можете ознакомиться в статье. К сожалению, такая гибкость в подгрузке классов идет в ущерб производительности, если вопрос производительности стоит для вас очень остро, рекомендую ознакомится с официальным приложением к мануалу.
 

craz

Нестандартное звание
я вас не понимаю(
в ZF все круто - вам то что нужно тогда? сделайте как в ZF и даже больше скажу просто подключите его автолоадер и не надо ничего выдумывать.
 

igortik

Новичок
что хорошего в поиске файла по всем возможным репозиториям (системная библиотека, библиотека приложения, модели, контроллеры и т.п.)?
 

Andreika

"PHP for nubies" reader
что хорошего в поиске файла по всем возможным репозиториям (системная библиотека, библиотека приложения, модели, контроллеры и т.п.)?
возможностью "переопределить" модель из системной библиотеки контроллером в библиотеке приложения
 

craz

Нестандартное звание
что хорошего в поиске файла по всем возможным репозиториям (системная библиотека, библиотека приложения, модели, контроллеры и т.п.)?
в ZF не так, но да там есть пул и это сокращает внедрение внтурь CMF своих модулей к примеру есть каркас на чистом ZF кладем library/somecodelibrary/application - и сюда расширенные Somecodelibrary_Application в конфиге прописываем папку подключения и вуаля мы имеем свой расширенный Somecodelibrary_Application через автолоадер без необходимости include.
В чем у вас проблема? По-моему проблему вы надумали. или думаете что она есть, но ее не нет
 

Активист

Активист
Команда форума
Т.е., большенство говорит здесь, что MVC это уменее разделять, ну а какой смысл тогда это знать. Как можно знать умение? Умение - это опыт применения, а поскольку четкого определения нет - то это только самому владельцу сей кладезь знаний и известно? Судя по этому треду - разделять каждый будет по своему. Так? Это мой вывод по этому треду.

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

Она годиться на роль знающего MVC?

HraKK
Ну так, я не понял, заикнулся - говори, MVC - это ООП или это стиль кодинга?
Кто-то писал:
<?php
$id = $_GET['id']) ? $_GET['id'] : -1; //c
$id ++; //m
echo $id; //v
?>
тоже MVC.
 

igortik

Новичок
Активист
Да, каждый будет разделять по-своему с применением базовых принципов, но архитектура у каждого будет разная, либо частично похожа.
MVC это не ООП по определению, думаю ООП даже незачем применять при построении простейшей достаточной в 95% случаях архитектуры для удовлетворения бизнес-модели проектов B2B направления.

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

Реализация классами лучше, т.к. они систематизируют функции (методы) и то я не исключаю репозитория с функциями, почему нет?
Это уже дело стиля конкретного программиста.

А тот код, что ты написал вряд ли можно назвать MVC, там нет никакого разделения, весь функционал в области одного файла..
Ну, его, в принципе, тоже можно разделить.... комментариями к коду /* :D */
 

Духовность™

Продвинутый новичок
ваша проблема в том, сто вы все пишите какие-то определения при полном отсутствии ПРИМЕРОВ КОДА. О чем может быть речь, о какой дискуссии, если тут никто не может вразумительного кода привести, что бы дискуссия была прозрачна?
 

korchasa

LIMB infected
Духовность™
Да какой нафиг код. MVC это способ выделения слоев приложения, а не контрактов конкретных классов. PL/SQL (Model) + PHP(Controller) + XSLT это тоже MVC. Причем способ не единственный.
 

craz

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

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

atv

Новичок
Итого, делаем вывод: MVC это миффф!!! недосягаемый :D, а программисты мифффологи :D
 
Сверху