Блог веб-разработчика: в помощь программистам

MVC в языке PHP

кодоэнрговодный php кодымодышмодный программист

Как уже упоминалось — простота и доступность языка РНР зачастую обуславливает его некорректное использование. Это приводит к разработке приложений, которые очень трудно поддерживать. В частности, в контексте модели MVC это приводит к тому, что компоненты «модель», «вид» и «контроллер» размещаются в одном сценарии. Именно при таком подходе можно говорить о сценарии. В свою очередь, при корректной реализации шаблона MVC сценариев в приложении не «существует», а есть только компоненты.

Как не нужно делать

Предложите любому неопытному PHP-разработчику создать приложение гостевой книги, и он наверняка реализует его в виде единственного сценария. Этот файл может называться guestbook.php и выполнять как отображение существующих записей книги, так и добавление в базу данных новых записей. Его код будет иметь следующие особенности:
— Номер отображаемой страницы передается с помощью параметра метода GET.
— Если номер страницы не указан, отображается страница 1.
— Выполняется проверка наличия параметра NewGuestBookEntry. При его наличии выполняется проверка соответствия ограничениям (по длине и содержимому) и данные заносятся в базу. При его отсутствии выводится сообщение об ошибке. Сценарий завершает работу.
— Из базы данных извлекаются записи, соответствующие данному номеру страницы.
— Эти данные заносятся в таблицу HTML (описанную прямо в файле сценария).
— Пользователю выводится форма HTML, позволяющая ввести новую запись.
Этот подход содержит множество проблем, связанных не только с использованием
метода GET для внесения изменения в базу данных. Если посмотреть на такую реализацию с точки зрения шаблона MVC, то окажется, что многочисленные компоненты контроллера и вида переплетаются друг с другом, создавая множество сложностей.

  • Не совсем согласен со статьей. Для конечного пользователя возможно и появляются некоторые неудобства при попытке редактирования (модификации) внешнего вида, т.к. в php-сценарии будет довольно сложно разобраться и что-либо найти не разработчику..

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

    А то, как будет выполняться сам сценарий – зависит от программиста. Ведь большинство описаных “проблем” можно легко обойти при грамотном написании кода.

    Если же автор считает что я не прав, то почему тогда указал только “неправильные особенности” и не написал, как же все-таки нужно правильно делать!

  • ZyBoy, нехорошо так говорить… Вопрос даже не в том, что пользователю удобнее – это вопрос философии.

    Я редко встречал в своей практике 2 разные работы программиста, выполненные в примерно одно время, которые используют 2 разные методики…

    Так либо иначе MVC не только упрощает жизнь – оно дает кучу возможностей. Пример? Легко: есть у вас объект “Structures” – не важно, что он описывает – дерево комментариев ли, дерево категорий… Будем считать, что он является прототипом.

    Как без MVC реализовать на основе этого parent-класса 2 разные структуры? switch`ем? :)

    “его описание в“разграниченом””… Бред. Простейший подход к MVC – это:

    $output = template::loadView(‘pageWrapper’);
    $data = new treeModel(`table_name`);
    $template = template::loadView(‘some_template’);
    $output = template::mountVars($template, $data);

    сложно? :)
    При том, что классы treeModel и template у вас валяются написанные уже год…

    А теперь сделайте тоже самое без MVC. А потом добавьте к ссылкам nofollow. А потом клонируйте :)

    Все это imho, конечно… Но говорить о том, что questbook должен быть из 1-го файла, смешанный наглухо… И что ООП использовать нехорошо – мягко говоря – недальновидно 😉

  • Прикольная картинка, я вспомнил Назад в Будующее с этим.. flux capasitor :)

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

  • Уже полгода работаю с концепцией MVC во фреймворке CodeIgniter. Концепция MVC это святая святых и как никто описывает ПРАВИЛЬНОЕ написание любого веб приложения! Такие приложения удобно использовать и что немало важно, легко находить и устранять ошибки!

  • Как без MVC реализовать на основе этого parent-класса 2 разные структуры?
    Как угодно. MVC – это шаблон, паттерн, архитектура – он всеголишь воплощает собой идею разделения бизнес-логики от представления но никак не дает больше возможностей, вообще все описанные в комментариях возможности – заслуга не MVC а ОО-подхода.
    Да, guestbook из одного файла – это мягко говоря плохо(это не то что хуже MVC – так вообще писать нельзя), но использовать MVC ради написания гостевой книги – еще хуже (если эта гостевая книга является отдельным компонентом а не частью проекта).
    И чем так плох метод GET для передачи параметров?
    Вообще плохой пример для сравнения с MVC, можно сказать пример не по теме.

  • Иногда switch + инклуды в разы лучше MVC, я лучше напишу скрипт на инклуде, который будет стабильно работать при посещалке 450к на слабеньком вдс, чем платить бешеные деньги за дедик, зато счастлив как слон что сайт по шаблону MVC

  • Lion__ Видимо ты не совсем понял смысл использования паттерна MVC. Если это громадный проект, одними инклудами и свитч ты не обойдешься. Да и проект невозможно будет поддерживать.

  • На удивление понятная схема, редко где такую встретишь. Предлагаю всем кто интересуется конкретным примером простой MVC системы ознакомиться с материалом статьи:
    MVC – фундамент интернет магазина
    На блоге: LifeExample

    http://lifeexample.ru/php-primeryi-skriptov/mvc-fundament-internet-magazina.html

  • Вот на этом сайте четко рассказано что такое mvc в php

    http://mvcphp.ru/

You can follow any responses to this entry through the RSS 2.0 feed.