Jan 30

После полного прочтения блога Ивана Сагалаева, у меня возникла мысль, что надо бы поискать фреймворки для 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, потому как сейчас ее нет даже в инкубаторе, а жаль.

Я думаю, я еще вернусь к этой теме.

written by fxposter \\ tags: ,


35 Responses to “PHP Frameworks”

  1. 1. Soul Says:

    Надо бы попробовать сию вещь :)

  2. 2. sas171 Says:

    За zend framework будущее. Стоит хотя бы заглянуть в исходники и всё становится понятно. Правда насчет ORM ты абсолютно прав.

    А в MVC паттерне сложно ничего нет. Могу поспорить ты его используешь уже сейчас. Просто в немного извращеной форме =)

    Спасибо за пост. Побольше бы про пхп ;)

  3. 3. FX Poster Says:

    sas171
    Если б они еще PHP доделывали, было бы вообще супер. Сделали бы классы date-time, string (нормальный) встроенными напрямую в пхп…
    Т.е. чтобы вместо набора функций в пхп был набор классов с методами…

  4. 4. zhulanov Says:

    посмотрите ещё и code igniter

    на мой взгляд для стандартных задач этот фреймворк подходит лучше остальных…

  5. 5. FX Poster Says:

    Слышал я о нем. Только когда обзор писался мне “пришлись по духу” эти три фреймворка, а сейчас времени нет еще обозревать. Как разберусь немного с учебой – продолжу. Надеюсь, это будет кому-нибудь нужно…
    PS. Что понимается под “стандартными задачами”?

  6. 6. zhulanov Says:

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

  7. 7. FX Poster Says:

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

  8. 8. zhulanov Says:

    ZF конечно подходит, просто я считаю, что остальные фреймворки тоже нужно попробывать (CodeIgniter в частности).

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

    К CodeIgniter’ру это в каком-то смысле относится в меньшей степени, имхо )

  9. 9. FX Poster Says:

    ZF – явно самый навороченный, с этим спорить будешь? :)
    CodeIgniter… Блин… Ох уж эта учеба. Поосмотрим. Я и так тут понаобещал всего – не знаю, когда время на это выделять.

  10. 10. zhulanov Says:

    Ну вот того же ORM’ма там нет… даже вроде ActiveRecord нет. Нет автогенерации админки и скаффолдинга (как в джанге или симфони). Наверное ещё чего-то нет, я не специалист по ZF )

    Желаю времени тебе побольше )))

  11. 11. FX Poster Says:

    ORM – нет, может будет. Посмотрим. Я вот на примере Zope погляжу, что есть ORM внутри, может мне какие-то интересные мысли прийдут относительно ModelDb моего.

  12. 12. RBatoon89 Says:

    Т.е. как это нет ORM в зенд фреймворке, а Zend_Db_Table – не это ли реализация ORM. По определению ORM это оно ;)

  13. 13. zhulanov Says:

    ха ) По определению может и так, взгляните на propel или на питоновские sqlobject/sqlalchemy и вам сразу станет понятно, что Zend_Db_Table это, эээ, костыль )

    P.S. судя по названию Zend_Db_Table реализует только AR паттерн ;)

  14. 14. RBatoon89 Says:

    Согласен, молоденький еще db_table. :)

    Но мельком взглянул на propel.
    По поводу установки (внедрения в приложения) – ну никак не ожидал что придется описывать структуру БД таблиц, да еще и в xml (хотя можно и из sql-файлика). Бяка! :( Zend_Db_Table требует описания только связей между таблицами (FK). :)
    Идем дальше. CRUD (Create, Retrieve, Update, Delete) операции очень похожи на наши Zend_Db_Table’овские. Связи один-к-одному, многие-ко-многим – всё это у нас тоже есть ;)

    А “компиляция” кода меня добило, если честно…

    Питоновские не смотрел, может конечно и лучше в чем-то, но меня вполне устривает Zend_Db_Table :)

  15. 15. FX Poster Says:

    Хехе, никакой это не ORM. И он даже не старается им притворятся.

    По поводу установки (внедрения в приложения) – ну никак не ожидал что придется описывать структуру БД таблиц, да еще и в xml (хотя можно и из sql-файлика).
    В том то и суть ORM – перенести работу с бд на уровень работы с самим языком. Одна из важных вещей ORM – согласование типов языка программирования и бд (в PHP и в бд разные ведь типы? :)) – такого не было, нет и не будет в ZF.

    Кстати, насчет ORM – они сами пишут по этому поводу:

    OO-RDBMS mapping
    We are currently supporting Table and Row Gateway patterns to relational databases. Based on feedback we will decide if and what kind of additional higher-level layer might be beneficial to our users.

  16. 16. zhulanov Says:

    Гм, имхо, суть ORM в том, что эта технология позволяет невидимо для программиста сохранять объекты в БД (с сохранением всех данных объекта), а также производить манипуляции (crud, relations) с этими объектами не сталкиваясь с бд.

  17. 17. RBatoon89 Says:

    Согласен с zhulanov.
    Суть ORM и состоит в том, чтобы разработчику абстрагироваться от БД. А Вы мне предлагаете в xml забивать поля данных, типы и т.д. А если у меня тип поля изменился на стадии разработки – лезть в xml, искать, править…

    Propel, несомненно, вещь мощная, но Zend_Db_Table для меня намного удобнее. Он избавляет меня от рутинной работы по налаживанию связки Объект-База_Данных (Object-Relation Mapping)

  18. 18. zhulanov Says:

    Для каждого дела свой инструмент. В каких то проектах оптимальнее использовать propel )

    P.S. Уж что-то, а тип поля, при правильном проектировании меняться, не должен ;)) Но к сожалению всё предусмотреть невозможно )

  19. 19. FX Poster Says:

    Попробую обьяснить, что именно я имел ввиду и чего Db_Table’у не хватает в первую очередь для того, чтобы считать его ORM’ом – нет самого M, маппинга то есть. :)
    сохранять объекты в БД
    Уточню – обьекты языка программировая. Обьект – это что? Это набор данных различных типов. Mapping – сопоставление типу ЯП тип БД. Для удобной работы. Это я и имел ввиду.

    Суть ORM и состоит в том, чтобы разработчику абстрагироваться от БД. А Вы мне предлагаете в xml забивать поля данных, типы и т.д. А если у меня тип поля изменился на стадии разработки – лезть в xml, искать, править…
    А вы предлагаете вручную писать SQL-код, которым таблицу вы будете создавать? :) По-моему лучше уж XML.

    Propel, несомненно, вещь мощная, но Zend_Db_Table для меня намного удобнее. Он избавляет меня от рутинной работы по налаживанию связки Объект-База_Данных (Object-Relation Mapping)
    1. Налаживать ничего особо не надо.
    2. Походу ты хорошими ORM’ами мало пользовался :) Поюзай propel побольше – поймешь лучше суть ORM’а.
    3. Он избавляет меня от рутинной работы, зато принуждает к рутинной работе с SQL’ем при создании и изменении таблицы :)

  20. 20. RBatoon89 Says:

    1. Действительно, налаживать с Zend_Db_Table ничего вообще не надо, разве указать имя таблицы и первичный ключ.

    2. Propel’ом не пользовался.

    3. По поводу написания SQL запросов, если честно, то уже начинаю забывать что это такое из-за таких средств проектирования как DBDesigner, MySQl workbench и им подобных.

    Дальше спорить не буду, все остались при своих мнениях :)

  21. 21. FX Poster Says:

    Еще раз:

    1. … и не иметь никаких преимуществ маппинга :)

    2. А какими ORM’ами пользовался?

    3. Ну, вообще-то можно обойтись и без них, юзая ORM ;) Причем это будет не какой-то GUI для бд, а обьектно-ориентированная работа с бд в рамках текущего проекта, в рамках предметной области.

    Мое мнение – Zend_Db_Table нужно улучшать и улучшать, причем в сторону именно ORM.

  22. 22. zhulanov Says:

    Кстати, зачем писать с нуля Zend_Db_Table, когда можно написать обёртку над уже существующими орм-библиотеками (http://wiki.cc/php/?title=Object-relational_mapping_tools)

  23. 23. FX Poster Says:

    В плане – разработчикам Zend зачем? Так у них абсолютно все в фреймворке свое. И сделано очень красиво.
    Если б они еще и сам язык развивали нормально. :(

  24. 24. larin Says:

    А как ZendFW по производительности? Можно ли на нем делать проекты предполагающие большую нагрузку?

  25. 25. larin Says:

    Я уже нашел ответ: http://paul-m-jones.com/blog/?p=236
    Zend оказался самым тормознутым

  26. 26. FX Poster Says:

    Мдя. Версия 0.2.0, в то время, как сейчас уже 1.0.1. По скорости – я не сравнивал и не буду. Мне скоростей хватает. Где зенд будет просаживаться – просядут и остальные фреймворки, в этом я уверен.

    Зенд интересен своей структурой, хорошими, красивыми архитектурными решениями. Я люблю, когда все спроектировано “красиво” и понятно.

  27. 27. Yuri Baburov Says:

    Попробуй для начала ещё CodeIgniter
    http://www.seleckis.lv/journal/journal-php/codeigniter-8212-framework-dlya-novichkov

  28. 28. FX Poster Says:

    :) Я пробовал…

  29. 29. mihailt Says:

    Если есть желение посмотри Solar. Начал его копать тоже довольно не плохой. ))

  30. 30. FX Poster Says:

    Нафиг? :)
    Сейчас куча фреймворков уже есть. Если начал писать на одном – не нужно переходить на другие, смысла в этом практически нет.

  31. 31. mihailt Says:

    Ну это как сказать, сравнимо с “начал писать на ПХП смысла нет Яву учить.

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

    А ещё плюс, если столкнёшся то будет меньше геммора :))

    А вообще монополия это плохо :) :) ;)

  32. 32. FX Poster Says:

    Смысл учить что-то есть, если есть достаточно большая вероятность, что то, что ты учишь реально лучше того, что знаешь. Либо если тебя текущие средства вообще не устраивают.

  33. 33. Zeke Fast Says:

    >Кстати, заметил за собой такую “штуку” – вот >сделал что-то с этим фреймворком, теперь мне >как-то без него неуютно… Что >посоветуете/скажете по этому поводу?

    Это как наркотики … подсел, стал ленивым, сам начинаешь что-то серьёзное делать, только когда уже реально припечёт, а ничего подходящего нет! Так что по своему опыту могу сказать, что тенденция должна будет прогрессировать.

    18. zhulanov Says:
    May 31st, 2007 at 14:31
    P.S. Уж что-то, а тип поля, при правильном проектировании меняться, не должен ;)) Но к сожалению всё предусмотреть невозможно )

    Не правда! Реалии разработки веб-приложений таковы что таблицы, поля, типы таблиц приходится менять при развитии проекта. Стоит избегать избыточного проектирования и всё не предусмотришь .. это базовых турдах по рефакторингу ещё описано, за продробностями отсылаю к М.Фаулер “Рефакторинг”.
    Если не поможет тогда прочитай ещё Скоттт В. Эмблер, Прамодкумар Дж.Садаладж “Рефакторинг баз данных – Эволюционное проектирование”. И поймёшь насколько всё не статично!!

    30.
    Нафиг? :)
    Сейчас куча фреймворков уже есть. Если начал писать на одном – не нужно переходить на другие, смысла в этом практически нет.

    Полностью не согласен! Каждый проект, каждый фреймвёрк, каждая библиотека уникальны, также как и их авторы! Поэтому новые решения стоит узнавать и использовать! Так как для конкретного проекта они могут подходить лучше чем другие похожие, что сократит время разработки, улучшит качество решений и уменьшит поток фраз относительно фреймвёрка начинающихся с “Да здесь это решается через ж … “

  34. 34. zhulanov Says:

    “Рефакторинг баз данных – Эволюционное проектирование” надо почитать, спасибо за совет.

    Тем не менее я немного утрировал, прекрасно понятно, что проект “с бумаги”, и то что получится в итоге — во многих аспектах разные, всего учесть нереально. Могу так же сказать, что пару раз приходилось пересматривать некоторые вещи кардинально, хотя этап проектирования занимал довольно много времени.

  35. 35. FX Poster Says:

    Полностью не согласен! Каждый проект, каждый фреймвёрк, каждая библиотека уникальны, также как и их авторы!…
    Если ты не фрилансер и работаешь много, то изучать новый фреймворк времени практически нет. Так что это будет лишь тратой времени.

Leave a Reply