Комментарии 19
Я все пхп фреймворки конечно не перепробовал, но аналогично что бы не попробовал, сразу вспоминаю симфони, она всегда чемто лучше.
Мне все эти фреймворки напомнают починку кареты в "формуле любви" - За день справитесь? - конечно, а за три?- попробуем, а за неделю?- ну барин ты задачи ставишь, а за месяц? - нет барин, тут одному не справится, тут помшник нужен! Так вот все эти джанги и симфонии напоминают мне тех самых помошников с помощью которых можно плевую работу которая пишется за пару дней растянуть на месяцы и задействовать вместо "одного землекопа" большой коллектив бездельников. Очень жаль что вменяемые фреймворки и технологии заменяются полурабочими монстрами написание на которых "hello world" требует немалой квалификации, 1000 строк кода и коллектива "специалистов" ...
Нет, не работал. Но у меня 30 лет стажа в it. Веб это не моя основная специализация, но делал несколько веб проектов, больше всего мне нравится codeigniter, он реально упрощает работу а не усложняет. Конкретно Symfony не изучал, но недавно пришлось сталкнуться с джангой и я просто обалдел)! Ни чего ужаснее я за 30 лет не видел. А этот пост был просто по ассоциации, подозреваю что это что то "из той же оперы")))
Вообще буквально пару лет назад (раньше такого не было) начал сталкиватся с тем что появляется много громозких и сложных утилит/фреймворков/сервисов для решения каких то элементарных задач, при этом они не упрощают а мнокократно усложняют решение этих задач. Это какя то свежая, пока не понятная мне тенденция.
codeigniter подходит для простых проектов. В этом его плюс, легко, быстро, но в этом и минус. Когда вам нужен большой проект, то нужен и фреймворк, который уже из-под коробки имеет много всего.
Я работал с обеими фреймворками, и мне нравятся оба.
Это как велосипед/мотоцикл и машина.
Я вот с джангой не работал. Зато работал с симфони, немного щупал codeigniter
codeigniter - там просто минимум всего, для простых задач наверно неплох.
На Симфони простые задачи решать, типа сайта визитки, или стандартных интернет магазинов, без каких-то кастомных переделок - действительно как в примере из фильма. А вот если придётся делать проект посложнее - то симфони уже очень не хватает. Особенно при разработке в команде. Причём последние версии симфони стали более модульными и отдельные модули из неё тащат в кучу разных фреймворков. Т.е. совсем не редкость взять какой-то самописанный проект сложный, покопаться в вендоре и найти кучу библиотек из симфони.
Подскажите, а если в статье Symfony заменить на любой другой фреймворк - чтото изменится?
Как я понял - в статье указаны именно плюсы использования фреймворков вцелом, на любом стеке.
И да. Я работал с почти всеми версиями yii, zend, symfony, laravel, onphp + drupal и другие cms.
На данный момент остановился на laravel. Хотя недавно работал на symfony, а до этого на yii. И мое мнение - все фреймворки плюс-минус одинаковые. Считаю, что надо выбирать по популярности (где больше сообщество). Все остальные "плюсы" - надуманы.
Честно, не убедительные доводы. Зашёл почитать ну какую-то конкретику, вроде удобства перегрузки классов ядра.. Вместо этого пишут про репутацию и стоимость.
У меня не было много опыта в Symfony, но мне показалось что этот инструмент сильно раздут, для большинства проектов он не очень подходит. Нет какого то мифического удобства в сравнении с той же Laravel, там более лаконичный синтаксис.
Не нравится в Symfony передача зависимостей через конструктор. Почему-то вообще не заходит и этот код кажется в классе лишним.
Помню там ещё была какая-то сложная валидация и мутная doctrine, но может быть она и неплоха, не сильно знаком со всеми фишечками.
Symfony можно описать как фреймворк монолитов. Из плюсов можно выделить компонентную основу. Благодаря ей компоненты можно использовать в других фреймворках, иногда это требует написание специфических адаптеров.
Я не знаю как в ларавеое но передача через конструктор позволяет симфони определить неиспользуемые сервисы и не включать их в финальный DI контейнер, что существенно ускоряет загрузку кода. Да и это просто удобно. Нужен сервис, добавил его в конструктор и все
Более правильным подходом кажется создание объектов в местах их использования.
в Laravel это делается например так:
$object = app(class);У вас может бытб очень много сервисов, но по факту к примеру вы используете лишь треть. Симфони может определить на этапе компиляции контейнера, какие сервисы реально используются, а какие нет. И удалить из контейнера неиспользуемые сервисы и их импорты
В конструкторе прописаны зависимости, как параметры. Когда создаётся объект, подразумевается, что параметры должны быть заданы.
Не помню точно, как в Symfony реализация, но если взять для примера Magento 2 (там тоже передача зависимостей через конструктор), то там происходит генерация параметров конструктора и подстановка в вызов. И даже если параметры потом ансетить, это всё равно лишние операции, лишняя логика.
Как нибудь будет время посмотрю подробнее этот процесс, но пока моё мнение, что в симфони это решение порочно.
Даже если там всё происходит через перегенерацию кода класса, то система никак без полной интерпретации логики не поймёт, нужна ли мне заполненная зависимость в параметре конструктора, или нет.
Также параметр зависимости в конструкторе подразумевает какое-то хранение в свойствах класса и тут ты опять получаем лишний код.
В нормальной системе, в параметрах конструктора, только то, что нужно именно в конструкторе объекта.
В общем как ни крути, а преимуществ этому не вижу.
Использование сервис локатора в методах класса - плохая практика, нарушающая инкапсуляцию. В таком виде сервис локатор является антипаттерном, скрывающим предусловия для корректного использования объекта. Это плохая архитектура и куча проблем на серьезном проекте, выходящего за рамки "накидать крудов".
Все фабрики генерируемых классов, различные мидлвэры прописываются в конфигах, а сервис локатор последовательно использует эти настройки при генерации объекта.
Если делать объекты через new, то это засоряет код, а если кода много, то становится максимально неудобно.
Также если вам потребовалась для обработки гора параметров в классе, то это уже невалидный код и так писать не надо. Логику обработок можно раскидать по тем же мидлверам/фабрикам. Действуя принципам SOLID 1 класс 1 задача, что по итогу будет класс оперирующий высокоуровневой логикой.
Параметры в конструкторе класса на этом фоне выглядят мягко-говоря лишними, только добавляющими сложности при создании объекта.
Если нужны параметры, используйте сеттеры и валидаторы.
Что значит кто мне сказал? Вы в методе своего класса используете неявную зависимость от черт пойми чего, какие конфиги, какие мидлвэры? Почитайте про solid, почитайте про явное определение зависимостей. Ваш класс должен иметь возможность быть созданным через new InstanceName() и явно давать понять что ему нужно для корректной работы. Без конфигов, без контейнеров. Вы же предполагаете наличие какого-то глобального объекта, который вернет какую-то зависимость, это нарушение инкапсуляции. В Ларке это допускается только потому, что по словам самого её создателя она нужна чтобы крудов быстро накидать. В нормальном приложении вы от этой лапши с ума сойдете, полностью потеряв границы ответственности программных модулей.
Поддержу. Тоже Symfony близок чем-то, что заставляет возвращаться к нему.
Порог входа у него выше, чем у laravel, из-за чего большинство оседают именно на laravel.
Но архитектурно он лучше и чище - в laravel много костылей, и это отталкивает. И документация на symfony очень подробная - с ней можно всё быстро освоить. Но необходимость копаться в ней отталкивает многих. Собственно только за счёт этого и выше порог входа: после чтения документации почти все вопросы исчезают.
Что замечательно - большинство компонентов работают независимо друг от друга, что позволяет собирать свои фреймворки или приложения из тех модулей, какие больше нравятся. Но в конце концов понимаешь, что всё это по факту выходят велосипеды, которые мало в чем выигрывают у symfony, но требуют поддержки, так что в конце концов приходишь к чистому symfony. Как уже было сказано, symfony это не только фреймворк, но и целая экосистема, которую поддерживает сообщество, и в которой всё согласовано друг с другом - самостоятельно такое повторять просто непродуктивно.
По производительности выходит всё не так красиво, как хотелось бы, такова цена функционала. Но у конкурентов ситуация ещё хуже. К тому же на symfony всё кешировано, а с кешами производительность сравнима с самыми быстрыми реализациями.
Но есть момент с ORM. ORM на symfony одна из самых совершенных, но и за ней нужно следить - хоть она и работает лучше конкурентов, но всё же многие вещи она не способна оптимизировать, и гонит избыточные запросы. Это общая особенность ORM систем, и с этим мало что можно сделать - ORM не способны понимать кейс, в котором используются запросы, поэтому и не способны оптимизировать обращения к БД, без дополнительных инструкций от программиста. Впрочем это настраивается один раз на каждый запрос, и потом всё работает как часы. Да и профилировщик встроен - можно посмотреть как текущий хит, так и предыдущие: какие компоненты работали, сколько, какое потребление памяти, какие запросы к БД выполнялись, и многое другое.
И ещё одна удобная фишка - консольные команды. С их помощью удобно автоматизировать развертывание и управление приложением, а также с их помощью генерируется почти весь каркас приложения.
Из последнего, что делал на symfony - rest-api со всеми вспомогательными сервисами и наворотами. По времени вышло намного быстрее, чем если бы делал вручную. Очень выручило, т.к. бюджет времени был сильно ограничен. В итоге получилась красивая конфетка, которую было не стыдно презентовать, что позволило в конкурсе выделиться на фоне самодельных решений и получить солидный профит.
Хороший даунгрейд со спринга на симфони.
Главные причины, почему мы разрабатываем веб-приложения на Symfony