Новая эра PHP фреймворков

27 комментариев
Новая эра PHP фреймворков
Здравствуйте, друзья! Изучая вопросы современных подходов к 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 - это способ получить расширяемое приложение, с помощью внешних компонентов. Умные плагины.

Заключение

Я очень рад тому, что сейчас происходит в PHP индустрии, и я полагаю, все это приведет к большим достижениям. Наконец-то настало время, когда мы можем выбросить большую часть из нашего старого наследия и реализовать свежие идеи. Спустя 5 лет, мы будем также возбуждены, как и сейчас. Источник: http://trish.in/article/php-frameworks Оригинал: http://blog.webspecies.co.uk/2011-05-23/the-new-era-of-php-frameworks.html Слайды: http://www.slideshare.net/juokaz/the-new-era-of-php-frameworks-dpc

Горячие события

Конкурс EY Entrepreneur Of The Year 2020
31 мая — 31 мая

Конкурс EY Entrepreneur Of The Year 2020

ISsoft Insights 2020
6 июня — 6 июня

ISsoft Insights 2020

Минск
GoWayFest 4.0
11 июля — 11 июля

GoWayFest 4.0

Минск

Читайте также

Состоялся релиз PHP 7.4
Состоялся релиз PHP 7.4

Состоялся релиз PHP 7.4

Уязвимость PHP7 подвергает сайты риску удалённого взлома
Уязвимость PHP7 подвергает сайты риску удалённого взлома

Уязвимость PHP7 подвергает сайты риску удалённого взлома

3 комментария
7 языков программирования, которые стоит изучать в 2019 году
7 языков программирования, которые стоит изучать в 2019 году

7 языков программирования, которые стоит изучать в 2019 году

5 комментариев
Python назвали самым популярным языком программирования
Python назвали самым популярным языком программирования

Python назвали самым популярным языком программирования

Обсуждение

Андрей Семиков
Андрей Семиков Software engineer в Godel Technologies Europe
0

Понравилось то, как описана эволюция фреймворков. Сколько внимания уделяется magic методам на собеседованиях, хотя по сути использовал их один раз за все время работы.

-1

упоминание такого говна как джумла и друпал не может быть уместно в посте с такими штуками как зенд и симфони

Ратмир (Максим) Новиков
Ратмир (Максим) Новиков Project Manager в Andersen
1

У сьвеце гэтага артыкулу было б цікава пачуць больш разгорнуты адказ, чаму ты лічыш Drupal і Joomla - ня вартымі ўзгадваньня :) На твой погляд у іх няма будучыні? Ці цябе проста не падабаецца, як зроблены гэтыя сістэмы? Ня трэба забывацца яшчэ й аб тым, што любы framework/CMS - гэта толькі інструманты, кожны са сваімі асаблівасьцямі. І тое, што падабаецца праграмістам, зусім не абавязкова спадабаецца бізнэсу (ад якога праграмісты, што не кажы, у пэўным сэнсе залежаць). Можна разглядзець гэта пытаньне з розных пунктаў гледжаньня, каб зразумець, якая будучыня насамрэч нас чакае, і на што мае сэнс арыентавацца. Той жа Бітрыкс, як бы яго не гнабілі, жыве сабе далей і трымае перашае месца сярод платных CMS рунэта.

-1

спадар Ратмір, для больш разгорнутага адказу, трэба было бы вам пачытаць зыходныя коды гэтых падробак, так бы мовіць. Калі ў пхп можа існаваць дрэнны стыль напісаньня коду, то гэта друпал\джумла. Працэдурнае праграмаваньне, 100Мб коду, пры чым нікчэмнага, магчыма з-за гэтага і пхп не лічыцца сур'ёзная мовай.

Ратмир (Максим) Новиков
Ратмир (Максим) Новиков Project Manager в Andersen
1

Спадар otone, я ўжо чытаў зыходнікі Joomla, а зараз чытаю зыходнікі Bitrix, таму мяне складана чымсьці спужаць :) Але факт у тым, што гэтымі сістэмамі карыстаюцца, і карыстаюцца мільёны людзей, таму з гэтым прыходзіцца лічыцца. Зразумела, заўсёды павінны быць ідэялы, да якіх трэба імкнуцца, але пры гэтым усё роўна прыйдзецца на шляху да іх зрабіць шмат памылак. Дарэчы, калі б не было падобных "падробак", можа й разьвіцьцё такім праэктаў, як Symfony, ішло куды больш павольна: часам каштоўна ведаць ня толькі, як трэба рабіць, але й як ня трэба ;)

І ўсё ж такі, вяртаючыся да артыкулу, - як ты лічаш, як будзе далей разьвівацца гэта сьфера? Калі CMS імкнуцца стаць CMF, а framework'і пры гэтым даюць усё больш гнуткасьці й універсальнасьці ў распрацоўцы, што нас чакае далей? На мой погляд сучасныя framework'і нагадваюць жалезны канструктар, які быў раней у продажы: там было шмат дэталяў, якія злучаліся вельмі проста (з дапамогай шворанаў :), і зь якіх можна было зрабіць па сутнасьці любую канструкцыю, але гэта патрабавала ўяўленьняў аб архітэктуры й прынцыпах яе пастраеньня. CMS жа - гэта больш як Lego: здаецца, і зрабіць нешта можна, але ўсё абмежавана стандартнымі памерамі й усё роўна будзе прастакутным, ніякай табе элегантнасьці, а каб зрабіць нешта незвычайнае - трэба вельмі моцна выкручвацца.

1

мiльёны мух не могуць памыляцца, а то

Ратмир (Максим) Новиков
Ратмир (Максим) Новиков Project Manager в Andersen
-1

Ад мільёна мух адмахвацца стамішся, таму цяжка не ўлічваць іх наяўнасьць ;)

agentcooper
agentcooper PM в SK hynix memory solutions Eastern Europe
1

Понравились обе последних реплики :)

1

работы невпроворот и без них.

1

Калі вашасьць цікавіць мая экспэртная думка, то я думаю так:
cms --- гэта сістэмы для аднаціпных задач - разгарнуць блёг, проста блёг, ці нешта падобнае, а таксама гэта ўсё зроблена для людзей, якія не праграмісты, ім не трэба ведаць, што там унутры, толькі трэба каб работала больш-меньш добра, якасна.
Калі вам трэба нейкія рэчы рэалізаваць, то тут канешне, лепей рабіць фрэймворку, бо будзе лепш бачна, што ды як там. Таксама хацелася бы адзначыць тое, што самі фрэймворкі і зэнд і сымфоні2, гэта рэчы для хуткай разгорткі, таксама як і рэілс, напрыклад для стратапаў, лепш і хутчэй напісаць усё на php\ruby, а потым гледзячы, як ідзе працэс, перапісаць на java\.net.
А такія рэчы як друпал, якія і cms і фрэймворк, гэта лайно, такое не магчыма. Не можа быць і тое і тое адначасова.

Таксама бы хацелася каб заўважылі важную думку з артыкулу - LAMP ужо не трэба, гэта старая тэхналёгія. Магчыма з-за таго ў пхп нічога не зьмянілася, і не хоча зьмяняцца, што проста не было канкурэнцыі (перл не канкурэнт, а на java трэба яшчэ напісаць, там ж статыка, як страшна жыць ;) ), а таксама, пхп-нікі не зьвярталі ўвагі на такія рэчы, як redis, mongo і падобнае, але зараз калі зьявіліся моцныя фрэймворкі на рубі\пітон (толькі пра рубі магу казаць, у якога gem\ы ёсьць на любы выпадак жыцьця), распрацоўшчыкам пхп трэба будзе палкапаціцца, каб не згубіць рынак.

Тут ужо заўважылі, што не хапае yii, але я таксама магу казаць (не першы раз ужо)))), што не хапае і fuel ----> http://fuelphp.com/ але ён зьявіўся ці летам ці ў пачатку восені, не памятую.

Ратмир (Максим) Новиков
Ратмир (Максим) Новиков Project Manager в Andersen
1

Дзякую за адказ, сапраўды вельмі цікава. Але як быць з тым, што, калі мы кажам аб працы на web-студзіі, то нам сапраўды ў большасьці выпадкаў даводзіцца рабіць нешта больш-меньш стандартнае, і рабіць хутка. Распрацоўваць кожны сайт "з нуля" - звычайна немэтазгодна й дорага; карыстацца гатовай CMS - магчыма, але ўзьнікаюць пытаньні з тым, наколькі складана яе будзе дапрацоўваць (але кліенты пры гэтым пішчаць "Бітрыкс, дайце Бітрыкс!" - маркетынг працуе ;); карыстацца "студыйнай CMS", распрацаванай намі ж і адаптаванай пад нашыя патрэбы - звычайна так і робіцца, толькі ў кліентаў часам узнікаюць сумненьні, як бы не прывязвацца да адной студыі (і гэта пры тым, што дробныя дапрацоўкі можна зрабіць у любым кодзе, а пад нешта істотнае ўсё роўна прыйдзецца пісаць "з нуля" на іншай сістэме). Пакуль што найлепшы варыянт, які мне бачыцца ў такім выпадку: распрацоўваць сваю CMS, але на добрым (і папулярным, што таксама важна!) framework'е і з максімальным выкарыстаньнем гатовых модуляў, plugin'аў і бібліятэк, каб у якімсьці выпадку пытаньне з падтрымкай і дапрацоўкай нават староньнімі людзьмі можна было б вырашыць досыць проста.

0

няма за што, калі ласка.

Сапраўды, самы лепшы варыянт гэта свая кмс на фрэймворку. Таксама з'яўляецца праўдай і тое, што нешта істотнае прыйдзецца пісаць "з нуля".
Але мне падаецца, што кліенту трэба толькі ведаць, што сайт на пхп, а на чым канкрэтна фрэймфорк ці кмс, гэта ўжо другаснае пытаньне.

Ратмир (Максим) Новиков
Ратмир (Максим) Новиков Project Manager в Andersen
0

> Кліенту трэба толькі ведаць, што сайт на пхп, а на чым канкрэтна
> фрэймфорк ці кмс, гэта ўжо другаснае пытаньне.

Вельмі хацелася б, калі б так сапраўды было, але... кожны ж лічыць сабе "спецыялістам", вось і прыходзяць даволі часта кліенты з упэўненасьцю, што ім трэба сайт менавіта на ... (зараз звычайна падстаўляюць слова "Бітрыкс"), таму што ... (і далей пералічваюць стэрыатыпы, якія прысутнічаюць у іх асяроддзі). Атрымліваецца, калі ёсьць жаданьне працаваць са сваёй сістэмай, прыйдзецца пераконваць кліентаў у тым, што насамрэч ... (і далей тлумачэньні, якія павінны быць зразумелымі й істотнымі для кліента). Таму тут часам узнікаюць супрацьрэчча паміж бізнэсам (якому цікава атрымаць грошы за заказ) і праграмістамі (якім цікава, акрамя грошай, яшчэ й атрымліваць хоць нейкае задавальненьне ад працэсу ;). Вось і цікава, наколькі атрымаецца пры такім падыходзе зрабіць так, каб усе былі задавольнены :)

0

гні сваю лінію, ці ўсё жыцьцё з бітрыксам будзеш змагацца)

Anonymous
Anonymous CEO в Acobby Ltd
1

Ссылкой на оригинал поделитесь, плс.
Да и ссылки из статьи можно было бы сохранить. Например вот на эти слайды, которые упоминаются в статье http://www.slideshare.net/juokaz/the-new-era-of-php-frameworks-dpc

Ратмир (Максим) Новиков
Ратмир (Максим) Новиков Project Manager в Andersen
-1

Артыкул: http://blog.webspecies.co.uk/2011-05-23/the-new-era-of-php-frameworks.html

Слайды: http://www.slideshare.net/juokaz/the-new-era-of-php-frameworks-dpc

Спасылкі дапісаў унізе артыкула, дзякую за нагадваньне ;)

Ратмир (Максим) Новиков
Ратмир (Максим) Новиков Project Manager в Andersen
0

Што датычыцца Symfony 2, ёсьць яшчэ вельмі цікавы артыкул ад Fabien Potencier - http://fabien.potencier.org/article/49/what-is-symfony2. Наколькі я разумею, найбольш поўная рэалізацыя ўсіх закладзеных задумак будзе ў версіі 2.1, якую плануецца выпусьціць недзе ў сакавіку 2012, да таго ж часу абяцаюць разабрацца з большасьцю "securety issuse" другой версіі, якія пакуль што крыху падвіслі. Але ў любым выпадку Symfony 2 - гэта тое, што немагчыма не заўважыць ;)

-1

Проблема всех РНР фреймвокров - это собственно сам РНР. Он очень изменился за последнее время, да и вообще, приобрел много того, для чего изначально создан не был. Вот разработчикам и приходиться теперь выбирать либо
\Сделать\Все\Красиво либо Сделать_Обратную_Совместимость. В связи с этим и эти цифры 2 в фреймворках. Однако, некоторые все равно будет тяжело переделать. Я больше всего общался с Zend, чуть смотрел другие...ничего не нравилось. Помню, в потоке эмоций, начал писать свой. По Фрейду :) ни одного майджик метода, ни одного синглтона и статика, структуру продумал)) Только потом потом начал Java'ой заниматься, там ребята уже все написали(( Сейчас наверное у Symfony должно что-то получиться, хотя еще интересно, что Zend будет делать, там очень интересные пропозалы были, но тоже - кардинально структуру менять нужно.

0

php фреймворки - либо быстрые, либо хорошие/удобные :)

Хотя возможно это всех языков касается.

1

Писать свой это правильно и полезно :) Много нового узнаешь, интересного. Видишь вещи с другой стороны, часто наконец понимаешь почему это должно быть так, а не иначе.
У нас на проекте свой собственный был, проект шел с плэйн кода, так что для удобства пришлось все делать самим. Сначала функции, потом объекты. Хотя все равно в зачаточном состоянии остался.
Думал зенд прикрутить, но он тот еще монстрик. И чересчур много изменений требуется.
Насчет проектов опен соурс хорошо замечено - почти все древнее :)

-1

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

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

Prepared statements ( http://en.wikipedia.org/wiki/Prepared_statement ) нужно использовать не для предотвращения sql injection'ов, а для того, чтобы быстро и эффективно выполнить много одинаковых запросов в цикле, отличающихся только передаваемыми параметрами . Хотя, обычно бывает эффективнее преобразовать этот цикл в один SQL запрос.

Disclaimer. С современными фреймворками под пхп не знаком, т.к. последний раз писал код на пхп в 2006 году. Тогда все известные фреймворки под пхп были на самом деле говнофреймворками. То же самое относилось и к исходникам самого php - это была аццкая жесть. Может, сейчас что-нибудь изменилось. Хотя, если судить по статьям типа http://nikic.github.com/2011/12/12/How-big-are-PHP-arrays-really-Hint-BIG.html , далеко пхп не ушел.

1

сапразды далёка не пайшоў

-1

Согласен с автором - всё так и есть. Жду у себя в блоге - http://nextov.ru/

0

Интересная статья даже для весьма далекого от программирования и пхп человека. Но вот скажите мне, знатоки чайнику, с какого такого перепуду в статье не упоминаются ни CodeIgniter ни Kohana? Если по вашему (как и автора?) мнению, это ниразу не frameworks, то просьба пояснить с этого места поподробнее.
Во всяком случае, прочитанное про Kohan-у весьма впечатлило на первый взгляд: "...PHP5 веб-фреймворк с открытым кодом, который использует архитектурную модель HMVC (Hierarchical Model View Controller - Иерарархические Модель-Контроллер-Вид). Его цели — быть безопасным, легким и простым в использовании". И еще "Особенности
Высокая безопасность
«Лёгкий» код (не загроможден лишними операциями)
Прост в понимании
Использует модель MVC
100 % совместимость с UTF-8
Очень легко расширяем
[править]
Технологии:
Строгое Объектно-ориентированное программирование, реализованное на PHP5
Простая абстракция базы данных c использованием SQL драйверов".
Заранее благодарю за идеи.

0

Уважаемый Ratmir, тырить статью без зазрения совести и буква в букву нехорошо. Можно было по крайней мере спросить разрешения.

Ратмир (Максим) Новиков
Ратмир (Максим) Новиков Project Manager в Andersen
0

Уважаемый trishin, я ничего и ни у кого не "тырил", так что моя совесть вполне спокойна. Неужели из введения ("Изучая вопросы современных подходов к web-программированию, я наткнулся на перевод довольно интересной статьи литовского программиста Юзеса Казиукенаса...мне захотелось поделиться с вами этой статьёй и обсудить...") и заключения (Источник: http://trish.in/article/php-frameworks, Оригинал: http://blog.webspecies.co.uk/2011-05-23/the-new-era-of-php-frameworks.html, Слайды: http://www.slideshare.net/juokaz/the-new-era-of-php-frameworks-dpc) не достаточно ясно, что это не мой перевод, а просто интересный материал, которым я захотел поделиться с участниками dev.by? Или вы принципиальный противник "перепоста", даже при сохранении авторства и наличии всех обратных ссылок? Если так, то приношу свои извинения, мне почему-то кажется, что это вполне нормальная практика, тем более что статья не была использована в коммерческих или иных корыстных целях, а лишь явилась ещё одним "кирпичиком" в стене профессионального роста читающих этот ресурс людей. Думаю, если каждый человек будет связываться с автороми всех статей, которые он публикует в своём блоге или на публичных ресурсах, то мы уже через пару месяцев потонем в этой бюррократической волоките. Возможно, однако, я что-то не так понял, и вы говорите о чём-то другом? Тогда, прошу, поясните свою позицию, чтобы я мог адекватно ответить.

0

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