Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Отзывы о PHP фреймворке Symfony

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

привет всем пхпщникам...

я работал со многими фреймворками.

Symfony позиционируют как лучший.

хотелось бы почитать реальные отзывы.....

я лично считаю Symfony худщим фреймворком, хотя бы по

1. временя разработки на нем дольше, чем на любом другом фреймворке

2. сложность выше любого другого фреймворка

3. Symfony «склепали» из других библиотек , типа Doctrina и др и поэтому настроек там полно и в разных местах (не в одном месте)

4. что добавить, к примеру, одно поле в таблицу, редактировать нужно аж в 3-5 местах

и т д

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Якось я Symfony палкою здалеку ковиряв, але теж не зайшов мені. Добре, що я десь у 2014 році зіскочив зі стеку PHP (Kohana, CodeIgniter, Pimple, Slim) на JavaScript (AngularJS), а десь через рік вже на TypeScript (Angular).

Щоправда на фронті трохи менше програмування, бо є HTML та CSS, але якщо йти на проекти, де у команді є верстальник, то можна й не побачити цього мінуса.

Ну і бекенд, на даний момент, вже на повну пишеться на TypeScript. PHP-фреймворк у багатопоточному режимі може обігнати NodeJS-фреймворк, але це стосується бенчмарка «Hello, World!». А якщо говорити за реальні проекти середнього чи великого розміру (для яких якраз і призначений Symfony), то тут вже мабуть жоден PHP-фреймворк і близько не буде таким же швидким як NodeJS-фреймворк, особливо якщо він написаний на TypeScript. Усе через те, що NodeJS-фреймворки на великих проектах можуть важку ініціалізацію робити один єдиний раз на старті, після чого будуть затрачати ресурси тільки на роботу в контексті конкретного запиту. Ну а TypeScript зменшить кількість помилок в рази, порівняно із JavaScript.

NodeJS так же имеет свои минусы. и ее сейчас переписали и развивают какой то новый аналогичный проект Deno

До речі, ось я робив якраз бенчмарк із «Hello, World!» PHP 7 vs. Node.js 4.4.7

Згоден, але сумніваюсь що особливо щось змінилось. Мабуть як і раніше PHP-фреймворки програватимуть NodeJS-фреймворкам у випадку бенчмарка із «Hello, World!» без конкурентних запитів, і деякі із PHP-фреймворків виграватимуть коли є конкуренція між запитами хоча б у десяток штук.

Така ж сама картина, як і раніше, залишилась і для великих проектів. Сумніваюсь що PHP-фреймворки можуть хоча б наблизитись до NodeJS-фреймворків по швидкості обробки запитів, навіть коли є конкурентні запити.

Те, що розробник ExpressJS розлюбив NodeJS і хоче більше працювати із GO, то його особиста справа. Тим більше він це усе писав до виходу ES2015, а це дуже суттєвий факт (нагадаю — тоді ще навіть промісів не було, і був актуальним колбек хел).

Ви читали цю статтю? Я її колись читав. По-моєму, тут якраз піддають сумніву те негативне, про що говорив перший розробник NodeJS, критикують його теперішнє творіння Deno...

Перечитайте ту статтю, що ви у попередньому коменті давали. Там хоча й признають мінуси NodeJS, але кажуть, що у неї більше плюсів, ніж мінусів, і початковий розробник NodeJS захотів хайпа для Deno, критикує NodeJS, але йому нічим крити...

Symfony позиционируют как лучший.

Симфони не самый лучший, а самый нафаршированный / навороченный / мудреный (нужное подчеркнуть).

Ну вообще да, Zend соревнуется (наверное) в этом с Симфони. :-)

Могу даже спойлер сказать, всё равно не поверишь: Symfony худший фреймворк потому что он на PHP. У пэхи своя ниша, достаточно широкая, но не пытайся делать из велорикши лимузин. Максимум что получится — собачья упряжка, да и та со слоном.

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

Симфони — довольно громоздкий фреймворк для разработки энтерпрайз-приложений со сложной обширной логикой. Есть множество модулей довольно высокого качества для решения самых разных задач и построения элементов архитектуры приложения, ORM, queues, mailing, cache, ... — packagist.org/packages/symfony. Много «абстракций над абстракциями», ООП в полную мощь.

1. временя разработки на нем дольше, чем на любом другом фреймворке

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

2. сложность выше любого другого фреймворка

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

3. Symfony «склепали» из других библиотек , типа Doctrina и др и поэтому настроек там полно и в разных местах (не в одном месте)

практически любой современный фреймворк — это набор компонентов: MVC, routing, view layer, DB-layer, .... — возиться с настройками можно долго, да, зато можно сконфигуриррвать практически все, что угодно, заменить компоненты при необходимости, или расширить их

4. что добавить, к примеру, одно поле в таблицу, редактировать нужно аж в 3-5 местах

Ну 3 еще может быть, а 5 раз куда его там добавлять то?
в миграцию, в entity, все остальное — это логика приложения уже как-бы, а не symfony.
Но вообще проблема понятна, излишняя громоздкость, в принципе Doctrine ORM использовать необязательно, хотя я еще и не видел Symfony-проектов без него, но можно посмотреть в сторону propel — github.com/propelorm/Propel2 (есть бандл для симофни — packagist.org/packages/propel/propel), по отзывам значительно легковеснее и хорошо интегрируется.

PS скорее всего, проекты просто не того объема и/или сложности, на которых будут видны преимущества symfony, имеет смысл взглянуть в сторону Laravel

а в чем «облегчение» для сложных проектов? какие преимущества он дает?

Ну тут нельзя сказать, преимущества: 1, 2, 3, ... используйте все симфони, иначе было бы всего полтора MVC-фреймворка и все его и так бы использовали. Тут скорее надо пару проектов крупных реализовать на симфони и на чем-то другом и это прочувствовать.

Я бы сказал так в общих чертах: количество качественных бандлов с хорошей документацией для самых разных задач с широкими возможностями конфигурации, смотрим например
— symfony.com/...​oc/current/messenger.html — сколько транспортов поддерживается (есть ли еще где-то Amazon SQS например, для ларавел нашел только 3rd-party решение), каковы возможности их конфигурации, каковы возможности расширения, как это все задокументировано
— аналогично по работе с почтой symfony.com/doc/current/mailer.html
— аналогично кеш — symfony.com/...​ent/components/cache.html, там абстракция на абстрации везде, для небольшого приложения — это ненужная громоздкость, для большого и сложного — возможно адаптировать все под свои нужды расширив логику
— есть пуш из коробки — symfony.com/...​al-time-push-capabilities (пока экспериментальный как я понял)
— та же самая доктрина — есть оптимистическая блокировка из коробки (только добавить колонку в таблицу надо) — www.doctrine-project.org/...​ions-and-concurrency.html (для ларавел нашел опять же только 3rd-party решение)

Практический пример: в моем проекте для смены логики статуса заказов используется — symfony.com/...​/components/workflow.html. Понятно, что в каждом отдельном случае можно найти и интегрировать 3rd-party решени или написать свое. Но потом процесс может дойти до того, что: нужна эта штука — ух ты есть в симфони, берем оттуда, нужна штука 2 — ух ты есть в симфони, берем оттуда, нужна штука 3 ... может в след раз на симфони вообще будем писать. Кстати таким путем пошли в ларавеле, там куча компонентов из симфони.

ЗЫ я не рекламирую симфони вообще ни разу если что, для среднего пхп-приложения он слишком громоздкий

т е симфони нравится потому что много

бандлов

?
все эти бандлы базтруются на каких то библиотеках,
которые можно интегрировать БОЛЕЕ гибко почти в Любой фреймворк

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

все эти бандлы базтруются на каких то библиотеках,
которые можно интегрировать БОЛЕЕ гибко почти в Любой фреймворк

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

фреймворк не должен содержать все. фреймворк дает РАМКИ для создания приложния.
если в нем есть все, то мне кажется это минус.

фреймворк самое главное должен давать скорость
в разработке и поддержке.

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

Описанное ниже мое субъективное мнение. На истину последней инстанции не претендую.

Мне кажется(крестится не буду ибо атеист я), вы несколько заблуждаетесь:

фреймворк дает РАМКИ для создания приложния

Фреймворк это набор инструментов. Соответственно, он должен давать не рамки, а возможности.

если в нем есть все, то мне кажется это минус.

Да, для symfony есть много разных компонентов. И это не минус, а скорее плюс. Т.к. для типовых задач вам при использовании Symfony не придется искать готовый пакет либо городить свой велосипед если не найдете готовый т.к. уже есть готовый гибкий компонент с подробной документацией который можно настраивать 1001 способами и при необходимости расширить.

Тем более, что изначально Вы можете поставить только скелет приложения(в котором будут инструменты для минимального MVC и не более) и дальше доставить нужные компоненты. Что конечно дольше чем просто поставить дэфолтный шаблон иного фреймворка с прибитой гвоздями кучей пакетов часть которых Вам может и не понадобится. Но просто выпилить лишний код из проекта может оказаться затруднительно/невозможно.

Что же до громоздкости и скорости разработки, то как уже было прокомментировано выше

хороший для одних задач, для других — не очень

Как и любой другой фреймворк/ЯП/СУБД/прочие инструменты — хороши для решения конкретных задач. В случае symfony — это большие громоздкие проекты. Если Ваш проект не из таких — symfony Вам, вероятнее всего, не нужен.

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

насчет этих бандлов.
в большинсве случаях геммор еще то
к примеру
TimestampableEntity
это просто дабавить строчку created = time()
и никого головняка с совместимостью версий

сейчас переношу Knp\DoctrineBehaviors\Translatable с 4.3 на симфони 5.2
это вообще тихий ужас

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

1. Які це «інші». Наскільки довше?
2. Для якого рівня знань?
3. Інші фрейми все зробили з 0? Для чого?
4. ? stackoverflow.com/...​xisting-entity-in-symfony

А шё вы про Yii2 скажите? Он вроде как использует готовые модули симфони.

Yii2

 а также Yii3 считаю не плохими фреймворками.
они ускоряют разработку и для большинства проектов подходят.
хотя я больше фанат CI 4
то что они используют какие то модули от

симфони

не говорит о том, что симфони как фреймворк хорош)))

есть такая статья «Симфония самоподдува»

цитирую оттуда

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

Yii3 уже релизнулся? Его уже юзают на продакшене...

Крайне далек, но

2. сложность выше любого другого фреймворка

Один плюс как минимум он заслуживает.

ну тогда нужно веб приложение на ассемблере делать, что б ," кайфануть" от сложности по полной))))

Кстати да — кто на ассемблере не писал, тот и не кайфовал.

Ща вроде на асамблере не пишут, кроме тех дедов с нашего универа! Зачем? Ведь можно делать с цешки ассамблерные вставки. Вообще если по-современному разговаривать, и очень хочется то есть веб ассамлер. filename.wasm

Для полного кайфа на Brainf*ck’е надо. :-)))

Підписатись на коментарі