Как стать автором
Обновить

Комментарии 255

Еще можно добавить к списку (если можно отредактировать) PHPixie.
Уже нельзя, к сожалению
Какое краткое резюме про phpixie можете сказать? Я просто смотрел в его сторону, но никак не могу слезть с Silex'а
Просто, отзывчиво, легко. Я не уверен что моей компетенции достаточно, чтобы оценивать фреймворки. Зенд, симфони и ларавель мне не зашли.
Зенд, симфони и ларавель мне не зашли.

почему? что отпугнуло?

Слишком нагромождено. Я раньше не пользовался фреймворками, с MVC познакомился на примере RoR, потом попробовал пхп-фреймворки. Было непонятно.

Vuejs — отличный php фреймворк

Вы такой остроумный, видимо уронили в детстве?
Кмк, не совсем корректно микрофреймворки типа Slim держать в одном списке с теми же Laravel, Yii. Все-таки у них немного разные ниши.
Возможно, вы правы. Но все-таки они в некоторой степени конкурируют друг с другом.
В любом случае, лучше не усложнять опрос, а то люди будут лениться заполнять.
НЛО прилетело и опубликовало эту надпись здесь

Сочувствую. Держитесь там.

Да, ладно. Ещё первый CakePHP был в работе в сравнении с CMS`ками просто манной небесной.

Сейчас используем 3 версию. От остальных не отстает, работает хорошо

Сейчас CakePHP вроде нормальный, косит под Laravel немного)))
Раньше конечно был адским немного… Наверное неплохо постарались над улучшением, да и над дизайном они явно постарались)))
НЛО прилетело и опубликовало эту надпись здесь
у нас еще проекты на своем фреймворке остались, портируем на ларавель
а кто-нибудь вообще использовал Aura целиком или отдельные компоненты?
Я использовал компонент i18n с Aura.
Я использую Phalcon, Yii2. Для длительного проекта выбрал бы Yii2 из-за скорости разработки, а для простого, или с усиленной безопасностью — то выбрал бы Phalcon, чтобы всё руками сделать
Использую Nova Framework, кто нибудь использовал его вообще?
Почитал документацию, не покидает ощущение слизанности с Laravel. Многие моменты вообще идентичны. И как вам в целом данный фреймворк?
Я посмотрел, там есть компоненты от Laravel. Мне показалось от него многое унаследовано. Простой, можно дополнять. Примеров маловато, есть видео уроки от самого создателя. Ну, а так в целом я использую не нагруженном проекте.
Ну по первому обзору нормальный… Довольно сильно напоминает Laravel)
А вот на каком фреймворке например написан Вконтакте, Гугл, Ютуб, Яндекс, тот же Хабр? Мне кажется ни на каком.
Я тут конечно не эксперт, практического опыта именно работы с фреймворками нет. Но зато есть обширный опыт программинга на С++. Пытался изучать фреймворки по книгам и видеоурокам, в результате пришел к выводу что фигня все это, огромное количество лишних абстракций которые ничего не решают вообще а только создают дополнительные прослойки и сложности.
Может быть это полезно для тех кто штампует небольшие сайты на заказ и важнее всего скорость. А для реальных высоконагруженных проектов вообще целесообразнее написать прототип на одном из веб-языков (php, python...), а затем переходить на тот же С++ или что-то компилируемое, чтобы не занимать процессор выполнением кода интерпретатора, а память — хранением динамически типизированных объектов.
Я конечно тот еще быдлокодер, тоже не люблю фреймворки, но, когда пришлось работать в команде из 20+ разработчиков, местным аналогом тимлида, мне пришлось очень быстро склепать свой фреймворк на базе того говнокода что уже был написан годы назад, а затем 7 лет переписывать его не ломая обратную совместимость, просто по тому что командная разработка разительно отличается от одиночных проектов. Теперь да, это уже полноценный внутренний фреймворк, с весьма хорошей архитектурой целиком удовлетворяющий требования уже не первого заказчика и документированная на 150 листах мануала (не считая комментариев кода), но когда грянул гром — это была мешанина из своих мыслей, в которых черт ногу сломит и новичкам трудно было даже написать простой модуль — слишком большой объем кода нужно было перелопатить чтобы вникнуть в суть.
Еслиб начинал сейчас, начал-бы свой проект на Yii, но тогда его еще и в помине не было.
свой «фреймворк» == не использую фреймворк
Закрытый фреймворк != не использую фреймворк. Данная система используется в десятке корпоративных веб-приложений и активно развивается усилием до 40 разработчиков. То что он не выложен на гитхаб — ну уж простите, я как создатель имею право выбирать какое ПО делать.
Хм, но глупо считать, что те, кто проголосовал за последний вариант копошаться в дерьме из вермишели и палок. :)
Черт его знает. Много что повидал за эти года.

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

знаете, если мне предлагают проект на суппорт, я по умолчанию буду делать предположение что там лапша или лазанья. Это никак не зависит от того на чем проект делался. Зависит только эффорты на рефакторинг.

Хм, то есть и на фреймворках (публичных мейнстримовых) пишут вермишель?
(Я как бы этого не отрицаю, просто уточняю :) )

Тогда не плевать ли, используется мейнстримовый фреймворк или самопись?
Не плевать. В проект на знакомом фреймворке быстрее вникнешь и сможешь что-то сделать для заказчика.
А что вообще нужно от фреймворка?
Работа с базой и кеш? (Это 90+% разработки)

Я вот быстро вник в незнакомый фреймворк. :)
В мои 50 кБ кода вникать не долго.

Или Вы фрилансер?
Ну тут да.
пишут вермишель?

конечно.


Тогда не плевать ли, используется мейнстримовый фреймворк или самопись?

ну одно дело когда у вас вермещель размазанная по крепкому каркасу (иногда там размазана лазанья и это хуже немного) и другое дело когда крепкого каркаса нет и все просто смесь из вермишели.

А у меня не вермишель на самописи.
Возможно, кому-то и нужен фреймворк и батог для дисциплинирования, мне нет :)
Хотя, без понимания, все равно будет вермишель :)

Довелось встречать лазанью на фреймворках:
  • html код выводился через echo 'some long html code'
  • Модели наследовали ActiveRecord, но при этом его не использовали, а дергали какую-то самописную фигню, при этом в этой фигне не было конструктора запросов, каждый запрос писался вручную.
А у меня не вермишель на самописи.

выложите на github, сделаем ревью.


Довелось встречать лазанью

вы видимо не поняли что есть "лазанья-код". Это когда разработчики начали делать слоеную архитектуру (не mvc, это один слой где m на границе другого) и для внесения любых изменений приходится "прорезать" все слои нашей лазаньи.


Фреймворки — это один слой. Он не может быть лазаньей по определению. Далее уже все зависит от того как разработчик работает с фреймворком.


html код выводился через echo 'some long html code'

интересно в каких таких фреймворках вы это видели. Вы про чушь аля CHtml из yii? ну может быть. Или вы про скомпилированные шаблоны twig? Ну так там в этом и суть.


Модели наследовали ActiveRecord, но при этом его не использовали, а дергали какую-то самописную фигню

ActiveRecord — это как подразумевает название — работа с одной записью. Скорее всего "в самописной фигне" разработчики попытались реализовать что-то типа dao но судить о плохости могу только видя код.

выложите на github, сделаем ревью.

Лазаньи у меня нет.
Но есть другие причины:
http://blog.kpitv.net/article/когда-будет-публичный-релиз-ядра-15373/

И для внесения любых изменений приходится «прорезать» все слои нашей лазаньи

И такое было.
Я просто не знал как подробнее описать.
Реально, проще назвать лазанья :)

интересно в каких таких фреймворках вы это видели.

Yii.
Но вряд ли это только он виноват.
Скорее тупость писавших. :)

Ваше «ноу-хау» никому не нужно, кроме вас, это же очевидно. При этом вы боитесь, что вас закидают помидорами, ибо давно бы уже выложили свои «50 Кб» в общий доступ.

Ну, если никому не нужно, то зачем его и выкладывать? :)
Хотя постоянно просят выложить.

Я не хочу, чтобы свиньи не оценили бисер.

Ну и оно не презентабельно пока. :)
Но есть другие причины:

напомню что часть исходников таки у вас вытекла. И да похвастать там было нечем. А что до "ноу хау" — скорее "хау абаут ноу"


Yii.

я не воспринимаю Yii как серьезный фреймворк. Не в обиду людям которые его юзают. Что там с Yii2 понятия не имею — не слежу уже лет 7 за ним.

напомню что часть исходников таки у вас вытекла

То не ядро было :)
Да и там ничего плохого не было :)

П.С.
Кстати, статья обновлена. :)
Не воспринимаю Yii как серьезный фреймворк с тех пор как осознал, что у них все встроенные вещи построены на обязательных паблик полях. В лучшем случае на protected, в случае с AR. Вкупе со статикой люди начинают делать из этого АД. во второй версии все то же самое.

Очень многие большие и сложные проекты написаны на фреймворках (Рельсы, Джанго, Лара и Симфони) вполне легко найти инфу. Полемика нужны ли фреймворки гудел лет 4-5 назад. И фреймворки победили.

Миллионы мух не могут ошибаться :)

Оставьте эту пошлую риторику. Не хотите фреймворки? Так я вам их не продаю.

При чем пошлая?
При чем риторика?

Вы сказали, что была полемика и была победа. :)
Я же усомнился в ваших словах. :)

Я у вас ничего и не покупаю.
Вот только усомнились вы в правильности решения использовать фреймворки, приведя как аргумент их популярность.
Как единственный аргумент это действительно выглядит пошло.
Недостатки выбраны превосходные. Чего стоят только
1. Плохая документация
2. Не самое логичное формирование путей для файлов
3. Дибильная работа с БД
4. При выпуске новых версий как правило отсутствует обратная совместимость
5. Неудобно создавать статические страницы
6. Нету возможности выполнить другой контроллер

И теперь главное. Эти недостатки автор приписывает ВСЕМ фреймворкам. У меня это взорвало мозг.

Сложилось впечатление что автор работал с yii 1. Но назвал это всеми фреймворками. Что удивляет еще больше так это дата этой статьи 2016 год. Автор критикует yii 1 который вышел в 2008 (!) году.
Также судя по разделу работы с базой данных автор не разобрался как правильно делать join. Но это не помешало ему найти сообщение на форме с корявым использованием и критиковать это =)
1. Она действительно плохая.
Расчитана на дебилов.
2. Ну да, там точки, там /, там \, я в этом не смог найти логику :)
Там включается название «модуля», там нет.
3. Если есть дибильный простой способ, то он и будет использоваться.
Законы Мерфи.
Ну и об этом советуют на форуме фреймворка.
Ну и то обсуждение вроде ж не 2008 года.
Ну и это значит, что фреймворки не святые, а эволюционирует.
Но так само может эволюционировать и самопись.
4. Ну да.
Программисты на фреймворках никогда не останутся без работы.

5. А разве удобно?
6. А разве обойтись одним «контроллером» нормально?
Выходит потом огород из костылей.

Yii 1.1 вышел в 2008 году?
Yii 1.1.17 афаир вышел в 2016 году.

Ну, то есть, Вы хоть какие-то контраргументы нашли только для п. 3.

Эти недостатки автор приписывает ВСЕМ фреймворкам.

Читай внимательно:
Как сказано выше, это не значит, что пункт не подходит к другим фреймворкам.
Разрази меня гром!
Вы свое абсолютное невежество в знаниях фреймворков (да похоже и архитектуры проектов в целом) вылили в бессмысленную статью совершенно оторванную от реальности.

Спрячьте(-сь). Не позорьтесь. Не надо так.

Так это уже его 3ая (если не ошибаюсь) реинкарнация на Хабре. И он всё время в комментах эту статью пихает)

Видимо поэтому и ник http3 :)

Долго думал, при чем тут зая… Оказалось, что это третья :)
О, вы новый аккаунт завели. А старый вместе с комментариями удалили?
НЛО прилетело и опубликовало эту надпись здесь
Та мне плевать на карму :)
НЛО прилетело и опубликовало эту надпись здесь
Может в том, что вы меня не слышите? :)

Я не говорил, что фреймворки не стоит вообще использовать.
Я говорю, что я не использую в личных проектах.
При этом не отрицаю, что они используются на работе.

Против чего же я выступаю?
Против утверждения (явного или не явного), что фреймворк подходит всем и для решения всех задач.
Против утверждения, что все те, кто не использует фреймворк, те лохи, а использует — д'Артаньяны.
Я так же само выступаю против дрочки на ООП.
Против хайпа на Реакт / Ангуляр.

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

Похожая точка зрения дана тут относительно использования наследования / композиции:
https://habrahabr.ru/post/325478/

Ну и все же следует признать, что аудитория чуток потупела все же.
Ну и у аудитории плоховато с юмором.
Хз как они отнесутся к комменту, оставленному для прикола.

Но вот сторонника фреймворков обвинили чуть ли не в поддержке моей позиции :):

Получу ли я адекватный ответ на этот коммент? :)
Вряд ли. :)

П.С.
Перечитал еще раз Ваш ответ.
Вы как бы и сами констатировали, что меня не хотят слышать :)
Но я не говорю, чтобы меня слушались.
Аудитория глухая? :)
Против утверждения (явного или не явного), что фреймворк подходит всем и для решения всех задач.

кто-то где-то подобное утверджает?


Я так же само выступаю против дрочки на ООП.

смотря что считать ООП. Если вы про идею тотальной инкапсуляции и late binding то это одно. А если паттерны, расширение за счет наследования и AbtractFactoryFactory — это совершенно другое. Первое это развитие идей структурного программирования, а второе это рак.

кто-то где-то подобное утверджает?

Ну вот в этой ветке.
Но в соседней теме Вы дали самописи 0,1%, и на том спасибо. :)

паттерны, расширение за счет наследования и AbtractFactoryFactory

Это.

Паттерны я бы выделил отдельно в паттерны головного мозга, паттерны наше все. :)
Но в соседней теме Вы дали самописи 0,1%, и на том спасибо. :)

На сегодняшний день в 50% случаев и бэкэнд свой писать не надо. не то что фреймворки свои писать.


Паттерны я бы выделил отдельно в паттерны головного мозга, паттерны наше все. :)

обычно с паттернами разработчики переживают три стадии:


  • паттерны это круто, они делают код лучше
  • паттерны отстой, они делают код сложнее
  • о, так выходит надо знать когда чего юзать...

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

НЛО прилетело и опубликовало эту надпись здесь
Та тут большинство оленей :)
Я первый не плевал…
Вдруг что, статья значительно переработана и улучшена. :)
Я же усомнился в ваших словах. :)

я так и не понял вашей позиции. Вы против именно full-stack фреймворков с готовый структурой но не против отдельных компонентов с помощью которых можно сделать свой фреймворк под задачу. Или вы вообще против любых third-party решений?

Я не против сторонних решений вообще :)

И я не против full-stack фреймворков вообще.
Просто имеющиеся переусложнены.

Правда, я не особо ковырялся с минифреймворками вроде Silex/Slim.
Они считаются full-stack или нет?
Просто имеющиеся переусложнены.

потому что они хэндлят штуки о которых вы не думаете? Это не переусложнение. Ну и да, не надо сравнивать с решениями вроде yii, там действительно все плохо и да это субъективная оценка.


Они считаются full-stack или нет?

да, они проще. Они хороши когда вам нужно что-то простое сделать. Например read-only часть приложения или чего еще.

потому что они хэндлят штуки о которых вы не думаете?

Да.
Я хочу понимать всю подноготную работы приложухи.
С самописью я понимаю. :)

yii, там действительно все плохо

Его критикуют за более монолитность. Мне это не особо важно.

Но разве что-то мешает использовать сторонний код в нем?
Те же компоненты от Симфони? :)

Моя самопись, если честно, тоже местами монолитна.
Это как бы не совсем гибко, но эта гибкость и не нужна пока в тех местах. :)

Они хороши когда вам нужно что-то простое сделать.

Все вещи желательно делать простыми, а не сложными. :)
С самописью я понимаю. :)

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


Я хочу понимать всю подноготную работы приложухи.

Вы изучали как работает Zend VM? Ибо по вашей логике для комфортной работы вам и этот уровень абстракции надо залесть. Ну и ниже, как вообще работает выполнение машинного кода, как операционная система изолирует память для процессов, как разруливает приоритизацию процессов, контекст свитчинг и т.д.


Но разве что-то мешает использовать сторонний код в нем?

Есть нюансы. Многие вещи там тупо нельзя заменить не перелопатив половину всего.


Все вещи желательно делать простыми, а не сложными. :)

KISS и все такое? Обычно в качестве примера предлагают историю из 60-х когда главный инженер потребовал спроектировать сверхзвуковой истребитель который пилот может починить обычными инструментами в поле.


Другими словами вещи должны быть простыми в использовании и обслуживании, но это не означает что внутри все будет просто и уж тем более сделать так бывает крайне сложно. Можете просто почитать про трудности которые пришлось решать когда делали usb type-c. Его легко юзать, но там были интересные задачи.

А другие разработчики которые будут поддерживать после вас?

Почему я не использую в личных проектах PHP фреймворки

Им же тоже придется разбираться и для них будет тоже самое что и любой другой фреймворк

Там всего 50 килобайт :)

Ибо по вашей логике для комфортной работы вам и этот уровень абстракции надо залесть.

На этот не нужно.
Только *.php код. То, с чем я работаю.

сделать так бывает крайне сложно

Просто сделать сложно.
Сложно сделать просто.
:)
НЛО прилетело и опубликовало эту надпись здесь
Когда надо в кратчайшие сроки запустить проект чтобы начал приносить деньги, особо нет времени заниматься велосипедо-строением дабы избежать фатального недостатка.
Позвольте слегка не согласиться.
Да, фреймворки содержат огромное количество абстракций, но никто не заставляет использовать все возможности конкретного фреймворка. Пишите свой, более быстрый код, который не «создаёт дополнительные прослойки и сложности». Вот только зачастую, чтобы добиться такой же гибкости и стабильности, придется написать как бы не более сложную и запутанную структуру. Всё же код фреймворков оптимизируется постоянно.

Что касается интерпретатора — нагрузка на процессор значительно снижается путем использования того же OPCache, благодаря сохранению однажды использованных структур и данных в памяти. Очень приближенно можно сказать, что в результате процессор будет выполнять только полезную работу, не повторяя раз за разом те же расчеты.
Вы правы.

Ну кроме переписывания на С++.
Кроме всего перечисленного, задам вопрос, а какой процент разработчиков пишет крутые проекты типа Гугла, Вконтакта или Фейсбука?
С нуля писать конечно очень увлекательно, но пока вы это делаете, конкурент уже забацает двадцать штук интернет магазинов на одном из перечисленных фреймворков.
А сколько времени писались
Гугла, Вконтакта или Фейсбука

? :)
Годами, что ли? :)
До сих пор пишутся )).
Кроме того, это не совсем стандартные проекты, плюс работают под дикой нагрузкой.
Ооо, они до сих пор не написаны?
Откуда Вы о них узнали тогда? :)
Вообще то код этих проектов постоянно правят. Вот что я имел в виду.
Как, собственно, и большинство остальных проектов ).
А на фреймворке раз написал и править не нужно? :)

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


Если без фреймворка мы будем делать ровно то же самое только сами и в своем. И тут не надо много ума что бы понимать что это не так эффективно.

Возвращаемся назад.

Гугл писался годами? :)
Повторное использование кода в самописи тоже запрещено? :)
Вы наивно полагаете, что гугл написан один раз и сейчас он в своём первозданном виде?
Сегодняшний гугл писался годами и пишется прямо сейчас.
гугл написан один раз и сейчас он в своём первозданном виде?

Где я такое писал?

Сегодняшний гугл писался годами и пишется прямо сейчас.

Где я это отрицал?
В основном у комментов по одному минусу.
Это один имбицил тупо минусует мои комменты? :)
А, сорри, 4 имбицила. :)
Гугл писался годами? :)

инкрементами и по чуть чуть уже десятилетиями. Что до "использует ли гугл фреймворки" — точно использовали django лет так 8 назад, используют разные ангуляры и и т.д. До этого тоже были продукты от них. И до этого…


Повторное использование кода в самописи тоже запрещено? :)

Код нельзя реюзать. Если вы видите в коде общие вещи вы должны выделить из этого абстракцию и вот уже абстракции реюзать можно.

инкрементами и по чуть чуть уже десятилетиями

А самопись не может так же писаться? :)

точно использовали django лет так 8 назад

Ого.
Ангуляр — это js и их же разработка…

Код нельзя реюзать. Если вы видите в коде общие вещи вы должны выделить из этого абстракцию и вот уже абстракции реюзать можно.

Что за ерунда?
Годами, что ли? :)

Ну какбы да. В целом если разработчики больше не коммитит код в проект то велика вероятность что проект мертв. А значит если вашему продукту лет 10 и более то его продолжают писать.

интернет не ограничен одними интернет-магазинами. Фреймворки хороши когда a. ты их знаешь b. ты занимаешься чем-то относительно стандартным и это стандартное ложится на логику фреймворка.
Шаг в сторону от мейнстрима — и добро пожаловать в клуб велосипедостроителей! Только я не понимаю когда говорят от построении «с нуля». Нет никакого нуля, просто переходим на более низкий уровень — берем либы и компонуем. Нормальный такой процесс, почему нет.
ты занимаешься чем-то относительно стандартным

аля "пишу http-based апы?" В любом нестандартном проекте есть "стандартные" части. Вроде "а как логи писат" или "а как хэндлить master/slave коннекшены к базе" или "а как зависимостями управлять в проекте". И в итоге мы берем любой фреймворк, возможно выкидываем отдельные компоненты и живем.

>В любом нестандартном проекте есть «стандартные» части. Вроде «а как логи писат» или «а как хэндлить master/slave коннекшены к базе» или «а как зависимостями управлять в проекте».

Вы меня простите великодушно если я заблуждаюсь, но все же вынужден спросить — Вы разницу между фреймворком и либой понимаете?
Вы разумно рассуждаете. Наводите хорошие примеры. А вот вывод не корректный.
Действительно если вы пишете гигантский сервис при разработке которого участвуют сотни человек. И работа идет годами. Тогда важность использования фреймворка опускается до 0. Вот только с этого утверждения вы делаете (не корректный) вывод что сфера применения фреймворков — маленькие сайты. Yahoo! и BlaBlaCar используют symfony. 2gis.ru использует yii.
«Маленькими сайтами» назвать их язык не повернется.

Ваше желание использовать C++ при веб разработке понятно. Ведь это ваш основной язык (с ваших слов). И его действительно в некоторых случаях стоит применять. Но в подавляющем большинстве случаев использование C++ как базового языка для веб приложения сродни самоубийству. Слишком увеличивается скорость и сложность разработки и поддержки такого проекта. Мы живем не в вакууме и это нельзя спускать со счетов. А вот самые высоконагруженные места можно и на C++ написать. В угоду скорости.
По второму вопросу воздержался, фреймворк нужно выбирать по ситуации.
Есть свой ADR масштабируемый микро-фреймворк.
На работе модифицированный ZF1.

Давно присматриваюсь к PHPixie.
свой ADR масштабируемый микро-фреймворк.

Вот вы юзаете ADR. Расскажите как. Правильно ли я понимаю что ADR у вас сводится к тому что формирование респонсов и запросы на чтение вынесены в респондеры? Бывает ли так что "экшен" занимается лишь инвоуком респондера? У вас апишки или сервер плюется html-ем (что бы примерно прикинуть что внутри респондера). Ну и в целом какие ограничения вы накладываете на эту троицу? Чего там быть например не должно, какие взаимоотношения и уровень знаний у action к resonder и т.д.

Использую уже два года Nette чешский. Быстро разворачивается, есть composer библиотеки.
Вы его сами выбрали или досталось по наследству? У меня после 3 месяцев работы очень негативное к нему отношение.
Выбрал сам, подкупил документацией и легкостью. А в чем причина негативного отношения?
Тем что он MVP и очень мало где используется. Но это чисто субъективное мнение.
Я с ним имел дело года 3 назад и не с нуля.
Тем что он MVP

давайте разбираться в разнице между mvp и mvc:



То есть сугубо говоря mvc в трактовке php фреймворков ничем не отличается от mvp.

В основном Symfony + DDD/CQRS/CommanBus/ApiDoc.
За многие годы использования фреймворков, а были у меня в продакшне и известные, такие как Symfony, Yii, Laravel, так и свои, пришел к выводу, что монолитные фреймворки как бы не особо нужны, а иногда, как Yii, и вредны (да-да, я про $breadcrumbs в контроллере!)

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

Всё это активно используется как в собственных проектах, так и профессионально (за деньги), развивается и адаптируется под новые версии PHP. Заодно на тех же библиотеках студенты у меня учатся участвовать в командной разработке, использовать TDD и вообще прикасаются немного к «взрослому» программированию в плане огранизации своего труда.

Планирую этому хозяйству однажды дать звучное имя и выложить в публичный доступ, как очередной мега-фреймворк-убийца-всех-остальных :)) Но врожденная скромность и вечная прокрастинация всё как-то мешают…

Резюмируя: хорошего фреймворка на PHP еще нет, у всех какие-то свои скелеты под капотами, но что-то мне подсказывает, что сообщество к нему уже готово. И, значит, он скоро появится.
Symfony можно использовать как набор слабосвязанных библиотек, не обязательно тянуть весь
Чем он выгодно и отличается от других актуальных фреймворков.
Собственно, вы с Zend'ом знакомы? Там куча отдельных компонентов на все случаи жизни
Собственно да.
Но всё равно берусь утверждать, что это сильно связанный фреймворк. Несмотря на наличие компонентов на все случаи жизни.
Одно другое не исключает.
НЛО прилетело и опубликовало эту надпись здесь

Правильней говорить:


Сейчас все актуальные фреймворки перешли на компонентны Symfony)))
Значит не за горами появление чего-то нового. Не может Symfony быть вечным.

Согласен. Было бы интересно посмотреть на что-то лучше Symfony)))

на базе компонентов symfony можно свой фреймворк сделать, сам когда то делал. ну и laravel так сделан.
НЛО прилетело и опубликовало эту надпись здесь
Последний раз ковырялся в вашем ПеХаПе наверное в 2004 году.
И тогда ООП только только начинал внедряться, пятая версия тогда вышла.
Сейчас вижу седьмая вышла.
До чего прогресс дошел, ваш ПеХаПе показывают и тут и там

НЛО прилетело и опубликовало эту надпись здесь
Ваше мнение очень важно для нас, пожалуйста, оставайтесь на линии :)
Извините, в последнее время меня тянет на чистый С и ASM.
Крис немного заразил меня Реверс инженерингом.
Но я упорно сопротивляюсь этому.

А я веган

попробуйте rust.

При всей моей нелюбви к PHP — вы держите, пожалуйста, в курсе. Это очень важно.

Update: пока писал комментарий — уже за меня выше ответили. :3

Я б сказал, «вы держитесь там, счастья вам, здоровья» :)

И хорошего вам настроения, да. Денег нет, но вы дебажьте.
Zend это не только Zend Framework но и микрофреймворк Zend Expressive. Но, судя по опросу, все равно не в тренде :)
Хочется Laravel, Symfony, Yii, Phalcon, Zend… а на практике — Битрикс и NoNameShitFramework
по-моему zend со второй версией очень долго жевал сопли и его обскакала «Symfony-based коалиция» и начала продвигать свой путь на рынке, из-за чего zend просел еще сильнее.
Не исключено, что ZF3 позаимствовал компонентный подход у Symfony, но это же не делает его менее привлекательным, правда?
В конце концов, даже не особо популярный в России ZF3 иногда сделан куда лучше своих 'битриксовых' аналогов.
ой, извиняюсь, я оказывается веткой промахнулся :)
Мое сообщение должно быть чуть выше к комментарию Sora
Буквально вчера видел тему на форуме пхпклаб, как один человек хотел внедрить Laravel в Битрикс, так как ему не хватало доступного функционала админки битрикса))
Лично я сам уже переборол себя и потихоньку с Битрикса перехожу на Лару (по крайней мере перевожу свои проекты). Надоело вариться в этом котле безрассудства и похоти)
В прошлом году подобное выступление было

внедрить Laravel в Битрикс, так как ему не хватало доступного функционала админки битрикса

Упс. :)
Скрещивание ежа с ужом :)
Админка нормально кастомизируется стандартными средствами.
Можно добавлять пользовательские типы данных.
Laravel и Kohana 3.2

Spiral, внутренняя разработка, используем последние 5 лет.

Перешел с Symfony на Silex, как ни странно. Из Silex по сути используется роутинг и контейнер, остальное либо добивается компонентами той же Симфонии, либо самописными компонентами.

А как же MicroKernelTrait? С появлением оного у silex-а вообще не осталось смысла в существовании. Его и сделали исключительно как пример как можно собрать по быстрому фреймворк на компонентах симфони.

Честно сказать, не слышал и не пробовал. Возможно когда я ставил Силекс, его еще просто небыло.

Он и так «микро». Работает шустро, все что мне нужно предоставляет — что еще нужно то? :)
НЛО прилетело и опубликовало эту надпись здесь

Ну по сравнению с контейнером лары — он довольно ограниченный. Нет двойной диспатчеризации, нет ленивого автовайринга, фриз после билда (т.е. отсутсвие вставки новых сервисов в рантайме, возможно это и плюс), нет контекстуального биндинга (как раз из-за отсутсвия ленивого автовайринга) и проч.

Нет двойной диспатчеризации

в 3.3 наконец-то сделали возможность юзать интерфейсы как id-ники сервисов, так же автовайринг теперь работает за счет алиасов. Так что дабл диспатч прикрутить сверху это изи.


нет ленивого автовайринга

Что есть "ленивый" автовайринг? В любом случае что-то похожее есть в 3.3 через setters/getters injection.


фриз после билда

мы уже обсуждали это, для test энвайрмента доступен ContainerBuilder со всеми возможностями для замены сервисов в рантайме.


нет контекстуального биндинга

скоро будут.

Что есть "ленивый" автовайринг? В любом случае что-то похожее есть в 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

Тот, который не надо объявлять, оно само находит декларации.

то если "ленивый" не в плане как оно работает в рантайме а "ленивый" в плане что ничего делать не надо? Ну нет, настолько опасных вещей в симфони не будет. Для ленивых там есть defaults для сервисов с 3.3 версии которые решают эти проблемы.


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

Этим ты сделаешь свои сервисы stateful и отслеживать это будет просто ад. Request вообще входящие данные, им не место в контейнере. Ну либо опять же тогда на каждый реквест надо делать свой контейнер который вытягивает вещи из основного зафриженого. Это позволит сделать много прикольных вещей.


Authenticatable мне прилетала энтити юзера.

У меня это не сущность (не люблю юзеров по контроллерам размазывать), а просто какой-то объект. Ну и пишется он у меня в атрибуты запроса. И в целом это очень и очень удобно.


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

Я пихаю туда кусочек entity manager который для query builder-ов и query. Ну мол у меня за операции чтения отдельные штуки отвечают, репозитории должны возвращать одну и только одну сущность. И никогда не null и не массив сущностей. Возможно это излишние загоны, но так контроля больше и возможностей.


К примеру я сейчас эксперементирую с кастомными гидраторами для доктрины и с ними можно делать очень много интересного. В частности мне все больше нравится идея не пускать сущности на view и использовать штуки вроде модифицированных array hydrator и т.д. или мэпить на dto сразу из dql.

то если "ленивый" не в плане как оно работает в рантайме а "ленивый" в плане что ничего делать не надо? Ну нет, настолько опасных вещей в симфони не будет. Для ленивых там есть defaults для сервисов с 3.3 версии которые решают эти проблемы.

Конечно не будет, по-этому вместо таких штук:


$container->factory(FactoryItem::class, ['a' => 23]);
$container->factory(FactoryItem::class, ['b' => 42]);

Приходится писать отдельный фектори, внутри которого придётся руками проставлять все аргументы из контейнера через сервис локацию (потому что симфонийский контейнер, вспоминаем, фризится).


Ну и т.д. Все ниже приведённые тобою отговорки имеют право на жизнь, более того — это вполне грамотные решения проблем. Только этих проблем в Laravel не возникает — отличие в этом.


<irony>
А давай вспомним бандлы? Моя любимая часть симфони. Начнётся всё с построения дерева конфигов. Примерно там же и будет похоронен юный падаван. "Зато никаких ошибок в конфигах" — говорили они =)
</irony>

Начнётся всё с построения дерева конфигов. Примерно там же и будет похоронен юный падаван. «Зато никаких ошибок в конфигах» — говорили они =)

а мне в ларе этого иногда не хватает, особенно если кто-нибудь альтернативно одаренный без чтения документации будет писать в конфигах какую-то дичь (строки вместо чисел например). Или снесет пакет, а конфиги останутся. Или при клонировании репозитория — в ларе сам читай readme и ищи какие параметры в .env нужно прописать если никто не прописал в .env.example то что нужно. А симфони сгенерит при установке пакетов parametest.yml с дефолтными значениями где останется прописать свои параметры для окружения
а мне в ларе этого иногда не хватает, особенно если кто-нибудь альтернативно одаренный без чтения документации будет писать в конфигах какую-то дичь (строки вместо чисел например).

Подсказываю решение:


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

С другой стороны кто-нибудь может удалить бандл, а тот же самый parameters.yml так и останется висеть набитый левыми переменными

Это к приложению относится, настройки бандлов в config_%env%.yml обитают.
Сносим бандл — все, симфони будет ругаться что лишние конфиги которые не к чему применить остались.
А за parameters.yml.dist следить да, надо самому
Подсказываю решение:

Это конечно круто, но как-то не то. А так в нужных местах можно было бы сделать так:
$rootNode
    ->children()
        ->integerNode('positive_value')
            ->min(10)
            ->max(1000)
        ->end()

А в ларе придется самому за этим следить и исключениями бросаться

Так а никто не мешает делать ассерты в репе, в результате получится ровно тоже самое, только вид сбоку:


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)
  • Можно точно так же добавить красивый интерфейс для конфигов со сложной логикой: тыц и тыц — явно видно преимущество необязательности использования симфонёвых нод для конфигов, т.к. задача проще и красивее решается.

Ну т.е. подводя итог — оба решения имеют право на существование, только на практике ноды почти всегда сложнее выходят, нежели простое решение "в лоб", но конечно же не всегда.

ассертинг отключается, 0-cost

ну как бы в symfony же все кэшируется и дампится так что тоже 0-cost.


Можно точно так же добавить красивый интерфейс для конфигов со сложной

А может не надо делать сложных конфигов?)

А может не надо делать сложных конфигов?)

А ты посмотри по ссылочкам лучше, а не вбрасывай =)

ну в симфони это был бы 1 compile pass и 1 тэг. и вместо некого RenderersRepository был бы RendererChain.

Zend гидраторы по-моему помощнее.
Там одна проблема. Связности.
Сами гидраторы могут жить отдельно.
А вот удобные агрегаторы тянут за собой целый ServiceManager

НЛО прилетело и опубликовало эту надпись здесь
Любителям Kohana советую обратить свой взор на fuelphp
В работе для последних двух проектов, которые пишутся уже больше года, взял Yii2. Для pet проекта написал свой микро фереймворк на PHP7.

Свой фреймворк разделил на две части, API и web. API принимает параметры через GET или POST, валидирует их и возвращает JSON с успешным результатом или ошибкой. Web выводит HTML. Реализовал всё самое необходимое: простейший роутинг, локализацию, мирграции, подключение ассетов, вывод шаблонов, валидацию параметров. Больше пока не понадобилось. Задокументировал, покрыл тестами на 70%. Пустую страницу выводит быстрее, чем Yii2, в 5 раз. Yii2 — 2.5ms, my — 0.5ms.

Возникают мысли выложить исходники в открытый доступ, но пока не вижу в этом целесообразности, так как писался он под определённую задачу, и многие популярные вещи, такие, как ORM, подключение шаблонизатора, вроде Twig, кастомные логи и прочее, в нём отсутствуют.
Странно вы сравниваете. Говорите, что написали свой микрофреймворк и сравниваете его с yii2 в котором на данный момент нет микроядра.

Использую silex / symfony, а вот следующий проект начну на Scala+Spring )

Что такое pet-проект?
Личный проект без получения денег?

А если личный с получением денег, то можно голосовать? :)
да
У меня есть нечто самописное, состоящее из роутера и своей реализации ActiveRecord (которая по функционалу пока не доходит до реализации из Yii2, но уже превосходит ту, что в первом Yii; по удобству использования имхо превосходит обе).
Не сказать, что работает быстрее прочих, но зато писать код с его помощью довольно просто.
Это CMS все же.
Я на прошлой неделе в Joomla добавлял AdminLTE в качестве фронтэнд странички, тоже думал что пора б заканчивать скрещивать ужа с ежом.
НЛО прилетело и опубликовало эту надпись здесь
Можно сделать плагин, содержащий всю логику проекта, и использовать там Composer и компоненты Symfony, написать адаптеры для API Wordpress и даже что-то попробовать в дальнейшем перенести, если понадобится, на любую платформу, реализуя аналогичный подход. Минус в том, что обычные WP-разработчики попросят у клиента много денег за доработку, т.к. им будет сложно разобраться в проекте. Некоторые вещи можно и в обход движка делать для ускорения, например, AJAX запросы, загрузка ядра занимает очень много времени. Попробуйте личный кабинет пользователя так написать или систему коллективного блоггинга. Мне такие задачи на WP попадались, но тогда я сочетанием корявых плагинов обходится, не осилил сам сделать.
Можно сделать плагин, содержащий всю логику проекта, и использовать там Composer и компоненты Symfony, написать адаптеры для API Wordpress

Кто кого будет дергать?
Wordpress Symfony
Или
Symfony Wordpress?

Естественно Symfony будет дёргать WordPress.

Извращение. :)
Вдруг что, я писал «кто кого» будет дергать, а не «кого кто».
Уже много лет работаю с Kohana.
На поддержке старых проектов или новые запускаете на Kohana? Если не ошибаюсь фреймворк мертвый уже года 3-4 как.
На кохане сделал что-то вроде простого CMS. Так что изредка пеку и новые проекты.
В долгоиграющем проекте (архив документации, электронный документооборот) используем mediawiki, поддержка модульности, версионирования, интернационализации. Известно о нём только благодаря википедии.
Другой (укажу в комментариях)

На собственном. Странно, что такого пункта нет :)

С самого появления Yii работал с ним. Сталкивался в свое время с CI и Kohana.

С этого года стал перебираться на Symfony в виду того, что поменялся взгляд на разработку.

Большой плюс и одновременно минус Yii, чисто субъективно, возможность быстро стартануть и низкий порог вхождения. Но при этом вся ответственность за архитектуру приложения лежит на разработчике. Если, что бы наговнокодить в Symfony нужно приложить специально определенные усилия, то в Yii это может получится само собой, в попытке сэкономить время. Ни что не мешает вызвать вьюху в модели, сохранять модель во вьюхе, а бизнеслогику перенести в контроллер.

Лет пять назад, джаст фо фан, с другом запустили небольшой сайт для автоматизации размещения его панорам. Шло время, прикрутил rbac и регистрацию юзеров, что бы и друге могли размещать свои панорамы, потом понадобился форум, потом api понадобилось. И в итоге, все это разрослось в такого мутанта, что когда мне нужно что-то новое добавить в код, я начинаю плакать кровавыми слезами :)

Так что, имхо, важнее не фреймворк, а то, как им пользоваться. Просто с некоторыми фреймворками накосячить сложнее, чем с другими.
я использую компоненты фреймворков и отдельные либы/пакеты
  • cboden/ratchet
  • react/react
  • guzzle/guzzle
  • symfony/http-foundation
  • klein/klein
  • twig/twig
  • colshrapnel/safemysql
  • monolog/monolog
  • raulfraile/ladybug
  • curl/curl
  • phpseclib/phpseclib

+FlightPHP.
Второе голосование, на мой взгляд, не совсем верно — нельзя точно говорить о выборе фреймворка не имея информации о проекте.
Длительное время вообще не использовал фреймворки но два года назад познакомился и подсел на Phalcon и очень им доволен, сейчас постепенно перевожу рабочие проекты на Phalcon, с учетом того что специально для нас была добавлена в Phalcon поддержка twemproxy.
Пишем все проекты на yii. Присматриваемся в сторону yii2. Перешли бы хоть завтра, но переписать за один день весь наработанный багаж не получится.

А у Joomla тоже фреймворк есть. И далеко не самый худший.

Сейчас сижу на Yii2, но больше по душе компонентный подход: Slim + пакеты сторонних разработчиков. В зависимости от задачи нужно постепенно наращивать функционал, усложнять бизнес-логику приложения. Здесь многого не надо: пакеты, которые крутятся вокруг HTTP-спецификации; работа с БД (Medoo, Eloquent ORM, Doctrine2); шаблонизатор (как по мне лучший Twig, нативный принципиально не рассматриваю). Но и вся архитектура на вас. Чаще в такие проекты порог входа выше, нежели в любой «тяжёлый» фреймворк.

Slim + пакеты сторонних разработчиков
+1. Slim, как каркас — великолепен. Ничего лишнего и шикарная архитектура, позволяющая легко и даже элегантно наращивать «мясо».

Работал с Zend 1, Symfony 2, Yii 1 и самописными фраймворками.


Как-то пришлось начать проект на Yii 1 после Symfony 2.
Год разработки я плакал горькими слезами (буквально).
Даже если очень захотеть, не говнокодить на Yii почти невозможно.


Смотрел Laravel. Тот же Yii вид сбоку.


Уже несколько лет я на Symfony и счастлив как ребенок.
DDD + CQRS + Specifications + ValueObject + Doctrine


Даже маленькие проекты на Symfony летают.

Ну у меня и на Yii2 проекты летают. Тут как пишешь и что используешь, мне кажется…

Позвольте, не стоит сравнивать Yii и Laravel — это совершенно разные подходы для одно "целевой аудитории".


DDD и прочее в Symfony вытекает из использования доктрины. Посмотрим как вы с Propel'ом так же развернётесь =) Берёте лару + доктрину и отличий не найдёте, ну кроме того, что не будет в проекте этой треклятой сервис-локации, а всё будет по-нормальному с чистым DI.

Просто интерсено: почему по вашему мнению, DDD вытекает из использования доктрины?
Доктрина, например, не умеет в ValueObject as identity. А собственно саму поддержку ValueObject запилили только спустя 5 лет после реквеста.
DDD с симфони применим, потому что фреймворк очень гибкий, а не потому что какая-то либа задаёт правила.

Не только доктрины. AR крайне сложно представить в виде чистых доменных сущностей из-за своей специфики прямой связанности с БД (т.е. тупого DAO). А доктрина — Data Mapper с чистыми энтитями никак не связанными со структурой БД, которая, как известно, хранит зачастую много технической информации не связанной с предметной областью. По-этому нормальную предметную область можно организовать лишь при использовании не-DAO ORM, как доктрина, к примеру. От фреймворка это уже мало зависит.

Я сравнивал 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. Если я что-то упустил, просветите меня пожалуйста.

Laravel 1 вроде как никогда не выходил, а на гитхаб вылился начиная с версии 3+ (сейчас 5.4, летом 5.5 LTS), откуда такой раритет? Поделитесь?

Таких подробностей я не помню. Смотрел на него несколько лет назад когда он только появился на хабре.

На хабре он начал появляться начиная с версии 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 в пару тычков, т.к. декларативные возможности роутинга, конфигов и прочего симфони — это всего лишь надстройка над императивщиной.

Теперь отдельно по пунктам:


роутинг через 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)
  • Возможность подписываться на любые события контейнера (например вызывать сеттер после резолва сервиса из контейнера)

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

Этот роутинг аналогичен именно симфонёвому, в 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 будет резолвить разные сервисы с одним интерфейсом? Да никак. Бам. О, моя нога)))

А чем он гибче и многословней?

Гибче?


  • Префиксы в том же месте, где и роуты (не вынося в отдельный 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

Скорее наоборот. В Laravel из коробки на несколько порядков больше возможностей. В симфони же почти всё ставится руками, всегда, начиная с flysystem, заканчивая всякими monolog, swiftmailer и проч.


А вы точно пробовали пакет symfony/symfony и symfony/framework-standard-edition? Это как раз для тех, кто хочет готовый комбайн под новый проект, если что. Потом можно ненужные вещи (твиг, например, в АПИ не пригодился) — выпилить

https://packagist.org/packages/symfony/symfony
https://packagist.org/packages/symfony/framework-standard-edition

Я про абстрактные билды в целом, потому что даже если брать какой-нибудь 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 фикстурами в симфони, но вроде у доктрины есть из коробки, не помню)


Ну и ещё огромное количество мелочей. Почти во всех проектах симфони это приходится руками доставлять.

P.S. Ну и ещё cross-DB миграции.

То есть, большое количество предустановленных компонентов в фраймворке которые будут не нужны большинству вы считаете плюсом?


Вы мне напомнили сейчас M-A-XG (нынче он http3) который хает фраймворки потому что в них нет хлебных крошек.


Фраймворк это каркас и конструктор, на который навешивается всю что необходимо в конкретном проекте и необходимость доставлять компоненты, это не то что нормально, это правильно.

Прошу заметить — это всё необходимые компоненты в 99% сайтах, которые чуть сложнее бложика.

Большинство этих вещей устанавливаются в два клика пару команд — 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. А так вы видимо просто делаете что-то однотипное.

У нас сейчас используется микросервисная архитектура и проекты на симфони и все разные. На половине из них все то, что вы написали не нужно.
  1. А как вы почту отправляете, например после регистрации? В том же треде? Это плохо.
  2. Это нужно для любых задач, например синхронизация данных с внешним апи раз в N часов. В кроне всегда будет одна строчка, вместо 100500. Это никак не относится к деплою.
  3. Я уже затерялся в комментах, повторите? Я не вижу: https://github.com/symfony/symfony-standard/blob/master/composer.json#L15-L25
  4. Неа, в 2.8 есть только аутентификация, надо ставить FOS поверх
  5. Это фигня, забей =) Тупо возможность пушить сообщения поверх, например вебсокетов.
  6. свифтмейлер только в стандард, в самом фрейме нету: https://github.com/symfony/symfony/blob/master/composer.json#L19-L30 По поводу остального и ватсап тоже: https://packagist.org/search/?q=laravel%20notification
  7. в доктрине, ага
  8. алис не такой гибкий, как доктриновский

Если доставлять приходится во всех, то вы давно могли сделать свой метапакет,

Нет конечно же, не во всех.

2) Sheduler
Это нужно для любых задач, например синхронизация данных с внешним апи раз в N часов. В кроне всегда будет одна строчка, вместо 100500. Это никак не относится к деплою.

Планировщик это по сути тот же крон, но внутри приложения. В документации к Laravel рекомендуют запускать планировщик раз в минуту. Вы не замечаете тут проблемы?


Проблема в том что приложение будет дергаться каждую минуту, хотя задачу возможно нужно выполнять раз в месяц или каждую третью неделю. И сколько в этом случае обращений к приложению будет идти в холостую?


Еще cron запускает процессы параллельно и fatal error в одной задаче никак не повлияет на другие. Возможно конечно Sheduler в Laravel как-то это учитывает, но не на столько качественно как cron.


Если бы Sheduler был полноценной заменой крона, то это былоб хорошим решением для хостингов на которых нет cron, но это никак не core функция.

Неа, в 2.8 есть только аутентификация, надо ставить FOS поверх

вообще-то нет. Обычного form login хватает. Он есть из коробки уже хз сколько.

Хм, точно, походу с 2.7 воутеры появились, что-то с сглупил =)

Нет, даже раньше. Ну бывает. Можно вычеркнуть п.5 из списка

form login хватает для классики. для внешней авторизации (хавоть чужую куку или апи какое хитрое авторизовать) этого уже мало, Guard принес много радости детишкам по поводу этого вопроса

Не спорю.

свифтмейлер только в стандард, в самом фрейме нету:

эм… стандарт эдишен это и есть фреймворк. Для работы отдельных симфони компонентов оно не надо. А swiftmailer bundle в отдельном репозитории живет. Как никак это интеграция со сторонним сервисом. Точно так же как и Doctrine bundle.

эм… стандарт эдишен это и есть фреймворк.

Всегда считал, что это сборка (одна из). А сам фрейм — тут: https://github.com/symfony/symfony

технически standard edition — это готовое boilerplate приложение на основе symfony fullstack (symfony\symfony) и доп. либ. официальное, православное. а сам фрейм отдельно, как вы указали

Нет, там — только компоненты и куски из которых строятся фреймворки. Более того, вся философия симфони — вот вам сэт компонентов и делайте свои фреймворки. standard-edition это так сказать путь для ленивых. silex — пример что можно сделать свой фреймворк. Ну и т.д.

  1. Нет, сфитмейлер умеет спулить емейлы. Либо откладывать до terminate ядра (т.е. шлет после отправки ответа пользователю, завершая коннект), либо можно спул обрабатывать внешним потоком (кроном, например). По умолчанию спул в памяти, отправка по терминейт
  2. Деплой должен настраивать такие штуки. Потому что это вещи, зависящие от окружения. В ином окружении (дев, тест) у нас такие вещи отключены или поставлены на более щадящие таймеры. В препрод, прод — работают. В проекте есть отдельный конфиг для whenever (так сложилось), который при деплое развертывается в готовый крон файл, этим же CI\CD отключается при откате релиза и прочее. А как вы отключаете ваши кроны при откате релиза?
  3. Filesystem — это часть пакета symfony/symfony (есть по вашей ссылки). symfony/symfony заменает filesystem. Можно установить отдельным пакетом
  4. FoS UB, если вы про него — это готовые пользователи, которые надо отметить, опять же не всем подходят. У нас на всех проектах авторизация внешняя, юзеры вообще в битриксе живут (так сложилось). Авторизация работает, в том числе встроенная симфонёвая. Есть проект с FoS UB (точней там Sonata Admin, которая тянет FoS UB
  5. Ок, не сталкивался, видимо
  6. Да, потому что технически это такая же внешняя библиотека, как доктрина. Поэтому она идет изкоробки в standard (как доктрина), но это не часть проекта symfony. Сути ссылки я не понял. Вижу что можно все подключить модулями.
  7. Не только в доктрине, есть knp pagination bundle, довольно удобная штука, умеет пагинировать не только доктрину, а много разных источников
  8. Возможно, сам пользуюсь доктриновским

  1. Кажется вы не посмотрели что я имел ввиду под шедулером. В случае ларки — крон команда только одна на всё приложение и на RC\Stage и на проде. А шедулер уже сам разруливает что и как включать, раз в 10 минут или раз в год, включая окружение, исключение перекрытий (т.е. исключение дублирования запуска) и прочее-прочее.
  2. Я говорил про Flysystem, а не Filesystem. Например подключение Amazon S3 или какого-нибудь WebDav, который на том конце является каким-нибудь статик-сервером для аплоадов. Это тот самый момент, когда подобное решение "из коробки" позволит в будущем переключить драйвер одним кликом.
А шедулер уже сам разруливает что и как включать

Что будет если я допустим в scheduler записал выполнять скрипт раз в 3 минуты и внезапно скрипт начал выполняться 10 минут? Или в документации упущен момент с костылями аля flock?


Я говорил про Flysystem

который интегрируется в симфони с пол пинка а по дефолту если он часто надо — ну я например просто включил его в свой скелет проекта. Точно так же как кучу других вещей которые мне надо где-то в 2/3 проектов.


А вообще ждем symfony/flex.

Что будет если я допустим в scheduler записал выполнять скрипт раз в 3 минуты и внезапно скрипт начал выполняться 10 минут? Или в документации упущен момент с костылями аля flock?

Я могу дальше кидаться ссылками на документацию, но оно надо?

  1. Про крон команду с вами уже обсуждают в другом треде, не буду повторяться. Не считаю удобным дергать все ядро раз в минуту вне зависимости от того, должно что-то отрабатывать или нет. Есть консольные команды, которые можно запускать хоть руками, хоть кроном
  2. Сорян, замыленый глаз прочитал не так :) Есть подозрение, что готовых интеграций тоже хватает https://packagist.org/packages/oneup/flysystem-bundle. Про решение «изкоробки» уже обсуждали — зачем оно всем подряд? Например при работе с сервисной архитектурой все проекты подряд скорей всего не будут грузить файлы, а будет один сервис для этого

Я думаю, что не стоит утверждать, что два разных класса ФС в проекте — это плохо, и всегда лучше одно что-то. Всё это очевидно и симфони — хороший фрейм, я его люблю.


И подытожить хочется мыслью о том, что фреймы создавались для того, чтобы облегчить жизнь. И лара — как раз то решение, когда всё всегда есть под рукой и всё удобно. Т.к. в симфони довольно часто, после ларки, не покидает ощущение что изобретаешь велосипеды. Балует фрейм.

Я хаю потому, что нету интерфейса для добавления ХК.
Я даже не говорю, что он должен быть одинаков для всех фреймворков.

Сам шаблон ХК — дело десятое.
Вот в вопросе логирования пришли же к PSR-3.

Хотя, я как бы и соглашусь, что данное требование более из свойств CMS.
Ну и я, если честно, не люблю, когда фреймворк что-то навязывает, например использовать обертки для json_encode() или для вывода элементов форм.
Должен быть выбор, использовать предполагаемый фреймворком функционал или реализовывать свой.
При этом следует различать разовую разработку и серийную разработку.
В разовой разработке без использования «сторонних решений, которые добавляют ХК» требование наличия интерфейса ХК в ядре не нужно.
В серийной разработке, когда часто используются «сторонние решения, которые добавляют ХК», наличие интерфейса ХК в ядре необходимо.

Поэтому можно сделать такой вывод:
Фреймворк все же больше подходит для разовой разработки. Или серийной закрытой
CMS — для серийной открытой
Самопись может использоваться как для разовой разработки, так и для серийной закрытой

Хотя это все — вопрос личных предпочтений. :)
Префиксы в том же месте, где и роуты (не вынося в отдельный yaml)

Префиксы нужны для группировки роутов модулей. Роуты модуля, как правило, лежат в модуле и, соответственно в глобальном роуте мы подключаем их с нужным нам префиксом, как это обычно и бывает.


Одной строкой задекларировать полный CRUDС

Аналогично в Symfony. Но нормальные проекты не ограничиваются только CRUD-ом. А когда мы говорим о DDD, то CRUD, вообще перестает быть актуальным


вязать с рантаймом (например выгрузить из БД, бред конечно, но мало ли)

Это удар по производительности и нужно разьве что для CMS. В Symfony это тоже можно сделать, но зачем?


Объявлять паттерны для плейсхолдеров для всей группы (или вообще глобально)

Пожалуй согласен. В Symfony этого нет. Объявить регекспы один раз, а не в каждом роуте может быть удобно, хотя реализация в Laravel мне не нравится. Ну и можно вообще отказатся от регекспов, так как всё равно маппинг делается на сущность.


А можно связать плейсхолдер с любой сущностью (например выбрать из БД энтити, как в симфони в контроллерах)

Это ParamConvertor, о котором я уже говорил ранее. Он удобнее чем в Laravel


А ещё раньше можно было одной строкой замаппить все роуты на паблик методы контроллера (задепрекейтили в 5.1, вроде, и вырезали в 5.3)

И правильно сделали


И самое главное у роутов есть приоритет. Аннотациями приоритет не сделать, приходится гибрид фигачить.

  1. Приоритет определяется порядком определегия.
  2. А зачем вообще приоритет роутингов? Если роутинги могут конфдиктовать, то у вас серьезные проблему в проекте
А зачем вообще приоритет роутингов? Если роутинги могут конфдиктовать, то у вас серьезные проблему в проекте

Ну например на любой роут с методом OPTIONS стоит возвращать 200ый ответ, а на любой роут после всех — 404 с красивой картиночкой.


Это ParamConvertor, о котором я уже говорил ранее. Он удобнее чем в Laravel

Это не коробочный симфони, если не путаю, это SensioBundle или что-то такое.


По остальным пунктам — согласен. Всё это можно, но зачастую надо влезать во внутренности, что печалит.

Ну например на любой роут с методом OPTIONS стоит возвращать 200ый ответ, а на любой роут после всех — 404 с красивой картиночкой.

Это есть из коробки. Если роут не найден — 404. Страницу 404 можно кастомизировать. Все ответы по умолчанию отдают 200


Это не коробочный симфони, если не путаю, это SensioBundle или что-то такое.

Sensio входит в стандартную поставку Symfony. Ссылку вам давали выше.

Это есть из коробки. Если роут не найден — 404. Страницу 404 можно кастомизировать. Все ответы по умолчанию отдают 200

С 404 — это нормальный путь. Я просто привёл пример, когда приоритет важен. Могу ещё что-нибудь придумать, но надо ли? Идею я донёс.


Sensio входит в стандартную поставку Symfony. Ссылку вам давали выше.

А, ну да, я слепой, бывает =)

Преимещуство в скорости разработки и скорости работы.
Очень хотелось бы поменьше этих самописных фремворков, на основе которых обычно гавнокод.
Редко (скорее невозможно, не встречал, покажите) когда какая то команда способна написать нечто в общем «умнее» чем разрабы крупных фреймворков с огромным комунити.
Когда я получаю проект, я не жду от него вашего фундаментального кода. Он не интересен, уже достаточно увидел.
Я надеюсь получить нечто что написано пускай даже CI 2 версий. В нем будет большее мне знакомо, чем всякое написанное на отдельных компонентах Symfony какой то Петей из Комчатки.
Любите компоненты Symfony, пишите пожалуйста на нем или возьмите тот же Laravel.
Любите блестать умом показывая свое уникальное (никому не нужное) решение в виде своего фреймворка, идите в github.

Осуждать Yii, за то что на нем можно гавнокодить было бы ошибкой, т.к. это возможно в разной степени в любом фреймворке. Не думаю что это некий показатель.
Это хорошо, когда с разных частей приложения ты можешь достучаться до всего остального, некая фишка, лучше чем если бы этого не было, иначе осуждали бы а отсутствие этой фишки, почему бы и нет.
Сам пишу в основном на Yii2 чему очень рад и редко на Laravel.
Забавно, как бы популярны не были эти двое, я очень радуюсь когда получаю проект основанный именно на них.

По меньше «своего» фундаментального ребята, займитесь лучше бизнес логикой.
Вы, видимо, встречаете говнокод на самописи потому, что это в основном устаревший код :)
Используем в компании самописный фреймворк на многих проектах. Даже наверное это микро-фреймворк.
Мне нравится фреймворк в HostCMS
Интересно, что есть люди, которые минусовали опрос. Что тут могло не понравится? Сам факт опроса по php-фреймворкам?
Многим не нравится сам PHP.

Что характерно, в топики, скажем, по brainfuck* не набигают хейтеры brainfuck* и не требуют от всех считать этот язык воплощением зла и «фракталом плохого дизайна».

При этом я уже третий цикл подряд (средний цикл в IT — пять лет) наблюдаю, как очередной царь горы* пыхтит, тужится, разводит хайп и медленно умирает где-то в районе первого базового лагеря. Пока PHP сидит наверху и кидает камешки в пропасть.

* тут подставьте любой не-PHP язык, претендующий быть «убийцей»

Laravel — нравится архитектура, программирование через интерфейсы, IoC — близко, отличное сообщество, Eloquent \ artisan -вещи… после него даже Symfony показался корявым, была бы моя воля использовал бы везде, где нужен фреймворк.


В ближайшее время на работе скорее всего придется использовать допиленную версию Silex и думаю на долго.


Учитывая популярность Yii2 "у нас" очень сильно старался испытать, не зашло, раздражает подход, архитектура, практически все если честно. Возможно не с того начал и не разобрался, но как есть, в дальнейшем всячески планирую его избегать.

Положа руку на сердце, всё же AR у Yii 2 (главное сырцы не смотреть) местами лучше, нежели Eloquent. Да и сравнивать Symfony с Laravel стоит без учёта ORM. Всё же Doctrine местами даст фору Eloquent.


В остальном, да, как симфонист — соглашусь. Начиная с симфони 3.0+ очень много плюшек в симфони стянуты с лары, плюс в новой LTS версии (которая осенью выходит) обещают апнуть контейнер до возможностей Laravel. Так что вполне возможно сравняются.

Положа руку на сердце, eloquent приносит больше проблем чем пользы. Взять ту же невозможность использования композитных ключей и диктатуру тайлера.
По работе приходиться работать с laravel-ом, в личном проекте использую yii2. Плюс laravel, в том что построен на symfony. Но так же громадный минус в корявой работе с IDE из-за магии с факадами.
Но так же громадный минус в корявой работе с IDE из-за магии с факадами.

Вот это меня тоже очень сильно расстроило, особенно когда у тебя половина классов строится через class_alias.


Из неприятных первых ощущений стандартная страница ошибки которую нужно сразу выкидывать из заменять на Whoops.


P.S. Используем и поддерживаем несколько Laravel приложений.

Решение этой проблемы простое — не используйте фасады и всё.


*Ответ и вам и автору чуть выше

Как же это не использовать в легаси/чужом коде?)

рефакторинг?) Ну если у вас это создает проблемы то имеет смысл их решать. Хотя подозреваю что на подобных проектах есть проблемы посерьезнее.

В результате всплывает таже проблема что и в Yii. Когда сервис может использоваться в любой точке апликашки, а без толковой индексации для поиска всех use cases приходиться делать текстовой поиск по всей кодовой базе.
К конце концов позволяет наговнокодить нехуже чем другие «entry level» фреймворки.

Это как? Вот вы пишите:


class Some 
{
    public function __construct(MyService $s) { ... }
}

Почему этот сервис MyService так сложно найти?

Речь о ситуации когда факады применяются аля
Facade::doSomething(), в любом месте в коде.
IDE без хаков не понимает как нестатичный метод вызывается статически, в результате когда вам надо узнать где применяется метод doSomething, просто кликнув на Find Usages не выйдет. Приходится искать по всем файлам как строку doSomething()

Таких приколов в laravel-е можно избежать просто их не используя, но в таком случае встает вопрос, почему попросту не использовать сразу Symfony.

Yii2 многие ругают за то что из любого места в коде, будь то вьюха или контроллер есть доступ к апликахе в целом через Yii::$app, но имхо использование факадов в ларе тоже самое, только в профиль.

Сужу об этом исключительно после опыта работу с Zend 2, Laravel 4, Yii1/2.

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

Ну так L4 и L5 совершенно разные фреймворки, в L4 без фасадов вообще почти ничего нельзя.

Взять ту же невозможность использования композитных ключей
Забавно. В doctrine best practices Марко пишет: «Avoid composite primary keys».
Any reason to not use an unique constraint instead?
Do they make a difference in your domain?
В pivot таблицах получается необходима лишняя колонка только для того чтобы это все работало без костылей.

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

В коде еще хуже)

И продвигаю, и предлагаю, а ещё работаю и развиваю начиная с 2005 года.
И всё это, обратите внимание, совершенно бесплатно.
Ммм, slaed только недавно стал бесплатным. И еще свежи в памяти ваши бекдоры раскиданные по исходникам, которые отправляли все данные админа сайта вам на почту.
Вы немного неправильно проинформированы. SLAED всегда был бесплатным. Даже когда появилась платная версия, параллельно с ней выпускалась бесплатная.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории