Задать вопрос
@romicohen
Системный Архитектор

Что принципиально отличает Symfony 5 от Laravel 8?

Меня тут искушают проектом на Symfony, но я в сомнениях. Дело в том, что я уже делал простенькие API на Symfony, и каких-то особых отличий от Laravel на этом уровне не заметил.

Но что будет, если копнуть глубже?

Есть ли что-то такое, что прям вот отличается-отличается?

//немного разверну: Doctrine - это тот же Eloquent, только в профиль. Ну, сеттеры-геттеры приходится эти писать, но это пережить можно, ну, роуты в пхпдок - тоже забавненько так. Но это всё не принципиальное, а есть ли что-то такое, что сильно прям отличается, и на что ларавельщику надо обратить особое внимание?
  • Вопрос задан
  • 1324 просмотра
Подписаться 3 Простой 6 комментариев
Решения вопроса 2
myks92
@myks92
Нашёл решение — пометь вопрос ответом!
  1. Прежде всего нужно понимать, что любой Framework, в руках хорошего разработчика будет жить долго и хорошо.
  2. Framework — это инфраструктура. Framework не предоставляет Вам готовый код и не задаёт архитектуру, он предоставляет Вам низкоуровневые инструменты или их быструю интеграцию, в которых нет необходимости писать с нуля под каждый проект. Хотя, ради практики, было бы не плохо попробовать это сделать, чтобы разобраться в данном вопросе, но сейчас не об этом. Исходя из этого Ваш код должен быть независим от какого-либо Фреймворка. Устарел Yii2 framework —поменяли контроллеры, немного инфраструктуры и код работает уже на Symfony или Laravel. Это касается не только Фреймворков, любая сторонняя библиотека должна быть изолирована от прямого использования. Это позволит Вам быть более гибче и сделает Ваш код менее связанным и зависимым.
  3. Оба Фреймворка популярны и имеют право на существование. У всех разный порог входа, разное сообщество и разные решения. На Symfony код пишется чуть сложнее и дольше, так как нет привычных фасадов. Многие компоненты и Фреймворки используют компоненты Symfony в виде своих обёрток. Однако, нужно понимать, что Фреймворк задаёт немного стиля в разработке, у Symfony этот стиль более правильный и строгий. Поэтому, использование Symfony интуитивно подталкивает Вас к написанию более чистого кода, без погружения в различные паттерны.
  4. Doctrine — это НЕ тот же Eloquent. Это совершенно разные вещи!
    Eloquent —это анти паттерн Active Record, а Doctrine это паттерн Data Mapper. Если речь идёт о быстрой разработке и не долгоживущем или небольшом проекте, то можно взять и её, однако на долгий срок лучше использовать Data Maper типа Doctrine, Cycle. При таком подходе ваши поля «не торчат» напрямую из базы данных в код. При изменении столбца в БД — его не придётся менять по всему проекту. Для Data Mapper подход — Code First (Вначале код), а для Active Record — Table Fist (Вначале таблицы). При использовании Data Mapper мы не думаем как будут храниться наши данные в БД, не думаем какая будет БД, что не скажешь по AR.

Тема фреймворков на Q&A поднимается очень часто. Лично мне приходилось много раз отвечать на подобные вопросы. Вы можете сами в этом убедится по моим ответам:

Поэтому, серьёзно к таким вопросам здесь не относятся. Чтобы понять разницу — Вам, очевидно, нужно попробовать оба Фреймворка в разных ситуациях. Со временем Вы сами всё поймете. А если Вас устраивает Laravel и не предвидится какого-то большого развития — пользуйтесь. Пару строк кода можно написать и без какого-либо Фреймворка. Главное — результат и правильно подобранный инструмент.
Ответ написан
@galliard
1. IDE понимает Symfony без дополнительных плагинов, на Laravel без плагинов писать не удобно.
2. Вам придется повсеместно использовать внедрение зависимостей через конструктор. Вы это и в Laravel могли делать, но там и другие варианты были (фасады, app('service_name')). В Symfony только DI и только через конструктор.
3. В Symfony вам придется пробрасывать данные к месту использования через аргументы. В Laravel вы могли достучаться до любого компонента при помощи статических фасадов и функций, вызвав их в любом произвольном месте, например могли вызвать request() где-то в модельке. В Symfony нужно будет пробросить данные запроса из контроллера через аргументы по всему стеку вызовов.
4. В Symfony вы перестанете наследовать свои классы от классов Symfony (за рядом исключений).
5. Конфиги вы будите писать в yaml (в этом есть плюсы и минусы)
6. В Symfony нет middleware (возможно есть какие-то сторонние пакеты, которые их реализуют, но обычно такой подход при разработки на Symfony не применяется)
7. В Symfony вы перестанtте манипулировать айдишниками и начнете манипулировать сущностями. То есть код $order->user_id = $user->id; превратится в $order->setUser($user);
8. Больше не надо писать миграции вручную, доктрина автоматически их сгенерирует.

Ну это то, что вспомнил, так то отличий может и больше будет.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы