Давно не делали опрос о популярности php-фреймворков. Это, конечно, не волшебный мир JavaScript, где всё меняется каждые полгода-год, но всё-таки и в php тоже постоянно идут изменения.Выпускаются новые версии, что-то устаревает, что-то входит в моду и т.д. Один фреймворк более «компонентный» и лучше следует принципам SOLID, другой удобен для быстрого старта, третий имеет хорошее комьюнити.
Итак, опрос для тех, кто использует php в своей практике.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (249)
Fractalzombie
30.03.2017 09:42-5Symfony, Laravel, Vuejs
redfs
30.03.2017 09:49+2Кмк, не совсем корректно микрофреймворки типа Slim держать в одном списке с теми же Laravel, Yii. Все-таки у них немного разные ниши.
varanio
30.03.2017 09:52+2Возможно, вы правы. Но все-таки они в некоторой степени конкурируют друг с другом.
В любом случае, лучше не усложнять опрос, а то люди будут лениться заполнять.
DeadikGudwin
30.03.2017 09:53+2На данный момент у нас cakephp в основном используется
malinichev
30.03.2017 10:05+3Сейчас CakePHP вроде нормальный, косит под Laravel немного)))
Раньше конечно был адским немного… Наверное неплохо постарались над улучшением, да и над дизайном они явно постарались)))DeadikGudwin
30.03.2017 15:15У нас версия 2.X, его новым не назовать, заказчик очень консервативен и переписывание проекта не одобряет) Проект долгоиграющий, так что приходится мирится)
malinichev
30.03.2017 10:15+1Я использую Phalcon, Yii2. Для длительного проекта выбрал бы Yii2 из-за скорости разработки, а для простого, или с усиленной безопасностью — то выбрал бы Phalcon, чтобы всё руками сделать
jtiq
30.03.2017 10:22Использую Nova Framework, кто нибудь использовал его вообще?
Sky4eg
30.03.2017 11:19Почитал документацию, не покидает ощущение слизанности с Laravel. Многие моменты вообще идентичны. И как вам в целом данный фреймворк?
jtiq
30.03.2017 18:59Я посмотрел, там есть компоненты от Laravel. Мне показалось от него многое унаследовано. Простой, можно дополнять. Примеров маловато, есть видео уроки от самого создателя. Ну, а так в целом я использую не нагруженном проекте.
NeoCode
30.03.2017 10:45-7А вот на каком фреймворке например написан Вконтакте, Гугл, Ютуб, Яндекс, тот же Хабр? Мне кажется ни на каком.
Я тут конечно не эксперт, практического опыта именно работы с фреймворками нет. Но зато есть обширный опыт программинга на С++. Пытался изучать фреймворки по книгам и видеоурокам, в результате пришел к выводу что фигня все это, огромное количество лишних абстракций которые ничего не решают вообще а только создают дополнительные прослойки и сложности.
Может быть это полезно для тех кто штампует небольшие сайты на заказ и важнее всего скорость. А для реальных высоконагруженных проектов вообще целесообразнее написать прототип на одном из веб-языков (php, python...), а затем переходить на тот же С++ или что-то компилируемое, чтобы не занимать процессор выполнением кода интерпретатора, а память — хранением динамически типизированных объектов.
daggert
30.03.2017 10:57+8Я конечно тот еще быдлокодер, тоже не люблю фреймворки, но, когда пришлось работать в команде из 20+ разработчиков, местным аналогом тимлида, мне пришлось очень быстро склепать свой фреймворк на базе того говнокода что уже был написан годы назад, а затем 7 лет переписывать его не ломая обратную совместимость, просто по тому что командная разработка разительно отличается от одиночных проектов. Теперь да, это уже полноценный внутренний фреймворк, с весьма хорошей архитектурой целиком удовлетворяющий требования уже не первого заказчика и документированная на 150 листах мануала (не считая комментариев кода), но когда грянул гром — это была мешанина из своих мыслей, в которых черт ногу сломит и новичкам трудно было даже написать простой модуль — слишком большой объем кода нужно было перелопатить чтобы вникнуть в суть.
Еслиб начинал сейчас, начал-бы свой проект на Yii, но тогда его еще и в помине не было.
http3
30.03.2017 14:24свой «фреймворк» == не использую фреймворк
daggert
30.03.2017 14:57Закрытый фреймворк != не использую фреймворк. Данная система используется в десятке корпоративных веб-приложений и активно развивается усилием до 40 разработчиков. То что он не выложен на гитхаб — ну уж простите, я как создатель имею право выбирать какое ПО делать.
http3
30.03.2017 15:06+1Хм, но глупо считать, что те, кто проголосовал за последний вариант копошаться в дерьме из вермишели и палок. :)
daggert
30.03.2017 15:21Черт его знает. Много что повидал за эти года.
А для тех кто хочет проголосовать за свой фреймворк, есть удобный вариант «другой» и указать его в комментариях. Понятное дело что охватить голосованием все не вариант.
Fesor
31.03.2017 09:01знаете, если мне предлагают проект на суппорт, я по умолчанию буду делать предположение что там лапша или лазанья. Это никак не зависит от того на чем проект делался. Зависит только эффорты на рефакторинг.
http3
31.03.2017 09:21-1Хм, то есть и на фреймворках (публичных мейнстримовых) пишут вермишель?
(Я как бы этого не отрицаю, просто уточняю :) )
Тогда не плевать ли, используется мейнстримовый фреймворк или самопись?NexOtaku
04.04.2017 20:57+2Не плевать. В проект на знакомом фреймворке быстрее вникнешь и сможешь что-то сделать для заказчика.
http3
05.04.2017 09:27А что вообще нужно от фреймворка?
Работа с базой и кеш? (Это 90+% разработки)
Я вот быстро вник в незнакомый фреймворк. :)
В мои 50 кБ кода вникать не долго.
Или Вы фрилансер?
Ну тут да.
Fesor
04.04.2017 22:34+2пишут вермишель?
конечно.
Тогда не плевать ли, используется мейнстримовый фреймворк или самопись?
ну одно дело когда у вас вермещель размазанная по крепкому каркасу (иногда там размазана лазанья и это хуже немного) и другое дело когда крепкого каркаса нет и все просто смесь из вермишели.
http3
05.04.2017 10:37А у меня не вермишель на самописи.
Возможно, кому-то и нужен фреймворк и батог для дисциплинирования, мне нет :)
Хотя, без понимания, все равно будет вермишель :)
Довелось встречать лазанью на фреймворках:
- html код выводился через echo 'some long html code'
- Модели наследовали ActiveRecord, но при этом его не использовали, а дергали какую-то самописную фигню, при этом в этой фигне не было конструктора запросов, каждый запрос писался вручную.
Fesor
05.04.2017 10:47+1А у меня не вермишель на самописи.
выложите на github, сделаем ревью.
Довелось встречать лазанью
вы видимо не поняли что есть "лазанья-код". Это когда разработчики начали делать слоеную архитектуру (не mvc, это один слой где m на границе другого) и для внесения любых изменений приходится "прорезать" все слои нашей лазаньи.
Фреймворки — это один слой. Он не может быть лазаньей по определению. Далее уже все зависит от того как разработчик работает с фреймворком.
html код выводился через echo 'some long html code'
интересно в каких таких фреймворках вы это видели. Вы про чушь аля
CHtmlиз yii? ну может быть. Или вы про скомпилированные шаблоны twig? Ну так там в этом и суть.
Модели наследовали ActiveRecord, но при этом его не использовали, а дергали какую-то самописную фигню
ActiveRecord — это как подразумевает название — работа с одной записью. Скорее всего "в самописной фигне" разработчики попытались реализовать что-то типа dao но судить о плохости могу только видя код.
http3
05.04.2017 13:56-1выложите на github, сделаем ревью.
Лазаньи у меня нет.
Но есть другие причины:
http://blog.kpitv.net/article/когда-будет-публичный-релиз-ядра-15373/
И для внесения любых изменений приходится «прорезать» все слои нашей лазаньи
И такое было.
Я просто не знал как подробнее описать.
Реально, проще назвать лазанья :)
интересно в каких таких фреймворках вы это видели.
Yii.
Но вряд ли это только он виноват.
Скорее тупость писавших. :)
franzose
05.04.2017 14:03+1Ваше «ноу-хау» никому не нужно, кроме вас, это же очевидно. При этом вы боитесь, что вас закидают помидорами, ибо давно бы уже выложили свои «50 Кб» в общий доступ.
http3
05.04.2017 15:29-3Ну, если никому не нужно, то зачем его и выкладывать? :)
Хотя постоянно просят выложить.
Я не хочу, чтобы свиньи не оценили бисер.
Ну и оно не презентабельно пока. :)
Fesor
05.04.2017 14:45Но есть другие причины:
напомню что часть исходников таки у вас вытекла. И да похвастать там было нечем. А что до "ноу хау" — скорее "хау абаут ноу"
Yii.
я не воспринимаю Yii как серьезный фреймворк. Не в обиду людям которые его юзают. Что там с Yii2 понятия не имею — не слежу уже лет 7 за ним.
http3
05.04.2017 16:47напомню что часть исходников таки у вас вытекла
То не ядро было :)
Да и там ничего плохого не было :)
П.С.
Кстати, статья обновлена. :)
pbatanov
06.04.2017 09:01+3Не воспринимаю Yii как серьезный фреймворк с тех пор как осознал, что у них все встроенные вещи построены на обязательных паблик полях. В лучшем случае на protected, в случае с AR. Вкупе со статикой люди начинают делать из этого АД. во второй версии все то же самое.
ellrion
30.03.2017 11:07+6Очень многие большие и сложные проекты написаны на фреймворках (Рельсы, Джанго, Лара и Симфони) вполне легко найти инфу. Полемика нужны ли фреймворки гудел лет 4-5 назад. И фреймворки победили.
http3
30.03.2017 16:24-3Миллионы мух не могут ошибаться :)
ellrion
30.03.2017 16:34Оставьте эту пошлую риторику. Не хотите фреймворки? Так я вам их не продаю.
http3
30.03.2017 16:40-1При чем пошлая?
При чем риторика?
Вы сказали, что была полемика и была победа. :)
Я же усомнился в ваших словах. :)
Я у вас ничего и не покупаю.taral
30.03.2017 17:46+4Вот только усомнились вы в правильности решения использовать фреймворки, приведя как аргумент их популярность.
Как единственный аргумент это действительно выглядит пошло.http3
31.03.2017 09:36-3Вам нужны аргументы?
Ну ок: :)
Почему я не использую в личных проектах PHP фреймворкиtaral
31.03.2017 10:00+6Недостатки выбраны превосходные. Чего стоят только
1. Плохая документация
2. Не самое логичное формирование путей для файлов
3. Дибильная работа с БД
4. При выпуске новых версий как правило отсутствует обратная совместимость
5. Неудобно создавать статические страницы
6. Нету возможности выполнить другой контроллер
…
И теперь главное. Эти недостатки автор приписывает ВСЕМ фреймворкам. У меня это взорвало мозг.
Сложилось впечатление что автор работал с yii 1. Но назвал это всеми фреймворками. Что удивляет еще больше так это дата этой статьи 2016 год. Автор критикует yii 1 который вышел в 2008 (!) году.
Также судя по разделу работы с базой данных автор не разобрался как правильно делать join. Но это не помешало ему найти сообщение на форме с корявым использованием и критиковать это =)http3
31.03.2017 10:28-71. Она действительно плохая.
Расчитана на дебилов.
2. Ну да, там точки, там /, там \, я в этом не смог найти логику :)
Там включается название «модуля», там нет.
3. Если есть дибильный простой способ, то он и будет использоваться.
Законы Мерфи.
Ну и об этом советуют на форуме фреймворка.
Ну и то обсуждение вроде ж не 2008 года.
Ну и это значит, что фреймворки не святые, а эволюционирует.
Но так само может эволюционировать и самопись.
4. Ну да.
Программисты на фреймворках никогда не останутся без работы.
5. А разве удобно?
6. А разве обойтись одним «контроллером» нормально?
Выходит потом огород из костылей.
Yii 1.1 вышел в 2008 году?
Yii 1.1.17 афаир вышел в 2016 году.
Ну, то есть, Вы хоть какие-то контраргументы нашли только для п. 3.
Эти недостатки автор приписывает ВСЕМ фреймворкам.
Читай внимательно:
Как сказано выше, это не значит, что пункт не подходит к другим фреймворкам.
pudovMaxim
31.03.2017 11:21Разрази меня гром!
Вы свое абсолютное невежество в знаниях фреймворков (да похоже и архитектуры проектов в целом) вылили в бессмысленную статью совершенно оторванную от реальности.
Спрячьте(-сь). Не позорьтесь. Не надо так.
sumanai
31.03.2017 16:36+1Откуда столько упорства в донесении своих мыслей до людей, которые сливом вашей кармы до -50 из раза в раз показывают, что вас тут слушать не хотят? Это кстати какой ваш клон по счёту?
http3
31.03.2017 16:54-5Та мне плевать на карму :)
sumanai
31.03.2017 16:59+1Да я не это спрашивал. Упорство откуда? Где источник ваших нескончаемых сил? Что поддерживает вас в вашей борьбе в плевках против ветра?
http3
03.04.2017 14:59Может в том, что вы меня не слышите? :)
Я не говорил, что фреймворки не стоит вообще использовать.
Я говорю, что я не использую в личных проектах.
При этом не отрицаю, что они используются на работе.
Против чего же я выступаю?
Против утверждения (явного или не явного), что фреймворк подходит всем и для решения всех задач.
Против утверждения, что все те, кто не использует фреймворк, те лохи, а использует — д'Артаньяны.
Я так же само выступаю против дрочки на ООП.
Против хайпа на Реакт / Ангуляр.
Я говорю, что нужно думать о целесообразности использования того или иного решения каждый раз.
Похожая точка зрения дана тут относительно использования наследования / композиции:
https://habrahabr.ru/post/325478/
Ну и все же следует признать, что аудитория чуток потупела все же.
Ну и у аудитории плоховато с юмором.
Хз как они отнесутся к комменту, оставленному для прикола.
Но вот сторонника фреймворков обвинили чуть ли не в поддержке моей позиции :):
Получу ли я адекватный ответ на этот коммент? :)
Вряд ли. :)
П.С.
Перечитал еще раз Ваш ответ.
Вы как бы и сами констатировали, что меня не хотят слышать :)
Но я не говорю, чтобы меня слушались.
Аудитория глухая? :)Fesor
03.04.2017 17:42Против утверждения (явного или не явного), что фреймворк подходит всем и для решения всех задач.
кто-то где-то подобное утверджает?
Я так же само выступаю против дрочки на ООП.
смотря что считать ООП. Если вы про идею тотальной инкапсуляции и late binding то это одно. А если паттерны, расширение за счет наследования и AbtractFactoryFactory — это совершенно другое. Первое это развитие идей структурного программирования, а второе это рак.
http3
04.04.2017 09:42кто-то где-то подобное утверджает?
Ну вот в этой ветке.
Но в соседней теме Вы дали самописи 0,1%, и на том спасибо. :)
паттерны, расширение за счет наследования и AbtractFactoryFactory
Это.
Паттерны я бы выделил отдельно в паттерны головного мозга, паттерны наше все. :)Fesor
04.04.2017 12:28Но в соседней теме Вы дали самописи 0,1%, и на том спасибо. :)
На сегодняшний день в 50% случаев и бэкэнд свой писать не надо. не то что фреймворки свои писать.
Паттерны я бы выделил отдельно в паттерны головного мозга, паттерны наше все. :)
обычно с паттернами разработчики переживают три стадии:
- паттерны это круто, они делают код лучше
- паттерны отстой, они делают код сложнее
- о, так выходит надо знать когда чего юзать...
Все это больше от непоследовательного изучения и культ карго.
alsii
31.03.2017 16:59Соблюдайте правила производственной гигиены!Fesor
31.03.2017 09:04Я же усомнился в ваших словах. :)
я так и не понял вашей позиции. Вы против именно full-stack фреймворков с готовый структурой но не против отдельных компонентов с помощью которых можно сделать свой фреймворк под задачу. Или вы вообще против любых third-party решений?
http3
31.03.2017 09:27-2Я не против сторонних решений вообще :)
И я не против full-stack фреймворков вообще.
Просто имеющиеся переусложнены.
Правда, я не особо ковырялся с минифреймворками вроде Silex/Slim.
Они считаются full-stack или нет?Fesor
31.03.2017 10:15-1Просто имеющиеся переусложнены.
потому что они хэндлят штуки о которых вы не думаете? Это не переусложнение. Ну и да, не надо сравнивать с решениями вроде yii, там действительно все плохо и да это субъективная оценка.
Они считаются full-stack или нет?
да, они проще. Они хороши когда вам нужно что-то простое сделать. Например read-only часть приложения или чего еще.
http3
31.03.2017 10:34-1потому что они хэндлят штуки о которых вы не думаете?
Да.
Я хочу понимать всю подноготную работы приложухи.
С самописью я понимаю. :)
yii, там действительно все плохо
Его критикуют за более монолитность. Мне это не особо важно.
Но разве что-то мешает использовать сторонний код в нем?
Те же компоненты от Симфони? :)
Моя самопись, если честно, тоже местами монолитна.
Это как бы не совсем гибко, но эта гибкость и не нужна пока в тех местах. :)
Они хороши когда вам нужно что-то простое сделать.
Все вещи желательно делать простыми, а не сложными. :)Fesor
31.03.2017 11:04+1С самописью я понимаю. :)
А другие разработчики которые будут поддерживать после вас? Им же тоже придется разбираться и для них будет тоже самое что и любой другой фреймворк.
Я хочу понимать всю подноготную работы приложухи.
Вы изучали как работает Zend VM? Ибо по вашей логике для комфортной работы вам и этот уровень абстракции надо залесть. Ну и ниже, как вообще работает выполнение машинного кода, как операционная система изолирует память для процессов, как разруливает приоритизацию процессов, контекст свитчинг и т.д.
Но разве что-то мешает использовать сторонний код в нем?
Есть нюансы. Многие вещи там тупо нельзя заменить не перелопатив половину всего.
Все вещи желательно делать простыми, а не сложными. :)
KISS и все такое? Обычно в качестве примера предлагают историю из 60-х когда главный инженер потребовал спроектировать сверхзвуковой истребитель который пилот может починить обычными инструментами в поле.
Другими словами вещи должны быть простыми в использовании и обслуживании, но это не означает что внутри все будет просто и уж тем более сделать так бывает крайне сложно. Можете просто почитать про трудности которые пришлось решать когда делали usb type-c. Его легко юзать, но там были интересные задачи.
http3
31.03.2017 14:08-4А другие разработчики которые будут поддерживать после вас?
Почему я не использую в личных проектах PHP фреймворки
Им же тоже придется разбираться и для них будет тоже самое что и любой другой фреймворк
Там всего 50 килобайт :)
Ибо по вашей логике для комфортной работы вам и этот уровень абстракции надо залесть.
На этот не нужно.
Только *.php код. То, с чем я работаю.
сделать так бывает крайне сложно
Просто сделать сложно.
Сложно сделать просто.
:)
Djeux
30.03.2017 11:30+1Когда надо в кратчайшие сроки запустить проект чтобы начал приносить деньги, особо нет времени заниматься велосипедо-строением дабы избежать фатального недостатка.
greatkir
30.03.2017 11:43Позвольте слегка не согласиться.
Да, фреймворки содержат огромное количество абстракций, но никто не заставляет использовать все возможности конкретного фреймворка. Пишите свой, более быстрый код, который не «создаёт дополнительные прослойки и сложности». Вот только зачастую, чтобы добиться такой же гибкости и стабильности, придется написать как бы не более сложную и запутанную структуру. Всё же код фреймворков оптимизируется постоянно.
Что касается интерпретатора — нагрузка на процессор значительно снижается путем использования того же OPCache, благодаря сохранению однажды использованных структур и данных в памяти. Очень приближенно можно сказать, что в результате процессор будет выполнять только полезную работу, не повторяя раз за разом те же расчеты.
UnknownUser
30.03.2017 14:02Кроме всего перечисленного, задам вопрос, а какой процент разработчиков пишет крутые проекты типа Гугла, Вконтакта или Фейсбука?
С нуля писать конечно очень увлекательно, но пока вы это делаете, конкурент уже забацает двадцать штук интернет магазинов на одном из перечисленных фреймворков.http3
30.03.2017 15:14-2А сколько времени писались
Гугла, Вконтакта или Фейсбука
? :)
Годами, что ли? :)UnknownUser
30.03.2017 20:35До сих пор пишутся )).
Кроме того, это не совсем стандартные проекты, плюс работают под дикой нагрузкой.http3
31.03.2017 09:42-3Ооо, они до сих пор не написаны?
Откуда Вы о них узнали тогда? :)UnknownUser
31.03.2017 10:52Вообще то код этих проектов постоянно правят. Вот что я имел в виду.
Как, собственно, и большинство остальных проектов ).http3
31.03.2017 11:53-4А на фреймворке раз написал и править не нужно? :)
Fesor
31.03.2017 12:08код самого фреймворка правит комьюнити и поддерживает его. Занимается оптимизациями, багфиксами, секьюрити ишусы находит и исправляет.
Если без фреймворка мы будем делать ровно то же самое только сами и в своем. И тут не надо много ума что бы понимать что это не так эффективно.
http3
31.03.2017 14:59-3Возвращаемся назад.
Гугл писался годами? :)
Повторное использование кода в самописи тоже запрещено? :)
porn
31.03.2017 16:50+1Вы наивно полагаете, что гугл написан один раз и сейчас он в своём первозданном виде?
Сегодняшний гугл писался годами и пишется прямо сейчас.http3
31.03.2017 17:06-4гугл написан один раз и сейчас он в своём первозданном виде?
Где я такое писал?
Сегодняшний гугл писался годами и пишется прямо сейчас.
Где я это отрицал?
Fesor
31.03.2017 17:09Гугл писался годами? :)
инкрементами и по чуть чуть уже десятилетиями. Что до "использует ли гугл фреймворки" — точно использовали django лет так 8 назад, используют разные ангуляры и и т.д. До этого тоже были продукты от них. И до этого…
Повторное использование кода в самописи тоже запрещено? :)
Код нельзя реюзать. Если вы видите в коде общие вещи вы должны выделить из этого абстракцию и вот уже абстракции реюзать можно.
http3
31.03.2017 17:39-3инкрементами и по чуть чуть уже десятилетиями
А самопись не может так же писаться? :)
точно использовали django лет так 8 назад
Ого.
Ангуляр — это js и их же разработка…
Код нельзя реюзать. Если вы видите в коде общие вещи вы должны выделить из этого абстракцию и вот уже абстракции реюзать можно.
Что за ерунда?
Fesor
31.03.2017 09:05Годами, что ли? :)
Ну какбы да. В целом если разработчики больше не коммитит код в проект то велика вероятность что проект мертв. А значит если вашему продукту лет 10 и более то его продолжают писать.
gearbox
30.03.2017 20:38+2интернет не ограничен одними интернет-магазинами. Фреймворки хороши когда a. ты их знаешь b. ты занимаешься чем-то относительно стандартным и это стандартное ложится на логику фреймворка.
Шаг в сторону от мейнстрима — и добро пожаловать в клуб велосипедостроителей! Только я не понимаю когда говорят от построении «с нуля». Нет никакого нуля, просто переходим на более низкий уровень — берем либы и компонуем. Нормальный такой процесс, почему нет.Fesor
31.03.2017 09:08ты занимаешься чем-то относительно стандартным
аля "пишу http-based апы?" В любом нестандартном проекте есть "стандартные" части. Вроде "а как логи писат" или "а как хэндлить master/slave коннекшены к базе" или "а как зависимостями управлять в проекте". И в итоге мы берем любой фреймворк, возможно выкидываем отдельные компоненты и живем.
gearbox
31.03.2017 17:44>В любом нестандартном проекте есть «стандартные» части. Вроде «а как логи писат» или «а как хэндлить master/slave коннекшены к базе» или «а как зависимостями управлять в проекте».
Вы меня простите великодушно если я заблуждаюсь, но все же вынужден спросить — Вы разницу между фреймворком и либой понимаете?
taral
30.03.2017 18:07+1Вы разумно рассуждаете. Наводите хорошие примеры. А вот вывод не корректный.
Действительно если вы пишете гигантский сервис при разработке которого участвуют сотни человек. И работа идет годами. Тогда важность использования фреймворка опускается до 0. Вот только с этого утверждения вы делаете (не корректный) вывод что сфера применения фреймворков — маленькие сайты. Yahoo! и BlaBlaCar используют symfony. 2gis.ru использует yii.
«Маленькими сайтами» назвать их язык не повернется.
Ваше желание использовать C++ при веб разработке понятно. Ведь это ваш основной язык (с ваших слов). И его действительно в некоторых случаях стоит применять. Но в подавляющем большинстве случаев использование C++ как базового языка для веб приложения сродни самоубийству. Слишком увеличивается скорость и сложность разработки и поддержки такого проекта. Мы живем не в вакууме и это нельзя спускать со счетов. А вот самые высоконагруженные места можно и на C++ написать. В угоду скорости.
Pinsky
30.03.2017 11:02Есть свой ADR масштабируемый микро-фреймворк.
На работе модифицированный ZF1.
Давно присматриваюсь к PHPixie.Fesor
31.03.2017 09:11свой ADR масштабируемый микро-фреймворк.
Вот вы юзаете ADR. Расскажите как. Правильно ли я понимаю что ADR у вас сводится к тому что формирование респонсов и запросы на чтение вынесены в респондеры? Бывает ли так что "экшен" занимается лишь инвоуком респондера? У вас апишки или сервер плюется html-ем (что бы примерно прикинуть что внутри респондера). Ну и в целом какие ограничения вы накладываете на эту троицу? Чего там быть например не должно, какие взаимоотношения и уровень знаний у action к resonder и т.д.
IvanSCM
30.03.2017 11:05+2Использую уже два года Nette чешский. Быстро разворачивается, есть composer библиотеки.
Nord001
30.03.2017 12:17Вы его сами выбрали или досталось по наследству? У меня после 3 месяцев работы очень негативное к нему отношение.
IvanSCM
30.03.2017 15:38Выбрал сам, подкупил документацией и легкостью. А в чем причина негативного отношения?
Nord001
30.03.2017 15:44Тем что он MVP и очень мало где используется. Но это чисто субъективное мнение.
Я с ним имел дело года 3 назад и не с нуля.Fesor
31.03.2017 09:23+2Тем что он MVP
давайте разбираться в разнице между mvp и mvc:
То есть сугубо говоря mvc в трактовке php фреймворков ничем не отличается от mvp.
AlexLeonov
30.03.2017 11:39+6За многие годы использования фреймворков, а были у меня в продакшне и известные, такие как Symfony, Yii, Laravel, так и свои, пришел к выводу, что монолитные фреймворки как бы не особо нужны, а иногда, как Yii, и вредны (да-да, я про $breadcrumbs в контроллере!)
В результате сейчас имею десяток своих слабосвязанных библиотек для разных случаев жизни, написанных в одном стиле и общий для них MVC-каркас (если вдруг он нужен).
Всё это активно используется как в собственных проектах, так и профессионально (за деньги), развивается и адаптируется под новые версии PHP. Заодно на тех же библиотеках студенты у меня учатся участвовать в командной разработке, использовать TDD и вообще прикасаются немного к «взрослому» программированию в плане огранизации своего труда.
Планирую этому хозяйству однажды дать звучное имя и выложить в публичный доступ, как очередной мега-фреймворк-убийца-всех-остальных :)) Но врожденная скромность и вечная прокрастинация всё как-то мешают…
Резюмируя: хорошего фреймворка на PHP еще нет, у всех какие-то свои скелеты под капотами, но что-то мне подсказывает, что сообщество к нему уже готово. И, значит, он скоро появится.varanio
30.03.2017 11:42+7Symfony можно использовать как набор слабосвязанных библиотек, не обязательно тянуть весь
AlexLeonov
30.03.2017 12:22+2Чем он выгодно и отличается от других актуальных фреймворков.
Serganbus
30.03.2017 13:18Собственно, вы с Zend'ом знакомы? Там куча отдельных компонентов на все случаи жизни
AlexLeonov
30.03.2017 13:50+1Собственно да.
Но всё равно берусь утверждать, что это сильно связанный фреймворк. Несмотря на наличие компонентов на все случаи жизни.
Одно другое не исключает.
sumanai
30.03.2017 17:18+1Сейчас все актуальные фреймворки перешли на компонентный подход.
ghost404
30.03.2017 20:40+4Правильней говорить:
Сейчас все актуальные фреймворки перешли на компонентны Symfony)))
AlexLeonov
30.03.2017 21:46Значит не за горами появление чего-то нового. Не может Symfony быть вечным.
riky
30.03.2017 17:21на базе компонентов symfony можно свой фреймворк сделать, сам когда то делал. ну и laravel так сделан.
Alexeyco
30.03.2017 11:51Laravel. Т.к. он наиболее популярный (или один из). До того использовал Kohana, но позже решил, что эта мнимая легкость и простота гораздо менее важны, чем возможность располагать гигантской кодовой базой. К примеру, в Kohana не было толком даже миграций, mptt-модуль пришлось писать самому. Ужасно. Сейчас с этим гораздо проще.
alexoron
30.03.2017 11:54-20Последний раз ковырялся в вашем ПеХаПе наверное в 2004 году.
И тогда ООП только только начинал внедряться, пятая версия тогда вышла.
Сейчас вижу седьмая вышла.
До чего прогресс дошел, ваш ПеХаПе показывают и тут и там
YaakovTooth
30.03.2017 13:08+2При всей моей нелюбви к PHP — вы держите, пожалуйста, в курсе. Это очень важно.
Update: пока писал комментарий — уже за меня выше ответили. :3
Sora
30.03.2017 12:02Zend это не только Zend Framework но и микрофреймворк Zend Expressive. Но, судя по опросу, все равно не в тренде :)
gromdron
30.03.2017 12:12+9Хочется Laravel, Symfony, Yii, Phalcon, Zend… а на практике — Битрикс и NoNameShitFramework
pudovMaxim
30.03.2017 12:24+1по-моему zend со второй версией очень долго жевал сопли и его обскакала «Symfony-based коалиция» и начала продвигать свой путь на рынке, из-за чего zend просел еще сильнее.
gromdron
30.03.2017 13:09Не исключено, что ZF3 позаимствовал компонентный подход у Symfony, но это же не делает его менее привлекательным, правда?
В конце концов, даже не особо популярный в России ZF3 иногда сделан куда лучше своих 'битриксовых' аналогов.pudovMaxim
30.03.2017 19:53ой, извиняюсь, я оказывается веткой промахнулся :)
Мое сообщение должно быть чуть выше к комментарию Sora
Tomio
31.03.2017 10:33Буквально вчера видел тему на форуме пхпклаб, как один человек хотел внедрить Laravel в Битрикс, так как ему не хватало доступного функционала админки битрикса))
Лично я сам уже переборол себя и потихоньку с Битрикса перехожу на Лару (по крайней мере перевожу свои проекты). Надоело вариться в этом котле безрассудства и похоти)porn
31.03.2017 11:37В прошлом году подобное выступление былоhttp3
31.03.2017 13:58внедрить Laravel в Битрикс, так как ему не хватало доступного функционала админки битрикса
Упс. :)
Скрещивание ежа с ужом :)
Админка нормально кастомизируется стандартными средствами.
Можно добавлять пользовательские типы данных.
Akuma
30.03.2017 13:07+3Перешел с Symfony на Silex, как ни странно. Из Silex по сути используется роутинг и контейнер, остальное либо добивается компонентами той же Симфонии, либо самописными компонентами.
Fesor
31.03.2017 09:31А как же
MicroKernelTrait? С появлением оного у silex-а вообще не осталось смысла в существовании. Его и сделали исключительно как пример как можно собрать по быстрому фреймворк на компонентах симфони.Akuma
31.03.2017 11:56Честно сказать, не слышал и не пробовал. Возможно когда я ставил Силекс, его еще просто небыло.
Он и так «микро». Работает шустро, все что мне нужно предоставляет — что еще нужно то? :)
alsii
31.03.2017 17:07А чем плох контейнер от Symfony? Вопрос без сарказма
SerafimArts
31.03.2017 23:53Ну по сравнению с контейнером лары — он довольно ограниченный. Нет двойной диспатчеризации, нет ленивого автовайринга, фриз после билда (т.е. отсутсвие вставки новых сервисов в рантайме, возможно это и плюс), нет контекстуального биндинга (как раз из-за отсутсвия ленивого автовайринга) и проч.
Fesor
01.04.2017 09:11Нет двойной диспатчеризации
в 3.3 наконец-то сделали возможность юзать интерфейсы как id-ники сервисов, так же автовайринг теперь работает за счет алиасов. Так что дабл диспатч прикрутить сверху это изи.
нет ленивого автовайринга
Что есть "ленивый" автовайринг? В любом случае что-то похожее есть в 3.3 через setters/getters injection.
фриз после билда
мы уже обсуждали это, для test энвайрмента доступен ContainerBuilder со всеми возможностями для замены сервисов в рантайме.
нет контекстуального биндинга
SerafimArts
01.04.2017 09:22Что есть "ленивый" автовайринг? В любом случае что-то похожее есть в 3.3 через setters/getters injection.
Тот, который не надо объявлять, оно само находит декларации. Ну я просто хз как ещё назвать такую штуку (которой можно что-нибудь когда-нибудь себе отстрелить) =)
мы уже обсуждали это, для test энвайрмента доступен ContainerBuilder со всеми возможностями для замены сервисов в рантайме.
А я ещё раз повторюсь, припекло мне вот Request засунуть в контейнер, чтобы он нормально приходил в методы контроллера из контейнера и в любом сервисе можно было получить. И всё тут. А ещё чтобы по интерфейсу
Authenticatableмне прилетала энтити юзера. А ещё хочется писать что-то такое, чтобы и репозиторий автоматом подсовывался и сервис пагинации для одного экшенеа был только в этом экшене:
public function someAction( RequestInerface $request, UsersRepositoryInterface $repo, PaginatoInterface $paginator ): JsonResponse { return $paginator->from($repo)->paginateRequest($request); }
А вот нельзя в симфони. Всё в сервисы и строй лапшу в контроллерах, а я против лапши. Вот и получаются тучи сервисов для сервисов для фектори, который возвращает фектори. Или методы контроллеров в сотню строк.
скоро будут.
Знаю, уже снизу отписался: https://habrahabr.ru/post/325234/#comment_10148430
Fesor
01.04.2017 09:32Тот, который не надо объявлять, оно само находит декларации.
то если "ленивый" не в плане как оно работает в рантайме а "ленивый" в плане что ничего делать не надо? Ну нет, настолько опасных вещей в симфони не будет. Для ленивых там есть defaults для сервисов с 3.3 версии которые решают эти проблемы.
чтобы он нормально приходил в методы контроллера из контейнера и в любом сервисе можно было получить.
Этим ты сделаешь свои сервисы stateful и отслеживать это будет просто ад.
Requestвообще входящие данные, им не место в контейнере. Ну либо опять же тогда на каждый реквест надо делать свой контейнер который вытягивает вещи из основного зафриженого. Это позволит сделать много прикольных вещей.
Authenticatable мне прилетала энтити юзера.
У меня это не сущность (не люблю юзеров по контроллерам размазывать), а просто какой-то объект. Ну и пишется он у меня в атрибуты запроса. И в целом это очень и очень удобно.
А ещё хочется писать что-то такое, чтобы и репозиторий автоматом подсовывался и сервис пагинации
Я пихаю туда кусочек entity manager который для query builder-ов и query. Ну мол у меня за операции чтения отдельные штуки отвечают, репозитории должны возвращать одну и только одну сущность. И никогда не null и не массив сущностей. Возможно это излишние загоны, но так контроля больше и возможностей.
К примеру я сейчас эксперементирую с кастомными гидраторами для доктрины и с ними можно делать очень много интересного. В частности мне все больше нравится идея не пускать сущности на view и использовать штуки вроде модифицированных array hydrator и т.д. или мэпить на dto сразу из dql.
SerafimArts
01.04.2017 09:45то если "ленивый" не в плане как оно работает в рантайме а "ленивый" в плане что ничего делать не надо? Ну нет, настолько опасных вещей в симфони не будет. Для ленивых там есть defaults для сервисов с 3.3 версии которые решают эти проблемы.
Конечно не будет, по-этому вместо таких штук:
$container->factory(FactoryItem::class, ['a' => 23]); $container->factory(FactoryItem::class, ['b' => 42]);
Приходится писать отдельный фектори, внутри которого придётся руками проставлять все аргументы из контейнера через сервис локацию (потому что симфонийский контейнер, вспоминаем, фризится).
Ну и т.д. Все ниже приведённые тобою отговорки имеют право на жизнь, более того — это вполне грамотные решения проблем. Только этих проблем в Laravel не возникает — отличие в этом.
<irony>
А давай вспомним бандлы? Моя любимая часть симфони. Начнётся всё с построения дерева конфигов. Примерно там же и будет похоронен юный падаван. "Зато никаких ошибок в конфигах" — говорили они =)
</irony>
MetaDone
01.04.2017 09:54Начнётся всё с построения дерева конфигов. Примерно там же и будет похоронен юный падаван. «Зато никаких ошибок в конфигах» — говорили они =)
а мне в ларе этого иногда не хватает, особенно если кто-нибудь альтернативно одаренный без чтения документации будет писать в конфигах какую-то дичь (строки вместо чисел например). Или снесет пакет, а конфиги останутся. Или при клонировании репозитория — в ларе сам читай readme и ищи какие параметры в .env нужно прописать если никто не прописал в .env.example то что нужно. А симфони сгенерит при установке пакетов parametest.yml с дефолтными значениями где останется прописать свои параметры для окруженияSerafimArts
01.04.2017 10:02+1а мне в ларе этого иногда не хватает, особенно если кто-нибудь альтернативно одаренный без чтения документации будет писать в конфигах какую-то дичь (строки вместо чисел например).
Подсказываю решение:
use Illuminate\Config\Respository; class MyConfig extends Repository { public function getSomething(): int { return (int)$this->get('some.value', 10); } }
И прошу заметить — такой вариант, с нормальным и красивым интерфейсом для конфигов на порядок лучше построения конфигов через ноды. Уровень абстракции выше, а гемора меньше.
Или при клонировании репозитория — в ларе сам читай readme и ищи какие параметры в .env нужно прописать если никто не прописал в .env.example то что нужно. А симфони сгенерит при установке пакетов parametest.yml с дефолтными значениями где останется прописать свои параметры для окружения
Полностью согласен. С другой стороны кто-нибудь может удалить бандл, а тот же самый parameters.yml так и останется висеть набитый левыми переменными, потом иди и вычищай. Ну т.е. подобные проблемы "оставаний кишок" есть везде.
P.S. Всё что я нашаманил для упрощения работы с этим для лары — это простенький интрфейсик установки .env
MetaDone
01.04.2017 10:16С другой стороны кто-нибудь может удалить бандл, а тот же самый parameters.yml так и останется висеть набитый левыми переменными
Это к приложению относится, настройки бандлов в config_%env%.yml обитают.
Сносим бандл — все, симфони будет ругаться что лишние конфиги которые не к чему применить остались.
А за parameters.yml.dist следить да, надо самому
Подсказываю решение:
Это конечно круто, но как-то не то. А так в нужных местах можно было бы сделать так:
$rootNode ->children() ->integerNode('positive_value') ->min(10) ->max(1000) ->end()
А в ларе придется самому за этим следить и исключениями бросатьсяSerafimArts
01.04.2017 10:30Так а никто не мешает делать ассерты в репе, в результате получится ровно тоже самое, только вид сбоку:
class MyRepo extends Repository { public function __construct(array $params) { parent::__construct($params); assert($this->get('positive_value') >= 10 && $this->get('positive_value') <= 1000); } }
А если заюзать DbC (php-deal например), то вообще сказка получится (эх мечты).
Из минусов:
- Не так удобно и немного попахивает
Из плюсов:
- На продакшене этих проверок не будет (ассертинг отключается, 0-cost)
- Можно точно так же добавить красивый интерфейс для конфигов со сложной логикой: тыц и тыц — явно видно преимущество необязательности использования симфонёвых нод для конфигов, т.к. задача проще и красивее решается.
Ну т.е. подводя итог — оба решения имеют право на существование, только на практике ноды почти всегда сложнее выходят, нежели простое решение "в лоб", но конечно же не всегда.
Fesor
01.04.2017 10:36ассертинг отключается, 0-cost
ну как бы в symfony же все кэшируется и дампится так что тоже 0-cost.
Можно точно так же добавить красивый интерфейс для конфигов со сложной
А может не надо делать сложных конфигов?)
SerafimArts
01.04.2017 10:44А может не надо делать сложных конфигов?)
А ты посмотри по ссылочкам лучше, а не вбрасывай =)
Fesor
01.04.2017 12:21ну в симфони это был бы 1 compile pass и 1 тэг. и вместо некого
RenderersRepositoryбыл быRendererChain.
noopic
30.03.2017 13:17В работе для последних двух проектов, которые пишутся уже больше года, взял Yii2. Для pet проекта написал свой микро фереймворк на PHP7.
Свой фреймворк разделил на две части, API и web. API принимает параметры через GET или POST, валидирует их и возвращает JSON с успешным результатом или ошибкой. Web выводит HTML. Реализовал всё самое необходимое: простейший роутинг, локализацию, мирграции, подключение ассетов, вывод шаблонов, валидацию параметров. Больше пока не понадобилось. Задокументировал, покрыл тестами на 70%. Пустую страницу выводит быстрее, чем Yii2, в 5 раз. Yii2 — 2.5ms, my — 0.5ms.
Возникают мысли выложить исходники в открытый доступ, но пока не вижу в этом целесообразности, так как писался он под определённую задачу, и многие популярные вещи, такие, как ORM, подключение шаблонизатора, вроде Twig, кастомные логи и прочее, в нём отсутствуют.TPbIHTPABA
30.03.2017 17:21+1Странно вы сравниваете. Говорите, что написали свой микрофреймворк и сравниваете его с yii2 в котором на данный момент нет микроядра.
ertaquo
30.03.2017 13:50-1У меня есть нечто самописное, состоящее из роутера и своей реализации ActiveRecord (которая по функционалу пока не доходит до реализации из Yii2, но уже превосходит ту, что в первом Yii; по удобству использования имхо превосходит обе).
Не сказать, что работает быстрее прочих, но зато писать код с его помощью довольно просто.
Armleo
30.03.2017 15:18+2Кажется я один на wordpress сижу :(.
Хочеться взять фреймворк и сделать, что-то большое, да работы тут нету.helg1978
30.03.2017 15:48Это CMS все же.
Я на прошлой неделе в Joomla добавлял AdminLTE в качестве фронтэнд странички, тоже думал что пора б заканчивать скрещивать ужа с ежом.
vlreshet
30.03.2017 16:47Пфф, вордпресс. Я уже 2 месяца сижу на связке SuiteCRM + Wordpress (связаны через модуль вордпресса). Вот уж где реальная боль и изврат. Иногда я открываю старый проект на ларавеле, и просто почитываю код, чтобы хоть как-то потушить подгорания в нижней части туловища после работы над кодом crm или wp.
khrnsb4y
31.03.2017 06:37Можно сделать плагин, содержащий всю логику проекта, и использовать там Composer и компоненты Symfony, написать адаптеры для API Wordpress и даже что-то попробовать в дальнейшем перенести, если понадобится, на любую платформу, реализуя аналогичный подход. Минус в том, что обычные WP-разработчики попросят у клиента много денег за доработку, т.к. им будет сложно разобраться в проекте. Некоторые вещи можно и в обход движка делать для ускорения, например, AJAX запросы, загрузка ядра занимает очень много времени. Попробуйте личный кабинет пользователя так написать или систему коллективного блоггинга. Мне такие задачи на WP попадались, но тогда я сочетанием корявых плагинов обходится, не осилил сам сделать.
http3
31.03.2017 11:26Можно сделать плагин, содержащий всю логику проекта, и использовать там Composer и компоненты Symfony, написать адаптеры для API Wordpress
Кто кого будет дергать?
Wordpress Symfony
Или
Symfony Wordpress?
MisterGoodman
30.03.2017 16:02-1Уже много лет работаю с Kohana.
TPbIHTPABA
30.03.2017 17:21На поддержке старых проектов или новые запускаете на Kohana? Если не ошибаюсь фреймворк мертвый уже года 3-4 как.
MisterGoodman
31.03.2017 07:33На кохане сделал что-то вроде простого CMS. Так что изредка пеку и новые проекты.
mrOrlando
30.03.2017 17:03-1В долгоиграющем проекте (архив документации, электронный документооборот) используем mediawiki, поддержка модульности, версионирования, интернационализации. Известно о нём только благодаря википедии.
de1vin
30.03.2017 17:48С самого появления Yii работал с ним. Сталкивался в свое время с CI и Kohana.
С этого года стал перебираться на Symfony в виду того, что поменялся взгляд на разработку.
Большой плюс и одновременно минус Yii, чисто субъективно, возможность быстро стартануть и низкий порог вхождения. Но при этом вся ответственность за архитектуру приложения лежит на разработчике. Если, что бы наговнокодить в Symfony нужно приложить специально определенные усилия, то в Yii это может получится само собой, в попытке сэкономить время. Ни что не мешает вызвать вьюху в модели, сохранять модель во вьюхе, а бизнеслогику перенести в контроллер.
Лет пять назад, джаст фо фан, с другом запустили небольшой сайт для автоматизации размещения его панорам. Шло время, прикрутил rbac и регистрацию юзеров, что бы и друге могли размещать свои панорамы, потом понадобился форум, потом api понадобилось. И в итоге, все это разрослось в такого мутанта, что когда мне нужно что-то новое добавить в код, я начинаю плакать кровавыми слезами :)
Так что, имхо, важнее не фреймворк, а то, как им пользоваться. Просто с некоторыми фреймворками накосячить сложнее, чем с другими.
Aircodes_Raccoon
30.03.2017 18:12я использую компоненты фреймворков и отдельные либы/пакеты
- cboden/ratchet
- react/react
- guzzle/guzzle
- symfony/http-foundation
- klein/klein
- twig/twig
- colshrapnel/safemysql
- monolog/monolog
- raulfraile/ladybug
- curl/curl
- phpseclib/phpseclib
WitER
30.03.2017 18:12+2+FlightPHP.
Второе голосование, на мой взгляд, не совсем верно — нельзя точно говорить о выборе фреймворка не имея информации о проекте.
bossound
30.03.2017 18:12Длительное время вообще не использовал фреймворки но два года назад познакомился и подсел на Phalcon и очень им доволен, сейчас постепенно перевожу рабочие проекты на Phalcon, с учетом того что специально для нас была добавлена в Phalcon поддержка twemproxy.
seregagl
30.03.2017 18:44Пишем все проекты на yii. Присматриваемся в сторону yii2. Перешли бы хоть завтра, но переписать за один день весь наработанный багаж не получится.
denisyukphp
30.03.2017 20:22+1Сейчас сижу на Yii2, но больше по душе компонентный подход: Slim + пакеты сторонних разработчиков. В зависимости от задачи нужно постепенно наращивать функционал, усложнять бизнес-логику приложения. Здесь многого не надо: пакеты, которые крутятся вокруг HTTP-спецификации; работа с БД (Medoo, Eloquent ORM, Doctrine2); шаблонизатор (как по мне лучший Twig, нативный принципиально не рассматриваю). Но и вся архитектура на вас. Чаще в такие проекты порог входа выше, нежели в любой «тяжёлый» фреймворк.
redfs
30.03.2017 22:36+3Slim + пакеты сторонних разработчиков
+1. Slim, как каркас — великолепен. Ничего лишнего и шикарная архитектура, позволяющая легко и даже элегантно наращивать «мясо».
ghost404
30.03.2017 21:11+2Работал с Zend 1, Symfony 2, Yii 1 и самописными фраймворками.
Как-то пришлось начать проект на Yii 1 после Symfony 2.
Год разработки я плакал горькими слезами (буквально).
Даже если очень захотеть, не говнокодить на Yii почти невозможно.
Смотрел Laravel. Тот же Yii вид сбоку.
Уже несколько лет я на Symfony и счастлив как ребенок.
DDD + CQRS + Specifications + ValueObject + Doctrine
Даже маленькие проекты на Symfony летают.
Rathil
30.03.2017 23:48+1Ну у меня и на Yii2 проекты летают. Тут как пишешь и что используешь, мне кажется…
SerafimArts
01.04.2017 00:02+2Позвольте, не стоит сравнивать Yii и Laravel — это совершенно разные подходы для одно "целевой аудитории".
DDD и прочее в Symfony вытекает из использования доктрины. Посмотрим как вы с Propel'ом так же развернётесь =) Берёте лару + доктрину и отличий не найдёте, ну кроме того, что не будет в проекте этой треклятой сервис-локации, а всё будет по-нормальному с чистым DI.
porn
01.04.2017 00:30Просто интерсено: почему по вашему мнению, DDD вытекает из использования доктрины?
Доктрина, например, не умеет в ValueObject as identity. А собственно саму поддержку ValueObject запилили только спустя 5 лет после реквеста.
DDD с симфони применим, потому что фреймворк очень гибкий, а не потому что какая-то либа задаёт правила.SerafimArts
01.04.2017 01:12+2Не только доктрины. AR крайне сложно представить в виде чистых доменных сущностей из-за своей специфики прямой связанности с БД (т.е. тупого DAO). А доктрина — Data Mapper с чистыми энтитями никак не связанными со структурой БД, которая, как известно, хранит зачастую много технической информации не связанной с предметной областью. По-этому нормальную предметную область можно организовать лишь при использовании не-DAO ORM, как доктрина, к примеру. От фреймворка это уже мало зависит.
ghost404
02.04.2017 09:55Я сравнивал Yii 1 и Laravel 1, когда он только вышел.
Что мне сходу не понравилось в Laravel:
- дурацкая файловая структура. Мне на тот момент она показалась не логичной.
- работа с базой через такой же ActiveRecord что и в Yii. Принципиальных преимуществ я не увидел, особенно если сравнивать с Doctrine.
- мне не понравился шаблонизатор. Не да Twig, пере php как в Yii, но это субъективное. Twig мне нравится больше.
Сейчас бегло пробежался по документации и увидел ещё проблемы:
- роутинг через php. Тоже что и в Yii. В Symfony роутинг конечно тоже транслируется в php, но описываем мы его либо в yaml конфигах, либо в аннотациях.
- аннотации считаю очень удобным инструментом, хоть и не всегда они к месту. В Laravel аннотаций я не увидел, возможно нужно было капнуть глубже.
- переводы в Laravel описываются в php файлах как и в Yii. Удобно использовать формат xliff, для которого есть редакторы и можно отдавать переводы на сторону — переводчикам, не разработчикам. Также удобным является формат yaml, позволяющий построить иерархию сообщений.
- для Doctrine есть бандл который позволяет переводить сообщения из БД
- реализация IoC в Laravel мне показалась странной. В Yii не лучше.
Не берусь утверждаеть, что Laravel плохо фраймворк. Беглый обзор документации и некоторых статей не дает возможности в полной мере понять и оценить все тонкости и преимущества этого фраймворка, но первое и второе впечатление скорее негативное.
Laravel и так написан на компонентах Symfony, если в него перенести Doctrine, Twig и еще кое какие компоненты из Symfony, то от самого Laravel почти ничего не останется и логичнее сразу писать на Symfony.
В результате, я не увидел никаких преимуществ Laravel и Yii перед Symfony. Если я что-то упустил, просветите меня пожалуйста.
SerafimArts
02.04.2017 10:08Laravel 1 вроде как никогда не выходил, а на гитхаб вылился начиная с версии 3+ (сейчас 5.4, летом 5.5 LTS), откуда такой раритет? Поделитесь?
ghost404
02.04.2017 10:16Таких подробностей я не помню. Смотрел на него несколько лет назад когда он только появился на хабре.
SerafimArts
02.04.2017 11:14На хабре он начал появляться начиная с версии 4.х, довольно паршивенькой, к слову, но довольно удобной для простых вещей. Начиная с версии 5.1+ уровень решения вполне конкурентен с симфони.
Но это оффтоп, если по теме:
В результате, я не увидел никаких преимуществ Laravel и Yii перед Symfony. Если я что-то упустил, просветите меня пожалуйста.
Начнём с того, что сравнивать Laravel, Symfony и Yii некорректно, начнём с ЦА:
- Yii — это Low и Middle решения
- Symfony — Middle и High
- Laravel 4.x — Low и Middle
- Laravel 5.x — Low, Middle и High
Я думаю рассказывать почему так не имеет смысла, а полное обсуждение вопроса потребует не один комментарий, но чуть объясню общими словами:
Эффективнее всего стартануть типовой проект получится однозначно на Yii, с Laravel и тем более Symfony это будет сложнее, просто потому, что у в ларе круд генераторы надо доставлять, а в симфони из близких аналогов только соната, и то, там только админка без генерации. С другой стороны архитектура Yii довольно кособокая с крайне высокой связанностью, из-за чего просто не развернуться в нетривиальных условиях.
Если рассматривать Laravel — его преимущество перед симфони в том, что он изначально строится на императивном подходе и каждый из подходов упрощён, но при этом в результирующем варианте (при аггрегации всех возможностей) у Laravel на порядок больше этих самых возможностей именно из-за упрощения подходов и увеличения их количества.
Если ещё более кратко — Symony и Laravel для крупных проектов вполне сопоставимы, только в симфони изначально планка так стоит, а в Laravel надо знать все особенности фрейма.
P.S. Все указанные особенности симфони реализуются на Laravel в пару тычков, т.к. декларативные возможности роутинга, конфигов и прочего симфони — это всего лишь надстройка над императивщиной.
SerafimArts
02.04.2017 11:31+1Теперь отдельно по пунктам:
роутинг через php. Тоже что и в Yii. В Symfony роутинг конечно тоже транслируется в php, но описываем мы его либо в yaml конфигах, либо в аннотациях.
Этот роутинг аналогичен именно симфонёвому, в Yii он иной, но при этом он гибче симфонёвого, но и многословнее.
аннотации считаю очень удобным инструментом, хоть и не всегда они к месту. В Laravel аннотаций я не увидел, возможно нужно было капнуть глубже.
Аннотации — это всего лишь пакет из Doctrine или Falcon (на ваш вкус), если хотите использовать роутинг и прочее — никто вас не ограничивает в этом, можно даже не писать, а использовать готовые вещи: https://laravelcollective.com/docs/5.0/annotations Это всё же фрейм и никто ни в чём вас не ограничивает, просто они не нужны из коробки
переводы в Laravel описываются в php файлах как и в Yii. Удобно использовать формат xliff, для которого есть редакторы и можно отдавать переводы на сторону — переводчикам, не разработчикам. Также удобным является формат yaml, позволяющий построить иерархию сообщений.
Никто в этом не ограничивает, добавляете новый адаптер (лоадер) и всё начинает работать с чем вам угодно, думаю достаточно очевидно как его реализовывать? https://github.com/illuminate/translation/blob/master/LoaderInterface.php
для Doctrine есть бандл который позволяет переводить сообщения из БД
А в Laravel есть лоадеры, которые могут дёргать всё из БД, а есть и доктрина: http://www.laraveldoctrine.org/
реализация IoC в Laravel мне показалась странной. В Yii не лучше.
Почему же более мощный DI — это плохой вариант IoC?
Что есть в Laravel:
- Получить сервис по интерфейсу, а не сервис-локации
($container->get(SomeInterface::class);) - Возможность создавать объекты с инжектом из контейнера (т.е. обычный new, но с сервисами из контейнера без декларации конфигов)
- Возможность управлять внедрением (говорить, что если контроллер или потомки запросит A — вернуть ему AA, а если этот сервис, то AB)
- Возможность подписываться на любые события контейнера (например вызывать сеттер после резолва сервиса из контейнера)
Это только то, что есть в ларе сверх возможностей симфонёвого контейнера. Ну помимо сервис-локации, которая умеет обрачиваться в статический интерфейс (треклятые фасады).
ghost404
02.04.2017 15:04-1Этот роутинг аналогичен именно симфонёвому, в Yii он иной, но при этом он гибче симфонёвого, но и многословнее.
А чем он гибче и многословней? Прочитал документацию. Абсолютно всё тоже самое, что и в Symfony. Только группировку в Symfony реализуется подругому, чуть более логчно, и ParamConvertor в Symfony удобнее. Поделитесь пожалуйста, чем роутинг в Laravel лучше чем в Symfony?
А в Laravel есть лоадеры
Под переводами в Doctrine я имел в виду не хранение переводов в бд, а автоподстановку переводов полей сущности:
https://github.com/Atlantic18/DoctrineExtensions/blob/master/doc/translatable.md
можно даже не писать, а использовать готовые вещи
добавляете новый адаптер (лоадер)О чем я и говорю. Добавьте в Laravel фарша из Symfony и получите Symfony.
Почему же более мощный DI — это плохой вариант IoC?
Описанные вами примеры это хороший способ усложнить сопровождение проекта или выстрелить себе в ногу.
Получить сервис по интерфейсу
Это просто эпический ад. Интерфейсы описываю контракт, который реализует один или более классов (как правило более одного). И как же Service Locator будет резолвить разные сервисы с одним интерфейсом? Да никак. Бам. О, моя нога)))
SerafimArts
02.04.2017 15:25А чем он гибче и многословней?
Гибче?
- Префиксы в том же месте, где и роуты (не вынося в отдельный yaml)
- А ещё есть суффиксы (правда через ядро)
- Одной строкой задекларировать полный CRUD
- Связать с рантаймом (например выгрузить из БД, бред конечно, но мало ли)
- Учитывая пункт выше — можно перейти на ADR-like, а не использовать всю цепочку MVP (MVC)
- Объявлять паттерны для плейсхолдеров для всей группы (или вообще глобально)
- А можно связать плейсхолдер с любой сущностью (например выбрать из БД энтити, как в симфони в контроллерах)
- А ещё раньше можно было одной строкой замаппить все роуты на паблик методы контроллера (задепрекейтили в 5.1, вроде, и вырезали в 5.3)
- И куча чего ещё. И самое главное у роутов есть приоритет. Аннотациями приоритет не сделать, приходится гибрид фигачить.
Многословнее? А когда императивный php был более лакончиным, нежели декларативный yaml?
О чем я и говорю. Добавьте в Laravel фарша из Symfony и получите Symfony.
Скорее наоборот. В Laravel из коробки на несколько порядков больше возможностей. В симфони же почти всё ставится руками, всегда, начиная с flysystem, заканчивая всякими monolog, swiftmailer и проч.
Это просто эпический ад. Интерфейсы описываю контракт, который реализует один или более классов (как правило более одного). И как же Service Locator будет резолвить разные сервисы с одним интерфейсом? Да никак. Бам. О, моя нога)))
Почитайте про контекстуальный биндинг. В новом симфони (который осенью) наконец это добавят: https://github.com/symfony/symfony/pull/22187
pbatanov
03.04.2017 09:41Скорее наоборот. В Laravel из коробки на несколько порядков больше возможностей. В симфони же почти всё ставится руками, всегда, начиная с flysystem, заканчивая всякими monolog, swiftmailer и проч.
А вы точно пробовали пакет symfony/symfony и symfony/framework-standard-edition? Это как раз для тех, кто хочет готовый комбайн под новый проект, если что. Потом можно ненужные вещи (твиг, например, в АПИ не пригодился) — выпилить
https://packagist.org/packages/symfony/symfony
https://packagist.org/packages/symfony/framework-standard-editionSerafimArts
03.04.2017 10:08Я про абстрактные билды в целом, потому что даже если брать какой-нибудь REST Edition — всё равно доставляется много чего. Ну если брать то, что есть в ларе в коробочном виде:
1) Очереди (redis, db, beanstalkd, rabbit, zero, etc)
2) Sheduler
3) SSH задачи (например можно задеплоиться из локалки одной консольной командой, хотя всякие Deployer и проч конечно лучше)
4) Абстракции над файловой системой (Flysystem)
5) Авторизация (в симфони 3.0+ похожее появилось, так что можно пропустить)
6) Броадкастинг
7) Почтовые драйверы и нотификации (можно сообщеньки прямо в какой-нибудь Telegram слать)
8) Пагинация
9) Сидеры (я пользовался alice фикстурами в симфони, но вроде у доктрины есть из коробки, не помню)
Ну и ещё огромное количество мелочей. Почти во всех проектах симфони это приходится руками доставлять.
ghost404
03.04.2017 11:42То есть, большое количество предустановленных компонентов в фраймворке которые будут не нужны большинству вы считаете плюсом?
Вы мне напомнили сейчас M-A-XG (нынче он http3) который хает фраймворки потому что в них нет хлебных крошек.
Фраймворк это каркас и конструктор, на который навешивается всю что необходимо в конкретном проекте и необходимость доставлять компоненты, это не то что нормально, это правильно.
SerafimArts
03.04.2017 12:17Прошу заметить — это всё необходимые компоненты в 99% сайтах, которые чуть сложнее бложика.
pbatanov
03.04.2017 15:55Большинство этих вещей устанавливаются
в два кликапару команд — composer require и подключение в ядро. Ну и список такой себе сомнительный.
1 — спорно, это все таки решение конкретных задач по управлению потоком
2,3 — это не задача проекта, а задача CI\CD, системы сборки (capistrano, deployer, выбирайте по вкусу). В «большинстве проектов сложней бложика», если говорить вашими терминами, эти вещи уже управляются снаружи.
4 — Filesystem есть изкоробки, я не зря привел вам пример пакета, в котором есть ВСЕ пакеты симфони
5 — Есть нормальное с версии 2.8, до 2.8 тоже можно было использвать, но чуть сложней (больше кода писать). Сейчас (с 2.8) достаточно заимплементить один интерфейс.
6 — не очень понял, что это именно
7 — есть, свифтмейлер из коробки. Телеграм из коробки — а почему не ватсап? скайп? Почему фреймворк за вас выбирает канал? Опять же — куча готовых модулей. Выбираете свой и подключаете.
8 — готовый бандл
9 — готовый бандл, но иногда действительно рекомендуют alice
Если доставлять приходится во всех, то вы давно могли сделать свой метапакет, типа того же symfony/framework-standard-edition и переиспользовать его. Есть, кстати и rest-edition. А так вы видимо просто делаете что-то однотипное.
У нас сейчас используетсямикросервисная архитектура и проекты на симфони и все разные. На половине из них все то, что вы написали не нужно.SerafimArts
03.04.2017 17:01- А как вы почту отправляете, например после регистрации? В том же треде? Это плохо.
- Это нужно для любых задач, например синхронизация данных с внешним апи раз в N часов. В кроне всегда будет одна строчка, вместо 100500. Это никак не относится к деплою.
- Я уже затерялся в комментах, повторите? Я не вижу: https://github.com/symfony/symfony-standard/blob/master/composer.json#L15-L25
- Неа, в 2.8 есть только аутентификация, надо ставить FOS поверх
- Это фигня, забей =) Тупо возможность пушить сообщения поверх, например вебсокетов.
- свифтмейлер только в стандард, в самом фрейме нету: https://github.com/symfony/symfony/blob/master/composer.json#L19-L30 По поводу остального и ватсап тоже: https://packagist.org/search/?q=laravel%20notification
- в доктрине, ага
- алис не такой гибкий, как доктриновский
Если доставлять приходится во всех, то вы давно могли сделать свой метапакет,
Нет конечно же, не во всех.
ghost404
03.04.2017 17:47+12) Sheduler
Это нужно для любых задач, например синхронизация данных с внешним апи раз в N часов. В кроне всегда будет одна строчка, вместо 100500. Это никак не относится к деплою.Планировщик это по сути тот же крон, но внутри приложения. В документации к Laravel рекомендуют запускать планировщик раз в минуту. Вы не замечаете тут проблемы?
Проблема в том что приложение будет дергаться каждую минуту, хотя задачу возможно нужно выполнять раз в месяц или каждую третью неделю. И сколько в этом случае обращений к приложению будет идти в холостую?
Еще cron запускает процессы параллельно и fatal error в одной задаче никак не повлияет на другие. Возможно конечно Sheduler в Laravel как-то это учитывает, но не на столько качественно как cron.
Если бы Sheduler был полноценной заменой крона, то это былоб хорошим решением для хостингов на которых нет cron, но это никак не core функция.
Fesor
03.04.2017 18:13Неа, в 2.8 есть только аутентификация, надо ставить FOS поверх
вообще-то нет. Обычного form login хватает. Он есть из коробки уже хз сколько.
Fesor
03.04.2017 18:59свифтмейлер только в стандард, в самом фрейме нету:
эм… стандарт эдишен это и есть фреймворк. Для работы отдельных симфони компонентов оно не надо. А swiftmailer bundle в отдельном репозитории живет. Как никак это интеграция со сторонним сервисом. Точно так же как и Doctrine bundle.
SerafimArts
03.04.2017 19:28эм… стандарт эдишен это и есть фреймворк.
Всегда считал, что это сборка (одна из). А сам фрейм — тут: https://github.com/symfony/symfony
pbatanov
03.04.2017 21:20технически standard edition — это готовое boilerplate приложение на основе symfony fullstack (symfony\symfony) и доп. либ. официальное, православное. а сам фрейм отдельно, как вы указали
Fesor
03.04.2017 21:43Нет, там — только компоненты и куски из которых строятся фреймворки. Более того, вся философия симфони — вот вам сэт компонентов и делайте свои фреймворки. standard-edition это так сказать путь для ленивых. silex — пример что можно сделать свой фреймворк. Ну и т.д.
pbatanov
03.04.2017 21:18+1- Нет, сфитмейлер умеет спулить емейлы. Либо откладывать до terminate ядра (т.е. шлет после отправки ответа пользователю, завершая коннект), либо можно спул обрабатывать внешним потоком (кроном, например). По умолчанию спул в памяти, отправка по терминейт
- Деплой должен настраивать такие штуки. Потому что это вещи, зависящие от окружения. В ином окружении (дев, тест) у нас такие вещи отключены или поставлены на более щадящие таймеры. В препрод, прод — работают. В проекте есть отдельный конфиг для whenever (так сложилось), который при деплое развертывается в готовый крон файл, этим же CI\CD отключается при откате релиза и прочее. А как вы отключаете ваши кроны при откате релиза?
- Filesystem — это часть пакета symfony/symfony (есть по вашей ссылки). symfony/symfony заменает filesystem. Можно установить отдельным пакетом
- FoS UB, если вы про него — это готовые пользователи, которые надо отметить, опять же не всем подходят. У нас на всех проектах авторизация внешняя, юзеры вообще в битриксе живут (так сложилось). Авторизация работает, в том числе встроенная симфонёвая. Есть проект с FoS UB (точней там Sonata Admin, которая тянет FoS UB
- Ок, не сталкивался, видимо
- Да, потому что технически это такая же внешняя библиотека, как доктрина. Поэтому она идет изкоробки в standard (как доктрина), но это не часть проекта symfony. Сути ссылки я не понял. Вижу что можно все подключить модулями.
- Не только в доктрине, есть knp pagination bundle, довольно удобная штука, умеет пагинировать не только доктрину, а много разных источников
- Возможно, сам пользуюсь доктриновским
SerafimArts
04.04.2017 01:31- Кажется вы не посмотрели что я имел ввиду под шедулером. В случае ларки — крон команда только одна на всё приложение и на RC\Stage и на проде. А шедулер уже сам разруливает что и как включать, раз в 10 минут или раз в год, включая окружение, исключение перекрытий (т.е. исключение дублирования запуска) и прочее-прочее.
- Я говорил про Flysystem, а не Filesystem. Например подключение Amazon S3 или какого-нибудь WebDav, который на том конце является каким-нибудь статик-сервером для аплоадов. Это тот самый момент, когда подобное решение "из коробки" позволит в будущем переключить драйвер одним кликом.
Fesor
04.04.2017 01:43А шедулер уже сам разруливает что и как включать
Что будет если я допустим в scheduler записал выполнять скрипт раз в 3 минуты и внезапно скрипт начал выполняться 10 минут? Или в документации упущен момент с костылями аля flock?
Я говорил про Flysystem
который интегрируется в симфони с пол пинка а по дефолту если он часто надо — ну я например просто включил его в свой скелет проекта. Точно так же как кучу других вещей которые мне надо где-то в 2/3 проектов.
А вообще ждем symfony/flex.
SerafimArts
04.04.2017 07:49Что будет если я допустим в scheduler записал выполнять скрипт раз в 3 минуты и внезапно скрипт начал выполняться 10 минут? Или в документации упущен момент с костылями аля flock?
Я могу дальше кидаться ссылками на документацию, но оно надо?
pbatanov
04.04.2017 08:22- Про крон команду с вами уже обсуждают в другом треде, не буду повторяться. Не считаю удобным дергать все ядро раз в минуту вне зависимости от того, должно что-то отрабатывать или нет. Есть консольные команды, которые можно запускать хоть руками, хоть кроном
- Сорян, замыленый глаз прочитал не так :) Есть подозрение, что готовых интеграций тоже хватает https://packagist.org/packages/oneup/flysystem-bundle. Про решение «изкоробки» уже обсуждали — зачем оно всем подряд? Например при работе с сервисной архитектурой все проекты подряд скорей всего не будут грузить файлы, а будет один сервис для этого
SerafimArts
04.04.2017 08:55Я думаю, что не стоит утверждать, что два разных класса ФС в проекте — это плохо, и всегда лучше одно что-то. Всё это очевидно и симфони — хороший фрейм, я его люблю.
И подытожить хочется мыслью о том, что фреймы создавались для того, чтобы облегчить жизнь. И лара — как раз то решение, когда всё всегда есть под рукой и всё удобно. Т.к. в симфони довольно часто, после ларки, не покидает ощущение что изобретаешь велосипеды. Балует фрейм.
http3
03.04.2017 13:56Я хаю потому, что нету интерфейса для добавления ХК.
Я даже не говорю, что он должен быть одинаков для всех фреймворков.
Сам шаблон ХК — дело десятое.
Вот в вопросе логирования пришли же к PSR-3.
Хотя, я как бы и соглашусь, что данное требование более из свойств CMS.
Ну и я, если честно, не люблю, когда фреймворк что-то навязывает, например использовать обертки для json_encode() или для вывода элементов форм.
Должен быть выбор, использовать предполагаемый фреймворком функционал или реализовывать свой.
При этом следует различать разовую разработку и серийную разработку.
В разовой разработке без использования «сторонних решений, которые добавляют ХК» требование наличия интерфейса ХК в ядре не нужно.
В серийной разработке, когда часто используются «сторонние решения, которые добавляют ХК», наличие интерфейса ХК в ядре необходимо.
Поэтому можно сделать такой вывод:
Фреймворк все же больше подходит для разовой разработки. Или серийной закрытой
CMS — для серийной открытой
Самопись может использоваться как для разовой разработки, так и для серийной закрытой
Хотя это все — вопрос личных предпочтений. :)
ghost404
03.04.2017 11:49Префиксы в том же месте, где и роуты (не вынося в отдельный yaml)
Префиксы нужны для группировки роутов модулей. Роуты модуля, как правило, лежат в модуле и, соответственно в глобальном роуте мы подключаем их с нужным нам префиксом, как это обычно и бывает.
Одной строкой задекларировать полный CRUDС
Аналогично в Symfony. Но нормальные проекты не ограничиваются только CRUD-ом. А когда мы говорим о DDD, то CRUD, вообще перестает быть актуальным
вязать с рантаймом (например выгрузить из БД, бред конечно, но мало ли)
Это удар по производительности и нужно разьве что для CMS. В Symfony это тоже можно сделать, но зачем?
Объявлять паттерны для плейсхолдеров для всей группы (или вообще глобально)
Пожалуй согласен. В Symfony этого нет. Объявить регекспы один раз, а не в каждом роуте может быть удобно, хотя реализация в Laravel мне не нравится. Ну и можно вообще отказатся от регекспов, так как всё равно маппинг делается на сущность.
А можно связать плейсхолдер с любой сущностью (например выбрать из БД энтити, как в симфони в контроллерах)
Это ParamConvertor, о котором я уже говорил ранее. Он удобнее чем в Laravel
А ещё раньше можно было одной строкой замаппить все роуты на паблик методы контроллера (задепрекейтили в 5.1, вроде, и вырезали в 5.3)
И правильно сделали
И самое главное у роутов есть приоритет. Аннотациями приоритет не сделать, приходится гибрид фигачить.
- Приоритет определяется порядком определегия.
- А зачем вообще приоритет роутингов? Если роутинги могут конфдиктовать, то у вас серьезные проблему в проекте
SerafimArts
03.04.2017 12:26А зачем вообще приоритет роутингов? Если роутинги могут конфдиктовать, то у вас серьезные проблему в проекте
Ну например на любой роут с методом OPTIONS стоит возвращать 200ый ответ, а на любой роут после всех — 404 с красивой картиночкой.
Это ParamConvertor, о котором я уже говорил ранее. Он удобнее чем в Laravel
Это не коробочный симфони, если не путаю, это SensioBundle или что-то такое.
По остальным пунктам — согласен. Всё это можно, но зачастую надо влезать во внутренности, что печалит.
ghost404
03.04.2017 13:14Ну например на любой роут с методом OPTIONS стоит возвращать 200ый ответ, а на любой роут после всех — 404 с красивой картиночкой.
Это есть из коробки. Если роут не найден — 404. Страницу 404 можно кастомизировать. Все ответы по умолчанию отдают 200
Это не коробочный симфони, если не путаю, это SensioBundle или что-то такое.
Sensio входит в стандартную поставку Symfony. Ссылку вам давали выше.
SerafimArts
03.04.2017 13:41Это есть из коробки. Если роут не найден — 404. Страницу 404 можно кастомизировать. Все ответы по умолчанию отдают 200
С 404 — это нормальный путь. Я просто привёл пример, когда приоритет важен. Могу ещё что-нибудь придумать, но надо ли? Идею я донёс.
Sensio входит в стандартную поставку Symfony. Ссылку вам давали выше.
А, ну да, я слепой, бывает =)
- Получить сервис по интерфейсу, а не сервис-локации
ablai
31.03.2017 06:36+2Очень хотелось бы поменьше этих самописных фремворков, на основе которых обычно гавнокод.
Редко (скорее невозможно, не встречал, покажите) когда какая то команда способна написать нечто в общем «умнее» чем разрабы крупных фреймворков с огромным комунити.
Когда я получаю проект, я не жду от него вашего фундаментального кода. Он не интересен, уже достаточно увидел.
Я надеюсь получить нечто что написано пускай даже CI 2 версий. В нем будет большее мне знакомо, чем всякое написанное на отдельных компонентах Symfony какой то Петей из Комчатки.
Любите компоненты Symfony, пишите пожалуйста на нем или возьмите тот же Laravel.
Любите блестать умом показывая свое уникальное (никому не нужное) решение в виде своего фреймворка, идите в github.
Осуждать Yii, за то что на нем можно гавнокодить было бы ошибкой, т.к. это возможно в разной степени в любом фреймворке. Не думаю что это некий показатель.
Это хорошо, когда с разных частей приложения ты можешь достучаться до всего остального, некая фишка, лучше чем если бы этого не было, иначе осуждали бы а отсутствие этой фишки, почему бы и нет.
Сам пишу в основном на Yii2 чему очень рад и редко на Laravel.
Забавно, как бы популярны не были эти двое, я очень радуюсь когда получаю проект основанный именно на них.
По меньше «своего» фундаментального ребята, займитесь лучше бизнес логикой.http3
31.03.2017 09:55-1Вы, видимо, встречаете говнокод на самописи потому, что это в основном устаревший код :)
Sonichka
31.03.2017 06:36Используем в компании самописный фреймворк на многих проектах. Даже наверное это микро-фреймворк.
varanio
31.03.2017 13:13Интересно, что есть люди, которые минусовали опрос. Что тут могло не понравится? Сам факт опроса по php-фреймворкам?
AlexLeonov
31.03.2017 16:03+5Многим не нравится сам PHP.
Что характерно, в топики, скажем, по brainfuck* не набигают хейтеры brainfuck* и не требуют от всех считать этот язык воплощением зла и «фракталом плохого дизайна».
При этом я уже третий цикл подряд (средний цикл в IT — пять лет) наблюдаю, как очередной царь горы* пыхтит, тужится, разводит хайп и медленно умирает где-то в районе первого базового лагеря. Пока PHP сидит наверху и кидает камешки в пропасть.
* тут подставьте любой не-PHP язык, претендующий быть «убийцей»
uaSaint
01.04.2017 06:43Laravel — нравится архитектура, программирование через интерфейсы, IoC — близко, отличное сообщество, Eloquent \ artisan -вещи… после него даже Symfony показался корявым, была бы моя воля использовал бы везде, где нужен фреймворк.
В ближайшее время на работе скорее всего придется использовать допиленную версию Silex и думаю на долго.
Учитывая популярность Yii2 "у нас" очень сильно старался испытать, не зашло, раздражает подход, архитектура, практически все если честно. Возможно не с того начал и не разобрался, но как есть, в дальнейшем всячески планирую его избегать.
SerafimArts
01.04.2017 09:13+1Положа руку на сердце, всё же AR у Yii 2 (главное сырцы не смотреть) местами лучше, нежели Eloquent. Да и сравнивать Symfony с Laravel стоит без учёта ORM. Всё же Doctrine местами даст фору Eloquent.
В остальном, да, как симфонист — соглашусь. Начиная с симфони 3.0+ очень много плюшек в симфони стянуты с лары, плюс в новой LTS версии (которая осенью выходит) обещают апнуть контейнер до возможностей Laravel. Так что вполне возможно сравняются.
Djeux
01.04.2017 09:54+1Положа руку на сердце, eloquent приносит больше проблем чем пользы. Взять ту же невозможность использования композитных ключей и диктатуру тайлера.
По работе приходиться работать с laravel-ом, в личном проекте использую yii2. Плюс laravel, в том что построен на symfony. Но так же громадный минус в корявой работе с IDE из-за магии с факадами.
Lachezis
01.04.2017 17:16Но так же громадный минус в корявой работе с IDE из-за магии с факадами.
Вот это меня тоже очень сильно расстроило, особенно когда у тебя половина классов строится через class_alias.
Из неприятных первых ощущений стандартная страница ошибки которую нужно сразу выкидывать из заменять на Whoops.
P.S. Используем и поддерживаем несколько Laravel приложений.
SerafimArts
01.04.2017 23:44Решение этой проблемы простое — не используйте фасады и всё.
*Ответ и вам и автору чуть выше
Djeux
02.04.2017 11:23В результате всплывает таже проблема что и в Yii. Когда сервис может использоваться в любой точке апликашки, а без толковой индексации для поиска всех use cases приходиться делать текстовой поиск по всей кодовой базе.
К конце концов позволяет наговнокодить нехуже чем другие «entry level» фреймворки.SerafimArts
02.04.2017 11:39Это как? Вот вы пишите:
class Some { public function __construct(MyService $s) { ... } }
Почему этот сервис
MyServiceтак сложно найти?Djeux
02.04.2017 12:52Речь о ситуации когда факады применяются аля
Facade::doSomething(), в любом месте в коде.
IDE без хаков не понимает как нестатичный метод вызывается статически, в результате когда вам надо узнать где применяется метод doSomething, просто кликнув на Find Usages не выйдет. Приходится искать по всем файлам как строку doSomething()
Таких приколов в laravel-е можно избежать просто их не используя, но в таком случае встает вопрос, почему попросту не использовать сразу Symfony.
Yii2 многие ругают за то что из любого места в коде, будь то вьюха или контроллер есть доступ к апликахе в целом через Yii::$app, но имхо использование факадов в ларе тоже самое, только в профиль.
Сужу об этом исключительно после опыта работу с Zend 2, Laravel 4, Yii1/2.
Перейти на пятую лару пока не получается возможным, надеюсь многие косяки 4-ой версии там исправлены.SerafimArts
02.04.2017 13:19-1Ну так L4 и L5 совершенно разные фреймворки, в L4 без фасадов вообще почти ничего нельзя.
porn
02.04.2017 01:12+2Взять ту же невозможность использования композитных ключей
Забавно. В doctrine best practices Марко пишет: «Avoid composite primary keys».
Any reason to not use an unique constraint instead?
Do they make a difference in your domain?Djeux
02.04.2017 11:19В pivot таблицах получается необходима лишняя колонка только для того чтобы это все работало без костылей.
Tomio
Еще можно добавить к списку (если можно отредактировать) PHPixie.
varanio
Уже нельзя, к сожалению
Voiddancer
Плюсую за phpixie, использую везде его. И буду.
PS: раньше вроде можно было менять опрос?
Nengchak
Какое краткое резюме про phpixie можете сказать? Я просто смотрел в его сторону, но никак не могу слезть с Silex'а
Voiddancer
Просто, отзывчиво, легко. Я не уверен что моей компетенции достаточно, чтобы оценивать фреймворки. Зенд, симфони и ларавель мне не зашли.
Fesor
почему? что отпугнуло?
Voiddancer
Слишком нагромождено. Я раньше не пользовался фреймворками, с MVC познакомился на примере RoR, потом попробовал пхп-фреймворки. Было непонятно.