Что принципиально отличает Symfony 5 от Laravel 8?
Меня тут искушают проектом на Symfony, но я в сомнениях. Дело в том, что я уже делал простенькие API на Symfony, и каких-то особых отличий от Laravel на этом уровне не заметил.
Но что будет, если копнуть глубже?
Есть ли что-то такое, что прям вот отличается-отличается?
//немного разверну: Doctrine - это тот же Eloquent, только в профиль. Ну, сеттеры-геттеры приходится эти писать, но это пережить можно, ну, роуты в пхпдок - тоже забавненько так. Но это всё не принципиальное, а есть ли что-то такое, что сильно прям отличается, и на что ларавельщику надо обратить особое внимание?
Да какая разница где писать говнокод? Фреймворк не фреймворк симфони не симфони, все равно ни тот ни этот не используется. Стандартная практика многих пхп программистов - как изначально научился на ванильном пхп клепать, так и продолжил на фреймворке. А ларавел там не ларавел без разницы. Что там надо выучить? роуты и запросы. потом писать на Тостере о сложностях проектирования в больших проектах (там где 5 страниц методы в контроллере)
Прежде всего нужно понимать, что любой Framework, в руках хорошего разработчика будет жить долго и хорошо.
Framework — это инфраструктура. Framework не предоставляет Вам готовый код и не задаёт архитектуру, он предоставляет Вам низкоуровневые инструменты или их быструю интеграцию, в которых нет необходимости писать с нуля под каждый проект. Хотя, ради практики, было бы не плохо попробовать это сделать, чтобы разобраться в данном вопросе, но сейчас не об этом. Исходя из этого Ваш код должен быть независим от какого-либо Фреймворка. Устарел Yii2 framework —поменяли контроллеры, немного инфраструктуры и код работает уже на Symfony или Laravel. Это касается не только Фреймворков, любая сторонняя библиотека должна быть изолирована от прямого использования. Это позволит Вам быть более гибче и сделает Ваш код менее связанным и зависимым.
Оба Фреймворка популярны и имеют право на существование. У всех разный порог входа, разное сообщество и разные решения. На Symfony код пишется чуть сложнее и дольше, так как нет привычных фасадов. Многие компоненты и Фреймворки используют компоненты Symfony в виде своих обёрток. Однако, нужно понимать, что Фреймворк задаёт немного стиля в разработке, у Symfony этот стиль более правильный и строгий. Поэтому, использование Symfony интуитивно подталкивает Вас к написанию более чистого кода, без погружения в различные паттерны.
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 и не предвидится какого-то большого развития — пользуйтесь. Пару строк кода можно написать и без какого-либо Фреймворка. Главное — результат и правильно подобранный инструмент.
Ну, значит, я чего-то там с Doctrine недопонял)) что в общем, не удивительно - я просто клал данные в таблицы и доставал их оттуда)) и простые отношения, без всяких полиморфных наворотов))
Ну, значит, я чего-то там с Doctrine недопонял)) что в общем, не удивительно - я просто клал данные в таблицы и доставал их оттуда)) и простые отношения, без всяких полиморфных наворотов))
значит у Вас были простенькие проекты, в которых было мало бизнес-логики, мало изменений, разделений, рефакторинга. Любое изменение нейминга будет для вас мучительным. Любой инструмент надо подбирать под задачи. Если Вас это устраивает, то используйте это. Да хоть вообще на прямых подключениях через mysqli без всяких фреймворков.
Максим, не надо меня грузить)) эдак можно договориться до того, что никаких фреймворков вообще нет, а есть лишь один Composer, великий и ужасный)) На самом деле у каждого фреймворка есть специфические черты, и мой вопрос как раз об этом. Что там такое есть в Symfony, на что придется потратить время, чтобы въехать в суть вопроса?
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. Больше не надо писать миграции вручную, доктрина автоматически их сгенерирует.
Ну это то, что вспомнил, так то отличий может и больше будет.
