в
Сам не понял, пока их не посмотрел
Size: a a a
2021 February 11
ST
Можно ивентами, а лучше создать кастомный персистер
Спасибо, почитаю, как там персистенсы создавать. Просто я думал что будет что-то вроде API - Контроллер, контроллер в сервис, который (сервис) могут использовать все кому-ни лень, а в ступор впал, что platform работает прям сразу с сущностью минуя всё.
ST
В 3 части гайдов по апи платфооме на сфкастс есть подробнейшее пояснение
Поищу, спасибо большое
MV
Господа, помогите новичку. Не могу понять "философию" api-platform. Она работает непосредственно с Entity, а если я хочу, чтобы вызов api/orders/{id} запускал хендлер, в котором чего-то я хочу делать? Ну например, обновлять сущность, но или еще что-нибудь
в
Спасибо, почитаю, как там персистенсы создавать. Просто я думал что будет что-то вроде API - Контроллер, контроллер в сервис, который (сервис) могут использовать все кому-ни лень, а в ступор впал, что platform работает прям сразу с сущностью минуя всё.
В этом и прикол) да, по началу понять сложно, потом норм
WD
И грузи свои таски
А как мне узнать что задачи из очереди выполнены?
AK
Привет!
А кто-то в своих проектах использует репозитории без наследования от доктриновского класса? (Через инъекции в конструкторе)
Как в статье - https://getrector.org/blog/2021/02/08/how-to-instantly-decouple-symfony-doctrine-repository-inheritance-to-clean-composition
Есть ли какие-то подводные камни? Стоит ли писать так же?
Выглядит адекватно, но одно дело статья, другое дело большие репы в реальных проектах :)
А кто-то в своих проектах использует репозитории без наследования от доктриновского класса? (Через инъекции в конструкторе)
Как в статье - https://getrector.org/blog/2021/02/08/how-to-instantly-decouple-symfony-doctrine-repository-inheritance-to-clean-composition
Есть ли какие-то подводные камни? Стоит ли писать так же?
Выглядит адекватно, но одно дело статья, другое дело большие репы в реальных проектах :)
А
Привет!
А кто-то в своих проектах использует репозитории без наследования от доктриновского класса? (Через инъекции в конструкторе)
Как в статье - https://getrector.org/blog/2021/02/08/how-to-instantly-decouple-symfony-doctrine-repository-inheritance-to-clean-composition
Есть ли какие-то подводные камни? Стоит ли писать так же?
Выглядит адекватно, но одно дело статья, другое дело большие репы в реальных проектах :)
А кто-то в своих проектах использует репозитории без наследования от доктриновского класса? (Через инъекции в конструкторе)
Как в статье - https://getrector.org/blog/2021/02/08/how-to-instantly-decouple-symfony-doctrine-repository-inheritance-to-clean-composition
Есть ли какие-то подводные камни? Стоит ли писать так же?
Выглядит адекватно, но одно дело статья, другое дело большие репы в реальных проектах :)
А в чем сомнения? composition over inheritance еще в школе изучают, никогда не наследовался.
Р
Привет!
А кто-то в своих проектах использует репозитории без наследования от доктриновского класса? (Через инъекции в конструкторе)
Как в статье - https://getrector.org/blog/2021/02/08/how-to-instantly-decouple-symfony-doctrine-repository-inheritance-to-clean-composition
Есть ли какие-то подводные камни? Стоит ли писать так же?
Выглядит адекватно, но одно дело статья, другое дело большие репы в реальных проектах :)
А кто-то в своих проектах использует репозитории без наследования от доктриновского класса? (Через инъекции в конструкторе)
Как в статье - https://getrector.org/blog/2021/02/08/how-to-instantly-decouple-symfony-doctrine-repository-inheritance-to-clean-composition
Есть ли какие-то подводные камни? Стоит ли писать так же?
Выглядит адекватно, но одно дело статья, другое дело большие репы в реальных проектах :)
Норм работает
в
Привет!
А кто-то в своих проектах использует репозитории без наследования от доктриновского класса? (Через инъекции в конструкторе)
Как в статье - https://getrector.org/blog/2021/02/08/how-to-instantly-decouple-symfony-doctrine-repository-inheritance-to-clean-composition
Есть ли какие-то подводные камни? Стоит ли писать так же?
Выглядит адекватно, но одно дело статья, другое дело большие репы в реальных проектах :)
А кто-то в своих проектах использует репозитории без наследования от доктриновского класса? (Через инъекции в конструкторе)
Как в статье - https://getrector.org/blog/2021/02/08/how-to-instantly-decouple-symfony-doctrine-repository-inheritance-to-clean-composition
Есть ли какие-то подводные камни? Стоит ли писать так же?
Выглядит адекватно, но одно дело статья, другое дело большие репы в реальных проектах :)
а в чем преимущество?
AK
А в чем сомнения? composition over inheritance еще в школе изучают, никогда не наследовался.
Да как-то раньше банально не задумывался об этом - по документации симфони изначально как стали делать, так и не было вопросов :)
Очевидно, что композиция лучше наследования - этим статья и привлекла
Очевидно, что композиция лучше наследования - этим статья и привлекла
А
а в чем преимущество?
В том, что у тебя в сервисах/хэндлерах доступны только те методы, что ты опишешь в интерфейсе своего репозитория, а не 10+ ненужных методов, которые позволяют делать говно.
в
а, глянул статью
в
буду теперь так делать
ⓐ
Всем привет! провожу небольшое исследование на тему сравнения 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
DT
в ларке фасады еще
VK
Всем привет! провожу небольшое исследование на тему сравнения 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
Laravel - для ослов, Symfony - не для ослов, но бывает что тоже для ослов
SP
Всем привет! провожу небольшое исследование на тему сравнения 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
а в чем цель исследования?
DT
в доктрине рекомендуемо всеравно через ммиграции