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 fxposter \\ tags: , , ,

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

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

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


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

  1. 1. Andrey Says:

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

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

  2. 2. 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’ить не нужно будет, то что, тоже всё выбирать?

  3. 3. Andrey Says:

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

  4. 4. 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>)

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

  5. 5. mihailt Says:

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

  6. 6. FX Poster Says:

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

  7. 7. FX Poster Says:

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

  8. 8. Sam Says:

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

  9. 9. mihailt Says:

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

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

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

  10. 10. Zeke Fast Says:

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

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

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

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

  11. 11. FX Poster Says:

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

  12. 12. Sam Says:

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

  13. 13. Tamerlan Says:

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

  14. 14. FX Poster Says:

    Apache Benchmark

  15. 15. Yevgeniy Says:

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

  16. 16. FX Poster Says:

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

  17. 17. Валерий Says:

    Хоть и прошло много времени после поста, но посмотри на Kohana. Тот же игнайтер, только с грамотным кодом. В игнайтере в коде куча собачек, как его можно считать нормальным

  18. 18. FX Poster Says:

    Как по мне – те же яйца.

  19. 19. xoma Says:

    yii как вариант…..

  20. 20. relo_san Says:

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

    Magento – это пример того, как можно написать объектно-ориентированный Оскоммерц с довольно красивым кодом, но тем не менее представляющим собой невъебенный пиздец. Через день работы с ним – хочется убить одного-двух его разработчиков, через неделю траха с этим гавном – хочется спалить нахуй фирму, которая его создала… Более хаотичной и ебанутой архитектуры я еще не видел за много лет программинга… Отсутствие сколько-нибудь вменяемой документации и комментов в коде прекрасно дополняют этот пиздец.

  21. 21. relo_san Says:

    Да, по теме: На данный момент из фреймворков на пхп вижу только два варианта под разные задачи. Если нужно сделать что-то небольшое и быстрое с небольшими затратами средств – CI. Внутри он конечно гавнецо, но в коммерческом использовании это не важно. Если задача предполагает большой проект с поддержкой и развитием – то Symfony, желательно тщательно отбирая программистов, чтобы гавна под ним не написали. Для эксклюзивных задач аля “фейсбук” или “фликр” фреймворки не подходят, чтобы достичь низкой ресурсоемкости там нужно писать свой каркас, максимально быстро работающий и не выполняющий ничего лишнего, либо существенно переписать ту же Symfony, убрав в ней некоторое количество ресурсоемкой гибкости.
    К сожалению, нормальных фреймворков (аналогов турбогирс, твистед и пайлонс в пайтоне) на пхп пока нет и не известно, будут ли когда-нибудь. Выбирать приходится только из попсы. Равно как и хороших орм, до уровня sqlalchemy пока из пхп-шных орм даже близко никто не приблизился.

  22. 22. FX Poster Says:

    relo_san
    это типа гон на пхп? :)

  23. 23. relo_san Says:

    да нет, гнать я ни на что/кого не собирался, тем более что сам пишу на пхп последние 5 лет :) Это мое видение текущего состояния развития языка и продуктов на нем. Перешел бы на пайтон, но лень мешает :) Плюс опыт на пхп большой, перелазить на другой язык особого смысла нет. Но не появись вовремя симфони – перелез бы, потому что говнокод уже в печенках сидит. А так можно жить, и даже вполне себе неплохо, и не смотреть при этом в продукты типа magento.

  24. 24. FX Poster Says:

    ясно. :) А я в последнее время запал на руби, но… Всё как и у тебя – работа-то на пхп, на другое времени не хватает :)

  25. 25. relo_san Says:

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

  26. 26. FX Poster Says:

    Как по мне, Sequel, AR и DataMapper вполне себе уделывают SQLAlchemy :)

  27. 27. Виктор Says:

    ему, ввиду его молодости, пока не хватает хороших готовых решений
    Это что-то из серии “Мифы древней Греции”? :)

    Про скулачеми уже сказали а аналогом мако может быть Radius: http://radius.rubyforge.org/

  28. 28. relo_san Says:

    Холивары ненавижу и спорить не собираюсь. Возможно я что-то упустил, я не смотрел в сторону руби последние года полтора, не до этого было.
    Надеюсь, вы не относите рельсы к хорошим решениям :) Если есть качественные фреймворки под руби, готовые для коммерческого использования – назовите их, с удовольствием посмотрю при возможности.

  29. 29. FX Poster Says:

    Ммм. А чем плохи рельсы?

    Другие фрейморки: Sinatra, Merb.

  30. 30. Виктор Says:

    Надеюсь, вы не относите рельсы к хорошим решениям :)
    Что вы, что вы! Рельсы ужасны. Они опасны для жизни. Пятеро уже поплатились жизнью за то, что использовали их. Несколько десятков людей пропали без вести. Список жертв постоянно увеличивается. Следите за выпусками новостей. :)

  31. 31. relo_san Says:

    :) фанатизм – это плохо (это я к последнему комментарию).
    что касается рельс – у них много плюсов, до тех пор, пока задача не выходит за некие стандартные рамки. а если чуть дальше – все, писец. По крайней мере когда я ими интересовался – ситуация выглядела именно так. Основная проблема рельс собственно заложена непосредственно в их названии – с рельс не съедешь в сторону. Недостаточная гибкость в возможностях архитектуры. В сравнении скажем с Pylons или Twisted, на котором можно одинаково спокойно и без извращений реализовать куда более широкий круг задач. Более широкие возможности означают меньшую головную боль и больший охват клиентов, потому что программист, дабы сэкономить время и силы, обычно пользуется чем-то одним в арсенале и не станет перелазить на другой фреймворк ради одного проекта, который не вписывается в формат возможностей фреймворка, который он использует. Поэтому чем больше гибкости у фреймворка – тем выгоднее он для программиста. Т.е., если бы я перелазил на что-то с пхп – я бы ушел в Pylons (он к сожалению пока еще несколько сыроват, хотя некоторые его уже успешно используют в высоконагруженных серьезных проектах) или Twisted.
    P.S. Учитывая, что тема все же касалась изначально PHP фреймворков – думаю имеет смысл прекратить тут непрофильную дискуссию :) Тем более сильно смахивающую на холивар.
    P.S.2. Спасибо за список фреймворков, про Merb немного слышал, про Sinatra даже не слышал. Видимо они из свежих. Посмотрю, возможно понравится.

  32. 32. Fusion Says:

    Yii
    http://www.yiiframework.com/

    :) people say it’s great!!!

  33. 33. andryk Says:

    Я работал достаточно долго с CodeIgniter, Kohana. Более-менее поигрался с Yii. Вот что я могу сказать. CI – да, когда то для меня это было фантастикой. Но сейчас я вижу что он недостаточно функционален, много нужно дорабатывать, поддержка пхп4. Kohana – в принципе очень даже хорош. Но оочень слабенькая документация, хотя покопавшись 1 день в коде все становится понятным. Yii – многофункциональный, с красивым кодом и расширяемостю. Но сыроват пока. В будущем нужно еще раз посмотреть.
    А пока что я изучаю Symfony. Не буду ее лишний раз разхваливать, но просто все что приходилось ранее делать ручками, тут уже реализовано. Автоматические темплейты, кодогенерация, layout, интеграция с двумя ORM.
    Еще немного работал с Zend. Все таки, имхо, это не фреймворк, а набор отличных классов. По этому zend нельзя сильно сравнивать, он немного в другой нише.

  34. 34. Валерий Says:

    Думаю скоро все равно перейдешь на Kohana. Я на симфони писал почти год. Я не фанат бороться за милисекунды, для меня куда более важнее боротся за скорость разработки, но Symfony даже меня раздражает своей тормознутостью. У нас сервер с двумя 4-х ядерными ксеонами иногда лежит. Хотя посещаемость 3000 хитов в сутки (это просто смешно).

  35. 35. relo_san Says:

    Валерий, это вы просто не тем местом на Symfony программируете. Рассказывать о тормознутости может только человек, который ничего не понял в фреймворке и не научился им пользоваться, кодил под ним “абы работало”. Вы выложите исходники вашего проекта, который при 3к хитов в сутки ложит четырехядерный ксеон, мы дружно посмеемся. У меня на несчастном VDS с одним гигагерцем проца и гигом оперативы средней сложности проект на Symfony почему-то позволяет обслуживать несколько кило _уников_ в сутки и сервер при этом не грузится более чем на 40 – 50% в пике и 10 – 20% в среднем, на нем еще пара проектов и трак на пайтоне спокойно висят. Доктор, что я не так делаю?

  36. 36. Валерий Says:

    Исходники конечно же я давать небуду. Но скажу просто так – приложение делает простую задачу – работа с формами, новости и т.д. Сдесь намудрить тяжело. Машина ложится лишь иногда. Есть страницы которые требуют 15-20 МБ памяти и время 1-2 сек на генерацию. Это вы считаете нормально?. С XCache конечно дело получше, но все равно несравнится с Kohana. Покажите свою страницу простую и расскажите сколько она потребляет памяти и времени на генерацию, и тогда посмотрим вместие и посмеемся.

  37. 37. Валерий Says:

    Сынок будешь так разговаривать – поди убейся головой об стенку.

  38. 38. relo_san Says:

    папаша, не учите меня пожалуйста, как разговаривать, ладно? :)
    Если вас что-то оскорбило – имхо это ваши личные проблемы. Я высказал свое мнение по поводу вашей безосновательной характеристики. Я, заметьте, даже на “ты” не переходил. Поэтому если вас что-то не устроило в моем посте – можете последовать вашему же предложению на ближайшей стене.
    Теперь по существу. Просто так говорить не нужно. Хотите показать конкретику – сделайте простой тестовый шаблон, протестируйте и выложите результаты тестов, с подробным указанием конфигурации, тестируемого исходника и полученных результатов. А просто так рассказывать что “ну очень тормозной, прям валится” – смысла не вижу. Работа с формами? Я не знаю где у вас и на какой форме нужно много времени на генерацию и 20 метров оперативы… Я таких форм пока не встречал. Если мне будет не влом и появится свободное время – я на выходных сделаю простую форму полей на 15, связанную с парой табличек пропелом и замерю генерацию.
    Что касается новостей – простите, а слово “кеширование” вам возможно знакомо? Или вы каждому посетителю новости каждый раз из базы тянете и генерите?
    Приложение на VDS, про которое я говорил – сайт с примерно 18 тысячами статей, ни малейших проблем на значительно менее мощной конфигурации я не наблюдаю, все работает как часы.
    Что касается распространенной практики использования фреймворка – простите, насмотрелся. Гавно можно написать на любом фреймворке и любом языке. И гавна этого я видел за свою практику – дофигища, особенно на PHP. И в Symfony в шаблонах видел строчки вида “… $_REQUEST …”. Поэтому если у человека вдруг обычное несложное приложение жрет ресурсов в десяток раз больше положенного – то либо там программист нуб, либо сисадмин, который сервер настраивал – нуб, либо оба. Обижаться или нет – ваше личное дело.

  39. 39. crash Says:

    TEH DRAMA

  40. 40. relo_san Says:

    Вдогонку. С xcache не работал, а вот APC кешит опкод на ура и вопрос с тормозами из-за огромных многометровых простыней ORM решается. Также, если у вас часто нужно работать с базой и нельзя многое переложить на кеширование – не рекомендуется использовать Доктрину, она раза в два тормознее Пропела. Для критических приложений, где объем работы с базой очень высок и нужно максимальное быстродействие/возможности – можно обойтись вообще без ORM и работать напрямую с PDO, хотя это точно не ваш случай.

  41. 41. Валерий Says:

    Кеширование в симфони отдельная тема. Где к примеру таги, вместо этого remove_pattern(). Потом, если я хочу кешировать не шаблон а что нибудь другое, то что предлагает мне симфони? сделать так new sfCachFile. А где же фабрика? А как легко потом переключить кеш на другой бэкенд?. Для этого придется писать свою фабрику. Разве это удобсто?.

  42. 42. Валерий Says:

    Посмотри на нормальное кешированеи, например в ZF или Kohana.

  43. 43. Валерий Says:

    И повторяю просьбу – покажи пример стриницы и раскажи нам сколько она жрет памяти и времени. А потом поговорим.

Leave a Reply