После полного прочтения блога Ивана Сагалаева, у меня возникла мысль, что надо бы поискать фреймворки для PHP. Все же интересно, насколько они ускоряют процесс разработки приложений/сайтов и увеличивают удобство работы вообще. Сказано - сделано. При разборе запросов гугля я наткнулся на 2 статейки (одна и вторая), в которых было представлено 2 субъективных взгляда на существующие PHP фреймворки.
В обоих статьях больше всего (как мне показалось), хвалили Symfony. Также мне приглянулись Zend Framework (от разработчиков PHP) и Prado (.NET-подобный фреймворк, ориентированный на обработку event’ов).
Symphony
Наверное, один из лучших фреймворков для PHP (блин, надоело, далее будет просто “пхп”), построенный на принципах ROR (о нем я уже чуть-чуть писал). Он использует сторонние разработки (Propel для ORM, Creole для работы с БД и т.д.), “объединяя” их в одно целое. Здесь действительно есть очень многое, НО, по-моему, фреймворк ОЧЕНЬ сложен для новичков. Прочитав начало их документации (end-user которая), стало понятно, что МНЕ такое использовать либо еще рановато, либо вообще не стоит. Скорее всего второе :)
Prado
Общение с фреймворком закончилось после прочтения документации. Задумка хорошая (как я узнал позже, она сюда перекочевала из asp.net), но меня она не устроила в принципе. Мне ото фреймворка нужно было немного другое (да, каюсь, с MVC-паттерном я знаком лишь очень отдаленно, никогда его не использовал и узнал о нем, собственно, из блога SM.org).
Zend Framework
Фреймворк от разработчиков пхп. Как мне кажется, в него комманда зенда решила вложить то, чего не хватало самому языку пхп, правда в некоторых моментах они перестарались (сделайте Zend::dump() от строки с русскими буквами в юникоде), но все же пользоваться фреймворком, как по мне, вполне удобно. Он содержит много разных вещей, с помощью которых можно делать многие вещи гораздо удобнее. Им я сейчас и пользуюсь.
Кстати, заметил за собой такую “штуку” - вот сделал что-то с этим фреймворком, теперь мне как-то без него неуютно… Что посоветуете/скажете по этому поводу?
Сейчас зенд находится в стадии beta. Многие вещи еще будут переделываться (особенно это касается тех вещей, которые сейчас находятся в incubator’е), но им УЖЕ можно пользоваться и он РЕАЛЬНО помогает.
Чего не то, чтобы не хватает, а что хотелось бы увидеть в этом фреймворке - так это ORM, потому как сейчас ее нет даже в инкубаторе, а жаль.
Я думаю, я еще вернусь к этой теме.
January 31st, 2007 at 13:30
Надо бы попробовать сию вещь :)
February 1st, 2007 at 19:17
За zend framework будущее. Стоит хотя бы заглянуть в исходники и всё становится понятно. Правда насчет ORM ты абсолютно прав.
А в MVC паттерне сложно ничего нет. Могу поспорить ты его используешь уже сейчас. Просто в немного извращеной форме =)
Спасибо за пост. Побольше бы про пхп ;)
February 1st, 2007 at 23:36
sas171
Если б они еще PHP доделывали, было бы вообще супер. Сделали бы классы date-time, string (нормальный) встроенными напрямую в пхп…
Т.е. чтобы вместо набора функций в пхп был набор классов с методами…
March 4th, 2007 at 16:27
посмотрите ещё и code igniter
на мой взгляд для стандартных задач этот фреймворк подходит лучше остальных…
March 4th, 2007 at 18:48
Слышал я о нем. Только когда обзор писался мне “пришлись по духу” эти три фреймворка, а сейчас времени нет еще обозревать. Как разберусь немного с учебой - продолжу. Надеюсь, это будет кому-нибудь нужно…
PS. Что понимается под “стандартными задачами”?
May 30th, 2007 at 11:43
Простые приложения типа cms, блогов, всякая рутина. Как бы по точнее выразиться… мм, он хорошо подходит на роль основного рабочего инструмента )) Причем инструмент получается не слишком сложный, но и не слишком простой…
May 30th, 2007 at 14:53
На роль инструмента подходит как раз Zend Framework. Т.е. я с помощью него вязл что-то и смастерил.
Остальные фреймворки сами предлагают уже сделанное за тебя решение. Хорошо это или плохо - хз, я думаю это лучше, особенно для новичков.
May 30th, 2007 at 15:03
ZF конечно подходит, просто я считаю, что остальные фреймворки тоже нужно попробывать (CodeIgniter в частности).
>Остальные фреймворки сами предлагают
>уже сделанное за тебя решение
К CodeIgniter’ру это в каком-то смысле относится в меньшей степени, имхо )
May 30th, 2007 at 15:09
ZF - явно самый навороченный, с этим спорить будешь? :)
CodeIgniter… Блин… Ох уж эта учеба. Поосмотрим. Я и так тут понаобещал всего - не знаю, когда время на это выделять.
May 30th, 2007 at 15:50
Ну вот того же ORM’ма там нет… даже вроде ActiveRecord нет. Нет автогенерации админки и скаффолдинга (как в джанге или симфони). Наверное ещё чего-то нет, я не специалист по ZF )
Желаю времени тебе побольше )))
May 30th, 2007 at 15:58
ORM - нет, может будет. Посмотрим. Я вот на примере Zope погляжу, что есть ORM внутри, может мне какие-то интересные мысли прийдут относительно ModelDb моего.
May 30th, 2007 at 17:47
Т.е. как это нет ORM в зенд фреймворке, а Zend_Db_Table - не это ли реализация ORM. По определению ORM это оно ;)
May 30th, 2007 at 18:36
ха ) По определению может и так, взгляните на propel или на питоновские sqlobject/sqlalchemy и вам сразу станет понятно, что Zend_Db_Table это, эээ, костыль )
P.S. судя по названию Zend_Db_Table реализует только AR паттерн ;)
May 30th, 2007 at 20:04
Согласен, молоденький еще db_table. :)
Но мельком взглянул на propel.
По поводу установки (внедрения в приложения) - ну никак не ожидал что придется описывать структуру БД таблиц, да еще и в xml (хотя можно и из sql-файлика). Бяка! :( Zend_Db_Table требует описания только связей между таблицами (FK). :)
Идем дальше. CRUD (Create, Retrieve, Update, Delete) операции очень похожи на наши Zend_Db_Table’овские. Связи один-к-одному, многие-ко-многим - всё это у нас тоже есть ;)
А “компиляция” кода меня добило, если честно…
Питоновские не смотрел, может конечно и лучше в чем-то, но меня вполне устривает Zend_Db_Table :)
May 30th, 2007 at 22:45
Хехе, никакой это не ORM. И он даже не старается им притворятся.
По поводу установки (внедрения в приложения) - ну никак не ожидал что придется описывать структуру БД таблиц, да еще и в xml (хотя можно и из sql-файлика).
В том то и суть ORM - перенести работу с бд на уровень работы с самим языком. Одна из важных вещей ORM - согласование типов языка программирования и бд (в PHP и в бд разные ведь типы? :)) - такого не было, нет и не будет в ZF.
Кстати, насчет ORM - они сами пишут по этому поводу:
May 31st, 2007 at 11:23
Гм, имхо, суть ORM в том, что эта технология позволяет невидимо для программиста сохранять объекты в БД (с сохранением всех данных объекта), а также производить манипуляции (crud, relations) с этими объектами не сталкиваясь с бд.
May 31st, 2007 at 14:22
Согласен с zhulanov.
Суть ORM и состоит в том, чтобы разработчику абстрагироваться от БД. А Вы мне предлагаете в xml забивать поля данных, типы и т.д. А если у меня тип поля изменился на стадии разработки - лезть в xml, искать, править…
Propel, несомненно, вещь мощная, но Zend_Db_Table для меня намного удобнее. Он избавляет меня от рутинной работы по налаживанию связки Объект-База_Данных (Object-Relation Mapping)
May 31st, 2007 at 14:31
Для каждого дела свой инструмент. В каких то проектах оптимальнее использовать propel )
P.S. Уж что-то, а тип поля, при правильном проектировании меняться, не должен ;)) Но к сожалению всё предусмотреть невозможно )
May 31st, 2007 at 15:03
Попробую обьяснить, что именно я имел ввиду и чего Db_Table’у не хватает в первую очередь для того, чтобы считать его ORM’ом - нет самого M, маппинга то есть. :)
сохранять объекты в БД
Уточню - обьекты языка программировая. Обьект - это что? Это набор данных различных типов. Mapping - сопоставление типу ЯП тип БД. Для удобной работы. Это я и имел ввиду.
Суть ORM и состоит в том, чтобы разработчику абстрагироваться от БД. А Вы мне предлагаете в xml забивать поля данных, типы и т.д. А если у меня тип поля изменился на стадии разработки - лезть в xml, искать, править…
А вы предлагаете вручную писать SQL-код, которым таблицу вы будете создавать? :) По-моему лучше уж XML.
Propel, несомненно, вещь мощная, но Zend_Db_Table для меня намного удобнее. Он избавляет меня от рутинной работы по налаживанию связки Объект-База_Данных (Object-Relation Mapping)
1. Налаживать ничего особо не надо.
2. Походу ты хорошими ORM’ами мало пользовался :) Поюзай propel побольше - поймешь лучше суть ORM’а.
3. Он избавляет меня от рутинной работы, зато принуждает к рутинной работе с SQL’ем при создании и изменении таблицы :)
May 31st, 2007 at 15:47
1. Действительно, налаживать с Zend_Db_Table ничего вообще не надо, разве указать имя таблицы и первичный ключ.
2. Propel’ом не пользовался.
3. По поводу написания SQL запросов, если честно, то уже начинаю забывать что это такое из-за таких средств проектирования как DBDesigner, MySQl workbench и им подобных.
Дальше спорить не буду, все остались при своих мнениях :)
May 31st, 2007 at 16:19
Еще раз:
1. … и не иметь никаких преимуществ маппинга :)
2. А какими ORM’ами пользовался?
3. Ну, вообще-то можно обойтись и без них, юзая ORM ;) Причем это будет не какой-то GUI для бд, а обьектно-ориентированная работа с бд в рамках текущего проекта, в рамках предметной области.
Мое мнение - Zend_Db_Table нужно улучшать и улучшать, причем в сторону именно ORM.
May 31st, 2007 at 16:34
Кстати, зачем писать с нуля Zend_Db_Table, когда можно написать обёртку над уже существующими орм-библиотеками (http://wiki.cc/php/?title=Object-relational_mapping_tools)
May 31st, 2007 at 16:39
В плане - разработчикам Zend зачем? Так у них абсолютно все в фреймворке свое. И сделано очень красиво.
Если б они еще и сам язык развивали нормально. :(
September 6th, 2007 at 15:16
А как ZendFW по производительности? Можно ли на нем делать проекты предполагающие большую нагрузку?
September 6th, 2007 at 15:29
Я уже нашел ответ: http://paul-m-jones.com/blog/?p=236
Zend оказался самым тормознутым
September 6th, 2007 at 16:02
Мдя. Версия 0.2.0, в то время, как сейчас уже 1.0.1. По скорости - я не сравнивал и не буду. Мне скоростей хватает. Где зенд будет просаживаться - просядут и остальные фреймворки, в этом я уверен.
Зенд интересен своей структурой, хорошими, красивыми архитектурными решениями. Я люблю, когда все спроектировано “красиво” и понятно.
December 9th, 2007 at 03:42
Попробуй для начала ещё CodeIgniter
http://www.seleckis.lv/journal/journal-php/codeigniter-8212-framework-dlya-novichkov
December 9th, 2007 at 13:14
:) Я пробовал…
December 10th, 2007 at 20:29
Если есть желение посмотри Solar. Начал его копать тоже довольно не плохой. ))
December 10th, 2007 at 21:20
Нафиг? :)
Сейчас куча фреймворков уже есть. Если начал писать на одном - не нужно переходить на другие, смысла в этом практически нет.
December 10th, 2007 at 21:38
Ну это как сказать, сравнимо с “начал писать на ПХП смысла нет Яву учить.
Ещё всегда существует вероятность что, какой-либо фреймворк будет гораздо более удобный и функциональный, чем тот который ты используешь.
Еще изучая другие решения одних и тех же вещей и сам начинаешь менее однообразно смотреть на вещи.
А ещё плюс, если столкнёшся то будет меньше геммора :))
А вообще монополия это плохо :) :) ;)
December 10th, 2007 at 22:22
Смысл учить что-то есть, если есть достаточно большая вероятность, что то, что ты учишь реально лучше того, что знаешь. Либо если тебя текущие средства вообще не устраивают.
January 30th, 2008 at 03:28
>Кстати, заметил за собой такую “штуку” - вот >сделал что-то с этим фреймворком, теперь мне >как-то без него неуютно… Что >посоветуете/скажете по этому поводу?
Это как наркотики … подсел, стал ленивым, сам начинаешь что-то серьёзное делать, только когда уже реально припечёт, а ничего подходящего нет! Так что по своему опыту могу сказать, что тенденция должна будет прогрессировать.
18. zhulanov Says:
May 31st, 2007 at 14:31
P.S. Уж что-то, а тип поля, при правильном проектировании меняться, не должен ;)) Но к сожалению всё предусмотреть невозможно )
Не правда! Реалии разработки веб-приложений таковы что таблицы, поля, типы таблиц приходится менять при развитии проекта. Стоит избегать избыточного проектирования и всё не предусмотришь .. это базовых турдах по рефакторингу ещё описано, за продробностями отсылаю к М.Фаулер “Рефакторинг”.
Если не поможет тогда прочитай ещё Скоттт В. Эмблер, Прамодкумар Дж.Садаладж “Рефакторинг баз данных - Эволюционное проектирование”. И поймёшь насколько всё не статично!!
30.
Нафиг? :)
Сейчас куча фреймворков уже есть. Если начал писать на одном - не нужно переходить на другие, смысла в этом практически нет.
Полностью не согласен! Каждый проект, каждый фреймвёрк, каждая библиотека уникальны, также как и их авторы! Поэтому новые решения стоит узнавать и использовать! Так как для конкретного проекта они могут подходить лучше чем другие похожие, что сократит время разработки, улучшит качество решений и уменьшит поток фраз относительно фреймвёрка начинающихся с “Да здесь это решается через ж … “
January 30th, 2008 at 11:00
“Рефакторинг баз данных - Эволюционное проектирование” надо почитать, спасибо за совет.
Тем не менее я немного утрировал, прекрасно понятно, что проект “с бумаги”, и то что получится в итоге — во многих аспектах разные, всего учесть нереально. Могу так же сказать, что пару раз приходилось пересматривать некоторые вещи кардинально, хотя этап проектирования занимал довольно много времени.
January 30th, 2008 at 22:51
Полностью не согласен! Каждый проект, каждый фреймвёрк, каждая библиотека уникальны, также как и их авторы!…
Если ты не фрилансер и работаешь много, то изучать новый фреймворк времени практически нет. Так что это будет лишь тратой времени.