Изучая в последнее время вопросы современных подходов к web-программированию, я наткнулся на перевод довольно интересной статьи литовского программиста Юзеса Казиукенаса, посвящённой такому явлению, как PHP-frameworks, их появлению и эволюции.
Учитывая, что вопрос использования в своей работе framework’ов встаёт рано или поздно практически перед каждым программистом (а также беря во внимание то, что многие CMS или уже давно позиционируют себя как имеющие свой framework (CMF Drupal), или же движутся в эту сторону (как та же Joomla), мне захотелось поделиться с вами этой статьёй и обсудить то, как вы сами видите будущее web-программирования в общем и сайтостроения в частности.
Надеюсь, вам это будет интересно.
Итак, представляю вашему вниманию перевод интересной статьи литовского блогера и программиста Юзеса Казиукенаса (скорее бывшего литовского, так как Юзес прожил большую часть своего трудового стажа в США, а сейчас живет в Единбурге, Великобритания), и в которой он рассуждает о PHP-фреймворках с точки зрения перспективы.
Юзес кратко рассказывает о том, с чего начинались PHP-фреймворки и почему они важны сейчас. Далее, он заводит речь о следующем поколении PHP-фреймворков и о том, какие из них ему нравятся, а какие не очень. Например, в статье обсуждаются Zend Framework, Symfony и Lithium. Склонность Юзеса к Symfony очевидна, но это не искажает сути статьи. Стоит отметить, что Юзес один из разработчиков Zend Framework и Doctrine, имеет смысл иметь это в виду, анализируя его предпочтения.
Если вас интересует, что происходит в сфере PHP-фреймворков, вы просто обязаны прочитать эту статью.
Я работал с множеством систем и проектов за долгие годы своей жизни, большая часть которых была потрачена на PHP. Однако, лишь недавно я заметил, что начался важный исторический этап — новая эра PHP-фреймворков. Кажется, многое меняется в эти дни прямо у нас на глазах.
Я хочу обсудить здесь то, что я думаю о текущем положении дел, что в нем неправильно, и как новая банда PHP-фреймворков собирается менять ситуацию. 21 мая 2011 г. я выступал на Голландской PHP-конференции (Dutch PHP conference, DPC) как раз на эту тему и затем у меня состоялась весьма интересная дискуссия с некоторыми её участниками.
Взгляните сперва на эти слайды, иллюстрирующие мое выступление там. Конечно, имейте в виду, что без моих пояснений они не так хорошо выглядят, как хотелось бы. Поэтому эта статья представляет собой сокращенную версию того, о чем я говорил на конференции.
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-фреймворки также изменялись и росли, движимые обратной связью со стороны разработчиков, отзывами и пожеланиями. Через пару лет большинство людей уже были довольны, тем, что у нас было. Но если вы посмотрите внимательно, то в
PHP 4 поддерживался всеми фреймворками (и, как это не удивительно, все еще поддерживается некоторыми из них). Это стало причиной появления большого количества кода, который, в настоящее время, является морально устаревшим, особенно с точки зрения ООП-парадигмы. Попытки поддерживать его привели к усложнению реализации новых функций и исправления багов. Кроме того, все меньше и меньше разработчиков хотят работать с таким старым кодом.
Прежде всего, тогда было популярно использовать «магические» функции PHP (__get
, __call
и т.д.). На первый взгляд, ничего плохого в этом нет, но на самом деле они очень опасны.
Они делают API запутанным, автозавершение невозможным и, самое главное, они медленные. Их использовали, чтобы заставить PHP делать те вещи, которые он не хотел делать. И это работало. Но это могло привести к плохим последствиям.
Zend Framework в течении долгого времени был моим любимым фреймворком (и до сих пор им является для PHP 5.2), но самая главная проблема с ним в том, что он пытается весьма сложным способом быть... библиотекой компонентов. Другие фреймворки следуют тем же путем — вместо использования существующих библиотек, они написали свои собственные. Это привело к появлению огромного количества библиотек на PHP, подобных автономным библиотекам, но по прежнему требующих загрузки всей структуры фреймворка.
Итак, жирные и плохо cпроектированные фреймворки действительно раздражают. И не меня одного.
Для улучшения этой ситуации люди решили сделать несколько вещей. Главное — это переписать фреймворки с нуля на основе 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, т.к. им удалось привлечь огромное количество разработчиков (см. схему здесь).
Текущий темп очень быстрый, и по сравнению с темпом разработки несколькими годами ранее, фреймворки улучшаются намного быстрее. Много всего было удалено.
Прежде всего, того «волшебства», о котором я упоминал ранее, в настоящее время нет, и сейчас везде используются явные определения. Кроме того, сейчас превалируют взгляды на фреймворк, как на маленькое ядро и дополнительный функционал, поставляющийся в виде расширений и библиотек. Это отличный способ, чтобы с фреймворками было легче работать и уменьшить потребление памяти. Производительность была серьезной проблемой для фреймворков, и большинство из них включило эту проблему в планы своих новых релизов.
Front-end также получил много внимания в таких фреймворках, как Symfony. Ими обеспечивается помощь в управлении статическим контентом (JavaScript и CSS) и установкой для них надлежащих заголовков. Серверная сторона получила огромную пользу, избавившись от магии и очистив код, также PHP 5.3 обеспечил огромный прирост производительности.
Очевидно, что включены все новые возможности языка. Пространства имен, например.
Поддержка пространств имен ведет к необходимости создания и согласования нового подхода к автозагрузке, который будет работать в большинстве фреймворков.
Стандарты PSR-o (Professional Standards Review Organization) созданы раньше, но в настоящее время хорошо интегрированы в фреймворки. И вскоре анонимные функции тоже войдут в них.
Я не совсем уверен, что мне нравится растущий список фич, портированных непосредственно из среды Java. Java работает по-другому (и требует около 1 Гб оперативной памяти), так что даже DiC является сложным в PHP.
Посмотрим, насколько это повлияет на нас, но до сих пор я немного волновался, т.к. знаю, что 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.
Из недостатков: пугающие сорсы из-за необыного кодинг стайла и отсутствие 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
6 комментариев
Четкий перевод. Спасибо! Познавательно и интересно.
Хорошая статья, спасибо за перевод. Соглашусь, что Yii прекрасный фреймворк. Лично мне даже сам код и его оформление доставляют эстетическое наслаждение.
Спасибо, а здесь можно прочитать про Zend - http://plutov.by/
>>> Want to buy with Discount? CLICK HERE!
[url=http://totalworldstore.com/shop/go.php?sid=1] [u][b]>>> Want to buy with Discount? CLICK HERE!
Очень удачно я нашел. Подробная статья о популярных php фреймворков
Рекомендую к прочтению: https://use-web.ru/news.php?id=58&tid=2