Просмотров: 17847

Приход новой эры PHP-фреймворков


Изучая в последнее время вопросы современных подходов к web-программированию, я наткнулся на перевод довольно интересной статьи литовского программиста Юзеса Казиукенаса, посвящённой такому явлению, как PHP-frameworks, их появлению и эволюции.

Учитывая, что вопрос использования в своей работе framework’ов встаёт рано или поздно практически перед каждым программистом (а также беря во внимание то, что многие CMS или уже давно позиционируют себя как имеющие свой framework (CMF Drupal), или же движутся в эту сторону (как та же Joomla), мне захотелось поделиться с вами этой статьёй и обсудить то, как вы сами видите будущее web-программирования в общем и сайтостроения в частности.

Надеюсь, вам это будет интересно.

Итак, представляю вашему вниманию перевод интересной статьи литовского блогера и программиста Юзеса Казиукенаса (скорее бывшего литовского, так как Юзес прожил большую часть своего трудового стажа в США, а сейчас живет в Единбурге, Великобритания), и в которой он рассуждает о PHP-фреймворках с точки зрения перспективы.

Юзес Казиукенас PHP фреймворки frameworks будущее развития лучший выбор

Юзес кратко рассказывает о том, с чего начинались PHP-фреймворки и почему они важны сейчас. Далее, он заводит речь о следующем поколении PHP-фреймворков и о том, какие из них ему нравятся, а какие не очень. Например, в статье обсуждаются Zend Framework, Symfony и Lithium. Склонность Юзеса к Symfony очевидна, но это не искажает сути статьи. Стоит отметить, что Юзес один из разработчиков Zend Framework и Doctrine, имеет смысл иметь это в виду, анализируя его предпочтения.

Если вас интересует, что происходит в сфере PHP-фреймворков, вы просто обязаны прочитать эту статью.

Вступление

Я работал с множеством систем и проектов за долгие годы своей жизни, большая часть которых была потрачена на PHP. Однако, лишь недавно я заметил, что начался важный исторический этап — новая эра PHP-фреймворков. Кажется, многое меняется в эти дни прямо у нас на глазах.

Я хочу обсудить здесь то, что я думаю о текущем положении дел, что в нем неправильно, и как новая банда PHP-фреймворков собирается менять ситуацию. 21 мая 2011 г. я выступал на Голландской PHP-конференции (Dutch PHP conference, DPC) как раз на эту тему и затем у меня состоялась весьма интересная дискуссия с некоторыми её участниками.

PHP фреймворки frameworks будущее развития лучший выбор

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

Рождение фреймворков

6 лет назад состоялся релиз CakePHP, одного из первых PHP-фреймворков, и с тех пор мы повидали немало PHP-фреймворков.

В настоящее время их около... Их миллионы, и каждый из них со своей реализацией MVC (Model-View-Controller), DBAL (Database Abstract Layer) и шаблонизации.

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

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

Многие разработчики утверждают, что они знают ООП, но когда появились фреймворки, они были вынуждены доказывать это на деле (до этого вы могли хакать их как только вам вздумается). И фреймворки заставили PHP разработчиков задуматься о том, что такое ООП на самом деле и как оно работает. Попросите кого-нибудь сейчас использовать mysql_query и вы рискуете получить удар в лицо. Дважды. Потому что вы еще будете вынуждены использовать mysql_real_escape_string . Как это было сделано?

Вставка от автора блога
Лично я всегда использовал mysql_query , т.к. это самый простой, прозрачный и краткий способ выполнения SQL-запроса в MySQL под PHP. Иногда было влом каждый раз эскейпить строки перед вставкой их в SQL-запрос. Тогда писалась простая обертка над mysql_query вида safe_mysql_query($sql_template, $array_of_params) , состоящая из пары строчек. Зачем использовать сложный и тормозной фрэймворк там, где можно обойтись парой строчек простого кода?

Слышу уже возмущенные голоса, что вместо mysql_query лучше использовать библиотеки, предоставляющие prepared statements (например), т.к. это полностью ликвидирует все SQL injection'ы. Тогда советую сравнить объем и ясность кода, где используется mysql_query+mysql_real_escape_string (или вышеупомянутая обертка safe_mysql_query ), с кодом, где используются prepared statements из какой-нибудь библиотеки или фреймворка.

Prepared statements нужно использовать не для предотвращения sql injection'ов, а для того, чтобы быстро и эффективно выполнить много одинаковых запросов в цикле, отличающихся только передаваемыми параметрами. Хотя, чаще всего эффективнее преобразовать этот цикл в один SQL-запрос.

Disclaimer. С современными фреймворками под PHP не знаком, т.к. последний раз писал код на PHP в 2008 году. Тогда все известные фреймворки под PHP были на самом деле говнофреймворками. То же самое относилось и к исходникам самого PHP - это была просто аццкая жесть. Может, сейчас что-нибудь изменилось? Хотя, если судить по статьям типа этой, далеко PHP с тех пор не ушел.

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

Они либо последовали за существующими в других языках фреймворками (такими, как Ruby On Rails), либо придумали свои собственные идеи. Так как опыта никакого не было, большинство PHP-фреймворков до сегодняшнего дня есть наследие конструкций, известных каждому: плохих, но не поддающихся исправлению.

Прагматичный подход PHP-разработчиков здесь сильно помог — аналогично тому, как эволюционировал язык PHP, PHP-фреймворки также изменялись и росли, движимые обратной связью со стороны разработчиков, отзывами и пожеланиями. Через пару лет большинство людей уже были довольны, тем, что у нас было. Но если вы посмотрите внимательно, то в 2007-м у нас был Zend Framework 1.0, который, в сравнении с версией 1.11, обладал очень ограниченным набором возможностей. Таким образом, даже сегодня фреймворки быстро развиваются, чтобы удовлетворять всем текущим потребностям разработчиков.

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

Что не в порядке?

Прежде всего, тогда было популярно использовать «магические» функции PHP (__get , __call и т.д.). На первый взгляд, ничего плохого в этом нет, но на самом деле они очень опасны.

PHP фреймворки frameworks будущее развития лучший выбор

Они делают API запутанным, автозавершение невозможным и, самое главное, они медленные. Их использовали, чтобы заставить PHP делать те вещи, которые он не хотел делать. И это работало. Но это могло привести к плохим последствиям.

SCOP (Static Class Oriented Programming) — программирование, ориентированное на статические классы. Это термин, который я придумал, чтобы описать большую часть кода на PHP. Статические методы нехороши по множеству причин, я не собираюсь погружаться в это сегодня, но самое главное: если класс представляет собой просто набор статических методов — это далеко не ООП. Это просто использование класса как контейнера для функций. Есть даже целые фреймворки, которые практикуют это.

Zend Framework в течении долгого времени был моим любимым фреймворком (и до сих пор им является для PHP 5.2), но самая главная проблема с ним в том, что он пытается весьма сложным способом быть... библиотекой компонентов. Другие фреймворки следуют тем же путем — вместо использования существующих библиотек, они написали свои собственные. Это привело к появлению огромного количества библиотек на PHP, подобных автономным библиотекам, но по прежнему требующих загрузки всей структуры фреймворка.

Итак, жирные и плохо cпроектированные фреймворки действительно раздражают. И не меня одного.

Новая эра в 2011

Для улучшения этой ситуации люди решили сделать несколько вещей. Главное — это переписать фреймворки с нуля на основе PHP 5.3.

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

Я не использовал никаких фреймворков до появления CakePHP, поэтому его я и собираюсь использовать в качестве ориентира. На самом деле, я даже сомневаюсь, существовало ли что-нибудь до CakePHP, конечно, если вы не назовете Drupal - фреймворком. С момента рождения CakePHP и по настоящее время прошло 6 лет, которые я называю Первой эрой PHP-фреймворков.

2011 год знаменует начало Второй эры и совершенно новые вещи, которые, наконец, состоялись, в основном в форме релизов и анонсов.

Интересно, что в 2011 году PHP — это уже не PHP. Или, уже не только PHP. Стек LAMP скучен, и все меньше и меньше используется с новыми инструментами, такими как Nginx и CouchDB. Сегодня интеграция и взаимодействие являются важными элементами.

То же самое и для языка PHP 5.3 — это совершенно новый зверь, который делает возможной удивительную функциональность. Кроме того, если вы используете PHP 5.3, то нет никакой реальной необходимости обеспечивать поддержку обратной совместимости.

Давайте исправим все это в таком случае, не так ли?

После перемещения в GIT многих фреймворков, стало намного проще внести свой вклад в их разработку. Меня особенно впечатлили результаты Symfony, т.к. им удалось привлечь огромное количество разработчиков (см. схему здесь).

Текущий темп очень быстрый, и по сравнению с темпом разработки несколькими годами ранее, фреймворки улучшаются намного быстрее. Много всего было удалено.

PHP фреймворки frameworks будущее развития лучший выбор

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

Front-end также получил много внимания в таких фреймворках, как Symfony. Ими обеспечивается помощь в управлении статическим контентом (JavaScript и CSS) и установкой для них надлежащих заголовков. Серверная сторона получила огромную пользу, избавившись от магии и очистив код, также PHP 5.3 обеспечил огромный прирост производительности.

Новые возможности

Очевидно, что включены все новые возможности языка. Пространства имен, например.

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

Стандарты PSR-o (Professional Standards Review Organization) созданы раньше, но в настоящее время хорошо интегрированы в фреймворки. И вскоре анонимные функции тоже войдут в них.

Dependency injection containers и Annotations — две вещи, которые я хотел бы упомянуть здесь. Обе радикально изменят стиль вашего кода в лучшую сторону. Мне нравится их использовать, и Symfony прекрасно их использует, но и другие фреймворки догоняют и включат их в ближайшее время. Сочетание этих вещей, а также новых функций PHP позволяет создавать очень чистые и сбалансированные микро-фреймворки, взгляните хотя бы на такие три мини-шедевра: Silex, F3, Fat Free.

Я не совсем уверен, что мне нравится растущий список фич, портированных непосредственно из среды Java. Java работает по-другому (и требует около 1 Гб оперативной памяти), так что даже DiC является сложным в PHP.

PHP logo фреймворки frameworks будущее развития лучший выбор

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

И что теперь?

Zend Framework 2.0

Он находится на пути к релизу, но все же потребуется некоторое время.

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

Lithium

Вот-вот уже будет, находится в режиме разработки, но, кажется, уже довольно близок к готовности. Это совершенно отличный фреймворк от привычных нам PHP-фреймворков, так что хотелось бы его попробовать. Я наиболее впечатлен их реализацией AOP. Само собой, он поддерживает только PHP 5.3+, а кроме того CouchDB и MongoDb, что весьма приятно.

Symfony 2

На мой взгляд, является вожаком стаи. Финальный релиз вышел 28 июля 2011. Список функциональных возможностей труден для понимания, поэтому смотрите их на сайте Symfony. Назову лишь один термин — Bundles (связки). Bundles — это способ получить расширяемое приложение, с помощью внешних компонентов. Умные плагины. Рекомендую интересную статью по Sf2.

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

Вставка от автора блога
YII - лично для меня на данный момент это лучший РНР-фреймворк. В нише "не enterprise" IMHO лучший в связке с Zend в качестве библиотеки классов, отличная документация, туториалы и комьюнити (по крайней мере англоговорящее).

Из недостатков: пугающие сорсы из-за необыного кодинг стайла и отсутствие PR-воплей про DI. Некоторые сочтут недостатком собственную реализацию ORM, она неидеальна, но работать с ней мне нравится куда больше, чем с Doctrine 2 (может по большому счету из-за моей привычки работать с ActiveRecord, а не DataMapper, но не только, есть и другие факторы). По поводу DI: его вполне комфортно можно использовать и без контейнера как в sf2, в большинстве случаев этого будет достаточно, лично я не склонен называть это недостатком, тем более, что внедрять зависимости в YII довольно удобно благодаря CComponent... но это уже детали.

Некоторым YII покажется слишком грязным, да, местами наблюдается, но разработчики думаю не задавались целью написать сферически правильный фреймворк в вакууме. Жду версию 2.0, обещанная в 2011 году альфа-версия пока откладывается.

Последние sf2 & Doctrine2 на практике мне пока не нравится. Теоретически все круто: бандлы, доктрин, твиг, аннотации и все это вокруг DIC... но на практике уже столкнулся с парой открытых issues на гитхаб, плюс дебаг по сравнению с YII неудобен из-за очень большого кол-ва этого сгенеренного из декларативных частей приложения (имею в виду аннотации, yml) php-кода. Может позднее втянусь и проникнусь красотой всего этого, но сейчас считаю, что весь этот "enterprise level" и джавоподобные приемы по крайней мере очень сыры для использования их в серьезных проектах. А вообще в сознании тусуется мысль, что они скорее несостоятельны, сравнивая их с Джава, спринг, JPA, EJB...

Заключение

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

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

~

Англоязычный оригинал, слайды-презентация к статье (вернее, к выступлению на конференции по теме этой статьи), 2011

twitter.com facebook.com vkontakte.ru odnoklassniki.ru mail.ru ya.ru pikabu.ru blogger.com liveinternet.ru livejournal.ru google.com bobrdobr.ru yandex.ru del.icio.us

Подписка на обновления блога → через RSS, на e-mail, через Twitter
Теги: , , , ,
Эта запись опубликована: Вторник, 24 января 2012 в рубрике Программирование.

3 комментария

Следите за комментариями по RSS
  1. Николай

    Четкий перевод. Спасибо! Познавательно и интересно.

  2. Александр

    Хорошая статья, спасибо за перевод. Соглашусь, что Yii прекрасный фреймворк. Лично мне даже сам код и его оформление доставляют эстетическое наслаждение.

  3. Спасибо, а здесь можно прочитать про Zend - http://plutov.by/

Оставьте комментарий!

Не регистрировать/аноним

Используйте нормальные имена. Ваш комментарий будет опубликован после проверки.

Зарегистрировать/комментатор

Для регистрации укажите свой действующий email и пароль. Связка email-пароль позволяет вам комментировать и редактировать данные в вашем персональном аккаунте, такие как адрес сайта, ник и т.п. (Письмо с активацией придет в ящик, указанный при регистрации)

(обязательно)


⇑ Наверх
⇓ Вниз