Здравствуйте, друзья!
Изучая вопросы современных подходов к web-программированию, я наткнулся на перевод довольно интересной статьи литовского программиста Юзеса Казиукенаса, посвящённой такому явлению, как PHP-frameworks, их появлению и эволюции. Учитывая, что вопрос использования в своей работе framework'ов встаёт рано или поздно практически перед каждым программистом (а также беря во внимание то, что многие CMS или уже давно позиционируют себя как имеющие свой framework (CMF Drupal), или же движутся в эту сторону (как та же Joomla), мне захотелось поделиться с вами этой статьёй и обсудить то, как вы сами видите будущее web-программирования в общем и сайтостроения в частности. Надеюсь, вам это будет интересно :)
Приятного чтения!
Представляю вашему вниманию перевод интересной статьи литовского блогера и программиста Юзеса Казиукенаса, в которой он рассуждает о PHP фреймворках. Юзес кратко рассказывает о том, с чего начинались PHP фреймворки и почему они важны сейчас. Далее, он заводит речь о следующем поколении PHP фреймворков и о том, какие из них ему нравятся, а какие не очень. Например, в статье обсуждаются Zend Framework, Symfony и Lithium. Склонность Юзеса к Symfony очевидна, но это не искажает сути статьи.
Если вас интересует, что происходит в сфере 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. Как это было сделано?
Никто точно не знал, какими должны быть PHP фреймворки. И какие у них должны быть возможности. Так как же людям удалось сделать то, что произошло?
Они либо последовали за существующими в других языках фреймворками (такими, как Ruby On Rails), либо придумали свои собственные идеи. Так как опыта никакого не было, большинство PHP фреймворков до сегодняшнего дня есть наследие конструкций, известных каждому: плохих, но не поддающихся исправлению.
Прагматичный подход PHP разработчиков здесь сильно помог - аналогично тому, как эволюционировал язык PHP, PHP фреймворки также изменялись и росли, движимые обратной связью со стороны разработчиков, отзывами и пожеланиями. Через пару лет большинство людей уже были довольны, тем, что у нас было. Но если вы посмотрите внимательно, то в 2007-м у нас был Zend Framework 1.0, который, в сравнении с версией 1.11, обладал очень ограниченным набором возможностей. Таким образом, даже сегодня фреймворки быстро развиваются, чтобы удовлетворять всем потребностям разработчиков.
PHP 4 поддерживался всеми фреймворками (и, как это не удивительно, все еще поддерживается некоторыми из них). Это стало причиной появления большого количества кода, который, в настоящее время, является морально устаревшим, особенно ООП парадигмы. Попытки поддерживать его привели к усложнению реализации новых функций и исправления багов. Кроме того, все меньше и меньше разработчиков хотят работать с таким старым кодом.
Что не в порядке?
Прежде всего, тогда было популярно использовать "магические" функции PHP (__get, __call и т.д.). На первый взгляд, ничего плохого в этом нет, но на самом деле они очень опасны. Они делают API запутанным, автозавершение невозможным и, самое главное, они медленные. Их использовали, чтобы заставить PHP делать те вещи, которые он не хотел делать. И это работало. Но это могло привести к плохим последствиям.
SCOP (Static Class Oriented Programming) - программирование, ориентированное на статические классы. Это термин, который я придумал, чтобы описать большую часть кода на PHP. Статические методы нехороши по множеству причин, я не собираюсь погружаться в это сегодня, но самое главное: если класс представляет собой просто набор статических методов - это далеко не ООП. Это просто использование класса как контейнера для функций. Есть даже целые фреймворки, которые практикуют это.
Zend Framework в течении долгого времени был моим любимым фреймворком (и до сих пор им является для PHP 5.2), но самая главная проблема с ним в том, что он пытается слишком сложно быть библиотекой компонентов. Другие фреймворки следуют тем же путем - вместо использования существующих библиотек, они написали свои собственные. Это привело к появлению огромного количества библиотек на PHP, подобных автономным библиотекам, но по прежнему требующих загрузки всей структуры фреймворка. Жирные фреймворки действительно раздражают.
Новая эра в 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, т.к. им удалось привлечь огромное количество разработчиков (см. схему здесь).
Текущий темп очень быстрый, и по сравнению с темпом разработки несколькими годами ранее, фреймворки улучшаются намного быстрее.
Много всего было удалено.
Прежде всего, того "волшебства", о котором я упоминал ранее, в настоящее время нет, и сейчас везде используются явные определения. Кроме того, сейчас превалируют взгляды на фреймворк, как на маленькое ядро и дополнительный функционал, поставляющийся в виде расширений и библиотек. Это отличный способ, чтобы с фреймворками было легче работать и уменьшить потребление памяти. Производительность была серьезной проблемой для фреймворков, и большинство из них включило эту проблему в планы своих новых релизов.
Front-end также получил много внимания в таких фреймворках, как Symfony. Ими обеспечивается помощь в управлении статическим контентом (JavaScript и CSS) и установкой для них надлежащих заголовков. Серверная сторона получила огромную пользу, избавившись от магии и очистив код, также PHP 5.3 обеспечил огромный прирост производительности.
Новые возможности
Очевидно, что включены все новые возможности языка. Пространства имен, например. Поддержка пространств имен ведет к необходимости создания и согласования нового подхода к автозагрузке, который будет работать в большинстве фреймворков.
Стандарты PSR-o (Professional Standards Review Organization) созданы раньше, но в настоящее время хорошо интегрированы в фреймворки. И вскоре анонимные функции тоже войдут в них.
Dependency injection containers и Annotations - две вещи, которые я хотел бы упомянуть здесь. Обе изменят стиль вашего кода. Мне нравится их использовать, и Symfony прекрасно их использует, но и другие фреймворки догоняют и включат их в ближайшее время. Сочетание этих вещей, а также новых функций PHP позволяет создавать очень чистые микро-фреймворки, взгляните на Silex.
Я не совсем уверен, что мне нравится растущий список фич, портированных непосредственно из среды 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 - это способ получить расширяемое приложение, с помощью внешних компонентов. Умные плагины.
Здравствуйте, друзья!
Изучая вопросы современных подходов к web-программированию, я наткнулся на перевод довольно интересной статьи литовского программиста Юзеса Казиукенаса, посвящённой такому явлению, как PHP-frameworks, их появлению и эволюции. Учитывая, что вопрос использования в своей работе framework'ов встаёт рано или поздно практически перед каждым программистом (а также беря во внимание то, что многие CMS или уже давно позиционируют себя как имеющие свой framework (CMF Drupal), или же движутся в эту сторону (как та же Joomla), мне захотелось поделиться с вами этой статьёй и обсудить то, как вы сами видите будущее web-программирования в общем и сайтостроения в частности. Надеюсь, вам это будет интересно :)
Приятного чтения!
6 лет назад состоялся релиз CakePHP, одного из первых PHP фреймворков, и с тех пор мы повидали немало PHP фреймворков.
В настоящее время их около... Их миллионы, и каждый из них со своей реализацией MVC (Model-View-Controller), DBAL (Database Abstract Layer) и шаблонизации.
Они мне нравятся, даже если у них есть свои странности, но все же их принятие не носит массового характера. Если вы посмотрите на количество проектов с открытым кодом, базирующихся на фреймворках, вы обнаружите всего несколько примеров. Это печально.
Частично причина в том, что многие из этих проектов были выпущены еще до того, как появились PHP фреймворки, а частично в том, что для того чтобы начать работать с PHP фреймворками, требуется время на их изучение. Таким образом, если проект будет основан на фреймворке, то он приведет к неизбежному увеличению кривой обучения, по крайней мере, в большинстве случаев.
Многие разработчики утверждают, что они знают ООП, но когда появились фреймворки, они были вынуждены доказывать это на деле (до этого вы могли хакать их как только вам вздумается). И фреймворки заставили PHP разработчиков задуматься о том, что такое ООП на самом деле и как оно работает. Попросите кого-нибудь сейчас использовать mysql_query и вы рискуете получить удар в лицо. Дважды. Потому что вы еще будете вынуждены использовать mysql_real_escape_string. Как это было сделано?
Никто точно не знал, какими должны быть PHP фреймворки. И какие у них должны быть возможности. Так как же людям удалось сделать то, что произошло?
Они либо последовали за существующими в других языках фреймворками (такими, как Ruby On Rails), либо придумали свои собственные идеи. Так как опыта никакого не было, большинство PHP фреймворков до сегодняшнего дня есть наследие конструкций, известных каждому: плохих, но не поддающихся исправлению.
Прагматичный подход PHP разработчиков здесь сильно помог - аналогично тому, как эволюционировал язык PHP, PHP фреймворки также изменялись и росли, движимые обратной связью со стороны разработчиков, отзывами и пожеланиями. Через пару лет большинство людей уже были довольны, тем, что у нас было. Но если вы посмотрите внимательно, то в 2007-м у нас был Zend Framework 1.0, который, в сравнении с версией 1.11, обладал очень ограниченным набором возможностей. Таким образом, даже сегодня фреймворки быстро развиваются, чтобы удовлетворять всем потребностям разработчиков.
PHP 4 поддерживался всеми фреймворками (и, как это не удивительно, все еще поддерживается некоторыми из них). Это стало причиной появления большого количества кода, который, в настоящее время, является морально устаревшим, особенно ООП парадигмы. Попытки поддерживать его привели к усложнению реализации новых функций и исправления багов. Кроме того, все меньше и меньше разработчиков хотят работать с таким старым кодом.
Прежде всего, тогда было популярно использовать "магические" функции PHP (__get, __call и т.д.). На первый взгляд, ничего плохого в этом нет, но на самом деле они очень опасны. Они делают API запутанным, автозавершение невозможным и, самое главное, они медленные. Их использовали, чтобы заставить PHP делать те вещи, которые он не хотел делать. И это работало. Но это могло привести к плохим последствиям.
SCOP (Static Class Oriented Programming) - программирование, ориентированное на статические классы. Это термин, который я придумал, чтобы описать большую часть кода на PHP. Статические методы нехороши по множеству причин, я не собираюсь погружаться в это сегодня, но самое главное: если класс представляет собой просто набор статических методов - это далеко не ООП. Это просто использование класса как контейнера для функций. Есть даже целые фреймворки, которые практикуют это.
Zend Framework в течении долгого времени был моим любимым фреймворком (и до сих пор им является для PHP 5.2), но самая главная проблема с ним в том, что он пытается слишком сложно быть библиотекой компонентов. Другие фреймворки следуют тем же путем - вместо использования существующих библиотек, они написали свои собственные. Это привело к появлению огромного количества библиотек на PHP, подобных автономным библиотекам, но по прежнему требующих загрузки всей структуры фреймворка. Жирные фреймворки действительно раздражают.
После перемещения в GIT многих фреймворков, стало намного проще внести свой вклад в их разработку. Меня особенно впечатлили результаты Symfony, т.к. им удалось привлечь огромное количество разработчиков (см. схему здесь).
Текущий темп очень быстрый, и по сравнению с темпом разработки несколькими годами ранее, фреймворки улучшаются намного быстрее.
Много всего было удалено.
Прежде всего, того "волшебства", о котором я упоминал ранее, в настоящее время нет, и сейчас везде используются явные определения. Кроме того, сейчас превалируют взгляды на фреймворк, как на маленькое ядро и дополнительный функционал, поставляющийся в виде расширений и библиотек. Это отличный способ, чтобы с фреймворками было легче работать и уменьшить потребление памяти. Производительность была серьезной проблемой для фреймворков, и большинство из них включило эту проблему в планы своих новых релизов.
Front-end также получил много внимания в таких фреймворках, как Symfony. Ими обеспечивается помощь в управлении статическим контентом (JavaScript и CSS) и установкой для них надлежащих заголовков. Серверная сторона получила огромную пользу, избавившись от магии и очистив код, также PHP 5.3 обеспечил огромный прирост производительности.
Очевидно, что включены все новые возможности языка. Пространства имен, например. Поддержка пространств имен ведет к необходимости создания и согласования нового подхода к автозагрузке, который будет работать в большинстве фреймворков.
Стандарты PSR-o (Professional Standards Review Organization) созданы раньше, но в настоящее время хорошо интегрированы в фреймворки. И вскоре анонимные функции тоже войдут в них.
Dependency injection containers и Annotations - две вещи, которые я хотел бы упомянуть здесь. Обе изменят стиль вашего кода. Мне нравится их использовать, и Symfony прекрасно их использует, но и другие фреймворки догоняют и включат их в ближайшее время. Сочетание этих вещей, а также новых функций PHP позволяет создавать очень чистые микро-фреймворки, взгляните на Silex.
Я не совсем уверен, что мне нравится растущий список фич, портированных непосредственно из среды 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 - это способ получить расширяемое приложение, с помощью внешних компонентов. Умные плагины.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.