ⓐ
Size: a a a
2021 February 11
VK
скорее в одинок русле нехорошо обсуждать вопросы определенных клиентов, в целом можно посмеяться но называя по имени для меня это недопустимо
почему?
VK
ну то есть почему нормально в мире обсуждают собесы как проводит гугл и все плохие и хорошие нюансы, а какую-то дыру низя ?
VK
условно люди будут знать что идти не стоит
DT
куда катится мир, если топовая компания в блокчейне спрашивает чем симфони от воравеля отличается
SP
куда катится мир, если топовая компания в блокчейне спрашивает чем симфони от воравеля отличается
лэндинги для топовой компании тоже кто-то должен делать
SP
зачем для этого пых и симфони - не понятно
DT
суешь руку в котел с фрилансерами
DT
какого достал тот и делает ленд
SP
достаешь оттуда "сделаю на симфони сделаю на ларавель" и оттуда дают такие вот тупые задачи. сделать сравнение)
VK
достаешь оттуда "сделаю на симфони сделаю на ларавель" и оттуда дают такие вот тупые задачи. сделать сравнение)
аахахахах
VK
вместо того чтобы найти того, кто сделает на wix или tilda
VK
или достаешь такого ,а он гвоорити могу wix и tilda, а потом справшиваешь в чем разница
VK
и он идет в чат делать исследование
VK
говорит "все они имплементят интерфейс бравузера"
i
Всем привет! провожу небольшое исследование на тему сравнения Symfony/Laravel
В чем для вас основное отличие этих двух систем?
Для себя я отметил следующее, но оно явно не полное.
1. Eloquent и Doctrine - оба ORM. Оба реализуют паттерн Fluent Interface.
Eloquent возвращает коллекцию объектов класса Test
Doctrine массив объектов класса Test
2. Миграции и ORM
В Laravel мы вынуждены создавать миграции сами и следить за синхронизацией структуры БД и PHP-классов
В Symfony же работа с миграциями осуществляется через Doctrine ORM. Здесь мы можем работать только с PHP-классами и аннотациями.
3. Шаблонизаторы
Symfony работает с Twig. Laravel - с Blade
В чем для вас основное отличие этих двух систем?
Для себя я отметил следующее, но оно явно не полное.
1. Eloquent и Doctrine - оба ORM. Оба реализуют паттерн Fluent Interface.
Eloquent возвращает коллекцию объектов класса Test
Doctrine массив объектов класса Test
2. Миграции и ORM
В Laravel мы вынуждены создавать миграции сами и следить за синхронизацией структуры БД и PHP-классов
В Symfony же работа с миграциями осуществляется через Doctrine ORM. Здесь мы можем работать только с PHP-классами и аннотациями.
3. Шаблонизаторы
Symfony работает с Twig. Laravel - с Blade
По моему субъективному опыту:
1) В Laravel сложнее интегрировать сторонние решения, например доктрину. Потому что многие фичи фреймворка завязаны на его коробочный стэк (сиды и апи-ресурсы могут много "веселого" доставить, если юзать их с доктриной)
2) В Laravel менее гибкий сервис-контейнер (сильно не понравилось отсутствие _instanceof, а так же не хватает функционала для ручной фильтрации сервисов), хоть и со своими фишками вроде contextual binding
3) Оба фреймворка RAD, но laravel чуть больше, т.к. в тех же форм-реквестах или апи-ресурсах многое доступно из коробки (из-за этого в фреймворке овердофига наследования и куча неиспользуемого функционала инициализируется, хотя это скорее экономия на спичках). Кроме того, в ларавеле дофига функционала связано, что является тоже и минусом и плюсом (те же апи-ресурсы дружат с элоквент-моделями и могут всякое-разное)
4) В ларавеле есть еб*чие фасады (и если сам ты их можешь не юзать, то вот стандартных там дофига, и не все додумываются конкретный инстанс юзать вместо фасада)
1) В Laravel сложнее интегрировать сторонние решения, например доктрину. Потому что многие фичи фреймворка завязаны на его коробочный стэк (сиды и апи-ресурсы могут много "веселого" доставить, если юзать их с доктриной)
2) В Laravel менее гибкий сервис-контейнер (сильно не понравилось отсутствие _instanceof, а так же не хватает функционала для ручной фильтрации сервисов), хоть и со своими фишками вроде contextual binding
3) Оба фреймворка RAD, но laravel чуть больше, т.к. в тех же форм-реквестах или апи-ресурсах многое доступно из коробки (из-за этого в фреймворке овердофига наследования и куча неиспользуемого функционала инициализируется, хотя это скорее экономия на спичках). Кроме того, в ларавеле дофига функционала связано, что является тоже и минусом и плюсом (те же апи-ресурсы дружат с элоквент-моделями и могут всякое-разное)
4) В ларавеле есть еб*чие фасады (и если сам ты их можешь не юзать, то вот стандартных там дофига, и не все додумываются конкретный инстанс юзать вместо фасада)
ⓐ
По моему субъективному опыту:
1) В Laravel сложнее интегрировать сторонние решения, например доктрину. Потому что многие фичи фреймворка завязаны на его коробочный стэк (сиды и апи-ресурсы могут много "веселого" доставить, если юзать их с доктриной)
2) В Laravel менее гибкий сервис-контейнер (сильно не понравилось отсутствие _instanceof, а так же не хватает функционала для ручной фильтрации сервисов), хоть и со своими фишками вроде contextual binding
3) Оба фреймворка RAD, но laravel чуть больше, т.к. в тех же форм-реквестах или апи-ресурсах многое доступно из коробки (из-за этого в фреймворке овердофига наследования и куча неиспользуемого функционала инициализируется, хотя это скорее экономия на спичках). Кроме того, в ларавеле дофига функционала связано, что является тоже и минусом и плюсом (те же апи-ресурсы дружат с элоквент-моделями и могут всякое-разное)
4) В ларавеле есть еб*чие фасады (и если сам ты их можешь не юзать, то вот стандартных там дофига, и не все додумываются конкретный инстанс юзать вместо фасада)
1) В Laravel сложнее интегрировать сторонние решения, например доктрину. Потому что многие фичи фреймворка завязаны на его коробочный стэк (сиды и апи-ресурсы могут много "веселого" доставить, если юзать их с доктриной)
2) В Laravel менее гибкий сервис-контейнер (сильно не понравилось отсутствие _instanceof, а так же не хватает функционала для ручной фильтрации сервисов), хоть и со своими фишками вроде contextual binding
3) Оба фреймворка RAD, но laravel чуть больше, т.к. в тех же форм-реквестах или апи-ресурсах многое доступно из коробки (из-за этого в фреймворке овердофига наследования и куча неиспользуемого функционала инициализируется, хотя это скорее экономия на спичках). Кроме того, в ларавеле дофига функционала связано, что является тоже и минусом и плюсом (те же апи-ресурсы дружат с элоквент-моделями и могут всякое-разное)
4) В ларавеле есть еб*чие фасады (и если сам ты их можешь не юзать, то вот стандартных там дофига, и не все додумываются конкретный инстанс юзать вместо фасада)
ну вот насчет фасадов спорный момент
SP
По моему субъективному опыту:
1) В Laravel сложнее интегрировать сторонние решения, например доктрину. Потому что многие фичи фреймворка завязаны на его коробочный стэк (сиды и апи-ресурсы могут много "веселого" доставить, если юзать их с доктриной)
2) В Laravel менее гибкий сервис-контейнер (сильно не понравилось отсутствие _instanceof, а так же не хватает функционала для ручной фильтрации сервисов), хоть и со своими фишками вроде contextual binding
3) Оба фреймворка RAD, но laravel чуть больше, т.к. в тех же форм-реквестах или апи-ресурсах многое доступно из коробки (из-за этого в фреймворке овердофига наследования и куча неиспользуемого функционала инициализируется, хотя это скорее экономия на спичках). Кроме того, в ларавеле дофига функционала связано, что является тоже и минусом и плюсом (те же апи-ресурсы дружат с элоквент-моделями и могут всякое-разное)
4) В ларавеле есть еб*чие фасады (и если сам ты их можешь не юзать, то вот стандартных там дофига, и не все додумываются конкретный инстанс юзать вместо фасада)
1) В Laravel сложнее интегрировать сторонние решения, например доктрину. Потому что многие фичи фреймворка завязаны на его коробочный стэк (сиды и апи-ресурсы могут много "веселого" доставить, если юзать их с доктриной)
2) В Laravel менее гибкий сервис-контейнер (сильно не понравилось отсутствие _instanceof, а так же не хватает функционала для ручной фильтрации сервисов), хоть и со своими фишками вроде contextual binding
3) Оба фреймворка RAD, но laravel чуть больше, т.к. в тех же форм-реквестах или апи-ресурсах многое доступно из коробки (из-за этого в фреймворке овердофига наследования и куча неиспользуемого функционала инициализируется, хотя это скорее экономия на спичках). Кроме того, в ларавеле дофига функционала связано, что является тоже и минусом и плюсом (те же апи-ресурсы дружат с элоквент-моделями и могут всякое-разное)
4) В ларавеле есть еб*чие фасады (и если сам ты их можешь не юзать, то вот стандартных там дофига, и не все додумываются конкретный инстанс юзать вместо фасада)
стоит заметить что все эти сказки про RAD остались в нулевых. Сегодня разница настолько незначительна (пишешь ты на ларавели и на пыхе или на спринге с котлинами) и все упираются больше в то что "а как быстро понять что сделать то надо" упустили. Мол сделать апишку и задеплоить что бы оно там скейлилось бесконечно сча можно быстро а вот анализ проблемы и решения какие фичи юзать до сих пор проблема
SP
ну вот насчет фасадов спорный момент
идея с фасадами в целом была неплохой. Проблема в том что идею фасадов смешали с service locator что поднасрало в головы людям