-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Подбор PHP фреймворков
- Автор темы java2xp
- Дата начала
ну, начнем с того что php это не java 
и в задачах, которые обычно решаются на php, orm нужен как собаке пятая нога. хотя есть реализации, тот же propel. я использую несколько иной подход, когда сам класс работающий с моделью сущности знает свои sql запросы для каждого действия. любой генератор убивает производительность. особо это касается mysql которому часто надо давать хинты типа use index.
mvc фреймворков жопой ешь, в гугл. я использую свой так что ничего не посоветую.
и в задачах, которые обычно решаются на php, orm нужен как собаке пятая нога. хотя есть реализации, тот же propel. я использую несколько иной подход, когда сам класс работающий с моделью сущности знает свои sql запросы для каждого действия. любой генератор убивает производительность. особо это касается mysql которому часто надо давать хинты типа use index.mvc фреймворков жопой ешь, в гугл. я использую свой так что ничего не посоветую.
FractalizeR
Новичок
Для MVC, наверное, хорошим выбором будет Zend Framework (http://framework.zend.com).
Для ORM, возможно, http://www.phpdoctrine.org.
Для ORM, возможно, http://www.phpdoctrine.org.
Alexandre
PHPПенсионер
+1
+1
http://www.google.ru/search?hl=ru&q=php+mvc&lr=
аналог strutshttp://phpmvc.net/, но когда я ее изучал - это был еще РНР4... не знаю, есть ли реализация под 5ю...
http://wiki.agiledev.ru/doku.php?id=ooad:manage_dependencies_in_php_code
там есть описание нескольких (2
) контейнеров
там есть описание нескольких (2
) контейнеровatv
Новичок
Пользовал, и остался очень недоволен.
Плюсы:
1. Достаточно документации, если чего не хватает, можно найти ответы на форуме.
2. Есть возможность генерировать скрипты по заданным модели данных и настройкам.
3. Интегрированная ORM, поддержка UnitTesting, и практически законченный цикл Build - Package - Deploy.
4. Может ещё что-то, пока не вспомню.
Минусы:
1. ОЧЕНЬ большое количество различных соглашений об именовании файлов, классов, методов, функций, настроечных параметров конфигурационных файлов, и много чего ещё. Документация по этим соглашениям разбросана по документации и не всегда полная. Не зная этих соглашений запустить приложение не получиться. Часто встречаются баги.
2. Достаточно костная архитектура, трудно поддаётся расширению. Очень много различных настроек, с которыми приходиться разбираться, чтобы запустить приложение.
3. Отсутствие шаблонизатора. Для меня это большой минус, так как много времени уходит на написание шаблонов. Часто приходиться использовать копи-пасте. Из-за отсутствия шаблонизатора, кастомизация сгенерированных скриптов достаточно сложная.
4. ОЧЕНЬ плохое качество кода. Методы по 300 строк кода для этого фрэймворка практически норма. Это сводит на нет все попытки расширения фрэймворка и исправления багов. Править исходные коды фрэймворка - это не есть хорошо, а отнаследоваться от него, чтобы обойти баг не всегда получается. Если и получается, то приходиться переопределять весь метод на 300 строк, чтобы в одной строчке внести изменение функциональности или исправить баг. Это же относиться и к интегрированной ORM PROPEL. Непонятно для чего в классе Criteria все свойства объявлены как private - и всё, и уже ничего с ним не сделаешь.
5. Было ещё что-то по мелочам, пока не вспомню.
Вобщем, не удивительно, что у программистов появляется такое стойкое отвращение к фрэймворкам, если их знакомство начиналось с Symfony, самого раскрученного фрэймворка. Тем не менее, не думаю, что менее раскрученные фрэймворки будут обязательно хуже, просто у Symfony маркетологи оказались лучше чем программисты.
dark-demon
d(^-^)b
> Отсутствие шаблонизатора.
после этого сию штуку можно смело сдавать в утиль...
после этого сию штуку можно смело сдавать в утиль...
dark-demon
d(^-^)b
и полное отсутствие ооп...
dark-demon
d(^-^)b
если другими номинантами были симфония и ей подобные, то это не удивительно
dark-demon
d(^-^)b
какое мнение? о пользе ооп или о пользе шаблонизаторов?
Black Raven
Новичок
1. соглашения не такие уж и сложные. автолоад тоже простой. документация доступна, поиск тоже. туторы очень подробные.
2. за 6 месяцев в симфони багов не заметил, хотя может не сильно ковырял.
если уж при таких туторах есть проблемы, то это странно.
опять же интересно что там понадобилось расширять, что это сложно сделать. (если есть время и желание - пиши в личку. с удовольствием пообщаюсь, потому что действительно интересно.)
1. напиши свою реализацию view. благо дело не очень сложное.
2. откуда у тебя было дублирование кода в шаблонах? хелперы для работы с "шаблонами" есть...
врать не буду - не раскручивал всё, может и есть такие методы.
propel и criteria имеют довольно отвлеченное отношение к симфони.
маркетологи у них видать шаманы, раз зомбировали гугл и яху...
т.е. сделать свой view с использованием любимого шаблонизатора это сложность?
---
Wicked
Ты видимо пользовал симфони, можешь высказать своё мнение? А какие еще фреймворки пользовал и какие плюсы у кого заметил? (если несложно конечно, ибо тема интересует.)
atv
Новичок
Я не говорю что они сложные, я говорю что их много, очень много, я до сих пор забываю что и где нужно писать.
Я активно использую генератор админки, именно в нём и обнаруживаю много багов, многие из которых связаны с соглашениями по именованию. В частности, много проблем возникает когда используешь маппинг колонок таблицы на свойства объекта, генератор в этом случае генерирует бажный код фильтров и сортировки.
Туторы хорошие, это правда, и я записал это в плюсы, но шаг влево шаг вправо от тутора смерти подобен.
"Достаточно костная архитектура, трудно поддаётся расширению." В архитектуре заложено что обязательно должен быть шаблон layout.php, который мне совершенно не нужен, если я хочу прикрутить XSLT шаблонизатор - это один из примеров костности архитектуры. Изменить это поведение очень сложно, так как оно находиться в методах по 300 строк размером, в которых трудно разобраться и не наделать багов. К тому же, если я прикручу XSLT шаблонизатор, то хелперы окажутся совершенно бесполезными, и придётся написать свои. Так что тогда останется от Symfony?
Я не нашёл способа подключить в нескольких модулях один и тот же partial template, пришлось копировать файл с этим шаблоном во всемодули. По поводу хелперов - они оформлены в виде функций, это означает, что я не могу его чуть-чуть изменить, только полностью переписывать на свой. Там есть такой хелпер как admin_double_list, который мне и нужно было изменить, так как у него вёрстка зашита прямо в коде. Конечно, в отсутствие шаблонизатора по другому и не сделаешь.
Если интеграция с ORM PROPEL заявлена как плюс фрэйворка, то и минусы PROPEL имеют отношение к фрэймворку. А без ORM, а тем более генератора админки, это вообще пустое место.