Книга о Django зарелизилась Укртелеком дает жару - новые тарифы
Dec 18

В виду некоторых обстоятельств (пока не буду говорить, каких) полностью перейти на Python + Django и забить на PHP не получается. В связи с этим вопрос - какой из PHP-фреймворков выбрать для изучения и последующего использования.

Кандидаты:

  1. Zend Framework - в принципе, если его основательно помучать, то за пару недель-месяц из него можно сделать неплохой каркас для быстрой разработки сайтов. Преимущества - красивый код, продуманность в архитектуре, гибкость (хотя во многих случаях она и не нужна). Недостатки - относительно медленный, нет всякой “помощи” разработчикам (типа скаффолдинга и прочего), нет реализации ActiveRecord.
  2. CodeIgniter - хороший, простой, и, самое главное, быстрый фреймворк. По скорости обгоняет все остальные (вчера был тест ZF/CakePHP/CI на линуксе с помощью ab - CI выиграл, причем с ощутимым отрывом). Есть скаффолдинг, есть куча плагинов, некоторые - достаточно интересные (в частности, rapyd).
  3. CakePHP - у этого фреймворка куча поклонников, много материалов по использованию и рабочих приложений. В недостатки можно записать жесткую тормознутость - он чуть ли не в 1,5-2 раза тормознее ZF (интересно, с чего бы это?).
  4. Советовали еще Limb, Solar, но пока их не смотрел. Еще что-нибудь предложите?

PS. Пока что склоняюсь к CI…

written by FX Poster \\ tags: , , ,

One Ping to “Выбор PHP фреймворка”

  1. farik.in.ua » Blog Archive » Выбор PHP фреймворка Says:

    [...] Продолжение, а самое главное камменты читаем тут [...]


67 Responses to “Выбор PHP фреймворка”

  1. 1. mihailt Says:

    Посмотри
    Kohana - основанный на CI.
    Если дружишь с pear то Solar может понравится, правда пока альфа.
    Если нужно что-то совсем легковесное то frog фреймворк подойдёт. ;)

  2. 2. FX Poster Says:

    Нужно то, чем я буду пользоваться и не испытывать больших проблем.

  3. 3. Sam Says:

    #1. Я тоже думал, что если его помучать, можно что-то вымучать… Возможно оно и можно, но:

    1. Мучать придётся кучу либ, а не разрабатывающийся проект. Это надолго. У меня за пару месяцев не вышло (мучал конечно в свободное время).

    2. ZF будет постоянно ставить палки и мешать мучению.

    #2. CodeIgniter. Штука занятная. Работает быстро. Мануал покрывает 80% возможностей. Код ядра - лапша ещё та… Если что сбойнёт - не разберёшься просто так. rapyd штука довольно бажная…

    #3. Cake. Не сказал бы, что тормознутый. Особенно если юзать кэш и вовремя откусывать ассоциации у моделей. Минус - есть довольно стабильная в работе пре-бэта 1.2. Всё время тянет на неё перейти (я уже). Но на неё нет внятной документации (у 1.1 с этим делом всё отлично).

    p.s. тестирование проводилось без кэширования на “hello, world!”? Кстати, cake в дефолтном отладочном режиме работает на порядок медленней, чем в продуктивном.

  4. 4. FX Poster Says:

    Кстати, cake в дефолтном отладочном режиме работает на порядок медленней, чем в продуктивном.
    А чем они отличаются? :))) Если по манам судить - ничем кроме расположения директорий. :-D

    Тестил на кейке 1.2. Кеширование вырублено. Дока по 1.2 есть тут.

  5. 5. FX Poster Says:

    Гм. Щас запустил тесты на 1.2 vs 1.1. Оба кейка - out-of-box.

    CakePHP 1.1: 21 запрос в секунду
    CakePHP 1.1: 11 запросов в секунду

  6. 6. FX Poster Says:

    Кстати, установка debug в разные значения принципиально картины не меняет. В CakePHP при DEBUG == 0 - 21 запрос/сек, при DEBUG == 2 - 20 запрос/сек.

  7. 7. Sam Says:

    Я не про это. Есть режим отладки, есть продуктивный. Это к папочкам никак не относится.

    app/config/core.php
    Configure::write(’debug’, 0);

    p.s. Это не дока, а наброски.

  8. 8. Sam Says:

    Так всё-таки на “hello, world!” тестирование было? ;)

  9. 9. FX Poster Says:

    Configure::write(’debug’, 0);
    см. выше. практически не роляет.

    Это не дока, а наброски.
    А разница?

    Так всё-таки на “hello, world!” тестирование было?
    Да, статическая страница размером 1.3кб.

  10. 10. Sam Says:

    Нашёл на чём тестировать :)

  11. 11. FX Poster Says:

    Разница видна невооруженным глазом даже на таком примере. Что еще нужно-то?

  12. 12. Sam Says:

    :)

    Потестируй на чём-нибудь более реальном: пара связанных моделей, одна вьюшка, пара-тройка выборок. Хотя бы так.

  13. 13. mihailt Says:

    У меня основной это фреймворк это CI, зенд встроить не проблема ( а куда его встроить проблема? ), да и сам CI куда угодно встраивать можно, плюс достаточно быстрый а в связке с memcached так вобще летает, с ораклом правда у него не всё в порядке и ещё минус не очень он с ajax’ом дружит.

    Насчёт rapyd - сначала тоже нравилось, но глюков там как сказал Sam действительно много. ;)

    Теперь про Kohanu( хотя упоминал уже) - ребята переработали CI и заточили его под пхп5 получилось очень хорошо,плюс постовляется в двух видах -minimal и standard набор минус доки мало, хотя там понятно всё в основном. :)

    CakePHP - ну, не знаю я, но почему-то я его очень не люблю

    ZF - как раз пару дней назад начал каркас делать, ну не выглядит что скоро всё будет и если чего-то быстро надо, то с тем же CI всё гораздо быстрее, хотя вещи на ZF точно делать можно взять хотя бы magento :)

  14. 14. FX Poster Says:

    Magento - жесткая штука. Пример того, сколько нужно написать, чтобы сделать хорошее приложение. А понаписано там… Дай боже…

    Kohana (кстати, по украински “кохана” - любимая ;)) - по скорости проигрывает CI. ;) А вообще - попробую, и наверно на нем и останусь. Совместимость с PHP4 мне нафиг не нужна.

  15. 15. FX Poster Says:

    Кстати, насчет Framework.php от Frog’а - тем же CI и CakePHP поучиться бы у него, как нужно делать ActiveRecord.

  16. 16. mihailt Says:

    дык я ещё в первом комменте про него сказал ;)

  17. 17. crash Says:

    А symfony почему выбросил? Да, у него Propel надо менять на Doctrine, но зато админка часто очень помогает с мозгоимением такой рутинной задачи :)
    У Limb ORM неплох, но все только-только начинается.

  18. 18. FX Poster Says:

    Доктрина только с виду хороша…
    Создай в ней запись. Создай экземпляр записи, не присваивая записи никаких значений (типа, пустая запись). И сделай записи save. ;)

    По доктриновской логике запись сохранится, только в бд она не добавится. А по идее - тут должен быть Exception.

  19. 19. FX Poster Says:

    Над симфони я думал… Нужно будет попробовать как-нить.

    PS. А чем пропел-то не нравится? Yaml - прикольная штучка ;)

  20. 20. crash Says:

    Ну после джанго писать запросы с Criteria - полнейший пиздец. Ну и YAML хз, к нему немного привыкнуть надо. И ситуация похожа на твою - хочется работать полностью на джанго, но некоторые обстоятельства требуют пхп :(

  21. 21. FX Poster Says:

    Да вот так и живём…
    А Yaml, кстати, очень даже популярен в ruby и rails ;)

  22. 22. Sam Says:

    На ror тут ориентироваться не стоит особо. Особенно если ror не нравится :)

    Наиболее близки к ror сейчас CakePHP 1.2 и PHPonTrax.

  23. 23. Nikita Says:

    CodeIgniter выигрывает в скорости отчасти из-за отсутствия собственного парсера структур типа YAML, а так же темплейтов. Только PHP. Active Record почти ничем не отличается от запросов MySQL, только на PHP основе. Имхо, этот фреймворк подойдёт тем, кто не хочет сильно заморачиваться с YAML, дополнительным синтаксисом шаблонов в View и т.п. Для новичков в framework’ах — идеально. Для больших проектов — не знаю.

    Symfony — комбайн. Но тормоз.

    ROR неплохая штука, но тоже тормоз. Плюс надо учить новый синтаксис.

  24. 24. FX Poster Says:

    Sam
    Я никогда не говорил, что мне ROR не нравится.
    А по поводу симфони - ты на это погляди. Мне охрененно понравилось.

    Nikita
    Эх… Все твердят - тормоз, тормоз. А в каких приложениях это проявилось? Разницы между рендерингом страницы за 0.2 секунды или за 0.01 - для конечного пользователя нет. Браузер эту страницу будет отображать ой как дольше.

  25. 25. mihailt Says:

    Насчет темплейтов в CI - они там хоть и хиленькие но есть ;)

  26. 26. Nikita Says:

    FX Poster, с большой нагрузкой нужно больше мощного железа.

    mihailt, в CI темплейты есть, но данные вставляются простым PHP. Нет лишнего синтаксиса для меток которые потом обрабатываются парсером. Соответственно скорость обработки меньше.

  27. 27. FX Poster Says:

    Nikita
    Нет лишнего синтаксиса для меток которые потом обрабатываются парсером.
    На самом деле есть. Догадайся, как работает <?= в CI с отключенными short_open_tags.

    с большой нагрузкой нужно больше мощного железа.
    Ну и что? CI быстр, согласен. Но мне вот интересно, есть ли такие приложения в вебе, которые бы на Symfony ложили сервер, а переписанные на CI - нормально работали бы. Я сильно сомневаюсь в том, что такие приложения вообще существуют.
    Те же тесты на ab - это обычная “писькомерялка”. Если проект неоправданно тормозит - нужно искать баги/рефакторить код. А сравнение фреймворков по сути не дает ничего - в реальных приложениях разница будет малозаметной.

  28. 28. Sam Says:

    Скринкаст вообще по Propel :) Symfony там как-то сбоку. Propel - да. Вещь. Но немного заморочно с ней на shared-хостинге.

  29. 29. Nikita Says:

    На самом деле есть. Догадайся, как работает <?= в CI с отключенными short_open_tags.

    А что, работает? А я не знал ))

    Ну, в принципе, ты прав. Если писать серьёзное приложение то нужно расчитывать нагрузку в соответствии с используемым софтом.

  30. 30. crash Says:

    >Скринкаст вообще по Propel :) Symfony там как-то >сбоку. Propel - да. Вещь. Но немного заморочно с >ней на shared-хостинге

    эм, генератор админки разве входит в поставку propel? :)
    Но то что с админкой не надо писать запросы через Criteria - это да, большой плюс :)

  31. 31. FX Poster Says:

    Sam
    А типа в симфони больше ничего нет, кроме propel? :) Вообще говоря, разница в подходах симфони и того же кейка впечатляет - в симфони всё сделано более продумано и профессионально. Тот же Doctrine в симфони подключается на ура через плагин. Сегодня пробовал.

    В симфони вообще применяется подход “тише едешь - дальше будешь”. Т.е. учишь долго - программишь потом быстро.

    Nikita
    Ага, работает. ;) Так что что-то он там все же делает. Что именно - не разбирался особо.

  32. 32. mihailt Says:

    Ага, работает. ;) Так что что-то он там все же делает. Что именно - не разбирался особо.

    Да собственно не особо много:

    if ((bool) @ini_get('short_open_tag') === FALSE AND config_item('rewrite_short_tags') == TRUE)

    {

    echo eval('?>'.preg_replace("/;*\s*\?>/", "; ?>", str_replace('<?=', '<?php echo ', file_get_contents($path))).'<?php ');

    }

  33. 33. Sam Says:

    FX Poster, а нафига тебе этот недоделанный AR Doctrine, когда есть нормальный ORM Propel?

    В Symfony много всего интересного. Но блин тяжеловесно очень…

  34. 34. bewhite Says:

    На CI заканчиваю второй проект. Работать можно. Не понравилась примитивность Active Record (по сравнению с RoR). Понравилось простота в установке и эксплуатации. Обязательно изучать плугины: сильно облегчают жизнь.

    Symfony не понравился своей монументальностью. Здоровенные структуры каталогов густо посыпанные по всей площади конфигурационыыми файлами раздражают. Хотя для монструозных проектов может быть и оправдано.

    Из портов RoR на PHP могу посоветовать глянуть на PHPonTrax и Akelos.

    Ну а RoR - это RoR. Не холивар же здесь начинать :)

  35. 35. bewhite Says:

    Кстати CI скаффолдинг в продакшене не советуют использовать даже авторы фреймворка.

  36. 36. FX Poster Says:

    Ты погляди скринкаст симфони выше в комментах. Это вам не простой скаффолдинг. ;)

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

  37. 37. Sam Says:

    Хе… доктрину чуть доделали… не заметил.

  38. 38. Sam Says:

    70% проектов небольшие. Скорее всего их быстрее будет сделать на CI, Kohana или Frog…

  39. 39. FX Poster Says:

    Ну тут как знать. Я считаю, что работа с симфоней в любом случае лишней не будет. ;)

  40. 40. Alex Says:

    Кто-нибудь рассматривал-тестировал-использует Prado Framework? Какое впечатление? Интересны отзывы об этом фрейворке.
    http://www.pradosoft.com

  41. 41. FX Poster Says:

    Я смотрел, правда давно и очень поверхностно. Тогда показался вполне нормальным. Но копать глубже не стал.

  42. 42. ACID Jesus Says:

    К CI приделываем Smarty, вставляем ZF в качестве third-party компонентов - получаем в итоге быстрый , удобный и достаточно лёгкий для освоения фреймворк, который может подойти не только для небольших проектов, но и для вполне крупных… ;)

  43. 43. FX Poster Says:

    Если честно, Model в CI мне не нравится.

  44. 44. mihailt Says:

    хмм.. а чем именно??

  45. 45. FX Poster Says:

    Как ни странно, но логикой. :) Хочется красивый ActiveRecord, а получаем фиг знает что.

    Ведь что собой ActiveRecord представляет - класс, обьекты которого полностью представляют из себя записи таблицы - их можно сохранять, на них навешиваются валидаторы и прочее. И набор методов, которые бы возвращали обьекты этого класса. В PHP-фреймворках это есть разве что в симфони.

  46. 46. FX Poster Says:

    Вру, в cakephp есть, но тоже как-то… Неправильно…

  47. 47. Andrey Says:

    В Symfony тоже убогий ORM(Propel, Doctrine). А вообще многим надо от FW, тока адекватную модель, а всё остальное ставится на 2-ой план.

  48. 48. FX Poster Says:

    Покажи, где убогость. ;) Что Propel, что Doctrine - лучшие из тех, что я видел ORM’ы на PHP.

  49. 49. Andrey Says:

    PDO в качестве DBAL, всё же накладывает некие ограничения(поддержка хостерами, PDO не может учитывать реализацию конкретного драйвера, к Oracle например и т.д.).
    Отношения 1 к 1, я так и не увидел.
    к примеру в Propel отношения сделаны вообще убого….
    Выбор драйвера всё же должен быть доступен разработчику…

  50. 50. FX Poster Says:

    Андрюх, ну обсуждали ж уже. :) PDO поддерживается большинством нормальных хостеров.

    PDO не может учитывать реализацию конкретного драйвера
    В смысле?

    Отношения 1 к 1, я так и не увидел.
    Может быть. Не смотрел. В Doctrine есть.

    к примеру в Propel отношения сделаны вообще убого….
    Аргументируй? Имхо - вполне даже ничего. Вчера игрался с симфоней - всё там норм.

    Выбор драйвера всё же должен быть доступен разработчику…
    Он доступен. Но только через PDO. :)

  51. 51. FX Poster Says:

    Почитай, кстати. Достаточно интересно. Проблема в том, что рассказывать, какие они хорошие, они умеют. А вот удобства я от Limb’а по сравнению с Symfony не увидел.

  52. 52. Andrey Says:

    Посмотри oci_*, намного больше функционала чем в PDO_OCI…
    да вроде в PDO нет mysqli драйвера((((
    Many-to-Many Relationships in Propel вот 1+n запросов мне и не нравится….

    P.S. вот LImb, мне ближе по структуре, чем Symfony!

  53. 53. FX Poster Says:

    Ну, для начала - ты реализуй DBAL, чтобы абсолютно все возможности каждого драйвера были задействованы. ;)

    Many-to-Many Relationships in Propel вот 1+n запросов мне и не нравится
    Тут двояко можно рассматривать. Для начала 1+n запросов могут быть не намного медленнее, чем 1, но очень большой:

    SELECT book.*, reader.* FROM book
    LEFT JOIN book_reader_ref ON(book_reader_ref.book_id = book.id)
    LEFT JOIN reader ON(reader.reader_id = book_reader_ref.reader_id)

    БД тоже нужно время, чтобы это всё обработать. Это раз. И два - А если тебе join’ить не нужно будет, то что, тоже всё выбирать?

  54. 54. Andrey Says:

    Ну, для начала - ты реализуй DBAL, чтобы абсолютно все возможности каждого драйвера были задействованы.
    планирую на конец января, но поддержка Oracle будет наврятли )))
    Тут двояко можно рассматривать. Для начала 1+n запросов могут быть не намного медленнее, чем 1, но очень большой
    не буду спорить, просто опять же нету выбора((((
    + IN() тут разве не пойдет?

  55. 55. FX Poster Says:

    планирую на конец января, но поддержка Oracle будет наврятли )))
    Если реализовывать все возможности каждого драйвера - про легкую смену баз данных можно забыть.

    IN() тут разве не пойдет?

    SELECT reader.* FROM book_reader_ref
    LEFT JOIN reader ON(reader.reader_id = book_reader_ref.reader_id)
    WHERE book_reader_ref.book_id IN(<тут список book.id>)

    Можно, но первый вариант более гибкий.

  56. 56. mihailt Says:

    кстати есть такая штука как junction ( http://www.junctionphp.com) достаточно легко интегрируется в любой проект

  57. 57. FX Poster Says:

    Документации нормальной нет? :(

  58. 58. FX Poster Says:

    Да и чем она лучше Propel’а и Doctrine’ы?

  59. 59. Sam Says:

    Junction в дремучей бэте.

  60. 60. mihailt Says:

    доки у неё немного в странные, но почитав wiki
    всё быстро становится ясно.

    установка на мой взгляд очень простая да и работает довльно шустро

    beta - это факт, но при этом работает стабильно

  61. 61. Zeke Fast Says:

    45. FX Poster
    В PHP-фреймворках это есть разве что в симфони.

    Посмотри Prado - замечательная реализация AR, выполняющая возложенные на неё задачи! Не больше ни меньше. С Propel её сравнивать без смысла ориентация у неё другая. Propel претендует на глобальную замену запросам, AR в Prado представляет же альтернативу маленьким и простым запросам к бд. В Prado для монстрообразных запросов есть SQLMap.

    52. Andrey
    P.S. вот LImb, мне ближе по структуре, чем Symfony!

    Ознакомься с Prado они очень похоже, как я понял. Оба WACT подобные темплейты используют если мне не изменяет память ….

  62. 62. FX Poster Says:

    Нет, Limb больше на симфонию похож как раз. :) Только гораздо менее доделанный, ИМХО.

  63. 63. Sam Says:

    Но сами Limb-овцы утверждают обратное… :)

  64. 64. Tamerlan Says:

    А как вы тестите скорость работы?

  65. 65. FX Poster Says:

    Apache Benchmark

  66. 66. Yevgeniy Says:

    Seagull PHP Framework, особенно для тех кто “очень” дружит с pear ;)

  67. 67. FX Poster Says:

    Спасибо, я уже выбрал Symfony. :)

Leave a Reply