Юра
Мне кажется это немного не то
Юра
Или то?
Vlad
а что тебе надо? мы используем все ок
Юра
Та не все то. я не понял сначала
Юра
быстрее чем preload?
Ну если ч правильно понимаю о чем ты, то всеравно на каждый запрос идет инициализация приложения
Dmitriy
Ну вот интересно писькомерство с прелоад
Юра
Кто-то знает как это работает? Какой-то канал с четырьмя видео за год, у которого почти 5к подписчиков
Юра
Юра
Боты и накрутки?
Gleb
Немного уточню - для англоязычных видосов это действительно немного. На русском набрать сложнее.
Где у нас миллион подписчиков это много, в англоязычном сегменте это небольшой канал.
Юра
Понял, спасибо
Shokha
artem
Maks
/listwarnings@BanWarnBot
Null
/listwarnings@BanWarnBot
Null
Пхе пхе пхе. Об каналы радостно ломается.
Kirill
Всем привет! Я хочу описать подход, который у нас используется. Подскажите, пожалуйста, а как вы это делаете?
Например, типичный метод create, который что-то создает выглядит примерно так:
- На вход приходит ДТО, валидируется
- Вызывается маппер, который из этой ДТО заполняет entity и возвращает ее
- Вызывается сервис, который эту entity сохраняет (обертка над entityManager)
- Вызывается второй маппер, который из entity заполняет ДТО (это другая ДТО, первая была входящей, там только айдишники)
- ДТО возвращается в ответ
Юра
Капец треш с этим UUID
Юра
Не смогли cделать по человечески чтобы в DQL не писать
$query->setParameter('parent', $task->getId(), 'uuid');
Юра
т.е. доктрина настолько могуча, что на полном серьезе если ты явно передашеь параметр туда с типом Uuid, оно не может догадаться что это uuid
Юра
Passing null as parameter type (which is the default when omitting the argument) tries to guess the right type. But the Doctrine ORM currently does not provide any extension point to extend the guessing logic to support custom types.
Павел
Капец треш с этим UUID
Ещё и на чтении надо будет помучаться, если голый sql . Но вроде можно через getBinary без указания типа в третьем параметре
Павел
Всем привет! Я хочу описать подход, который у нас используется. Подскажите, пожалуйста, а как вы это делаете?
Например, типичный метод create, который что-то создает выглядит примерно так:
- На вход приходит ДТО, валидируется
- Вызывается маппер, который из этой ДТО заполняет entity и возвращает ее
- Вызывается сервис, который эту entity сохраняет (обертка над entityManager)
- Вызывается второй маппер, который из entity заполняет ДТО (это другая ДТО, первая была входящей, там только айдишники)
- ДТО возвращается в ответ
Скорее всего последнее лишнее. sqc нарушается. Id на вывод достаточно, а то и его не надо
Павел
У вас есть экшен "создание". Почему он отвечает за респонс http - вопрос.
Павел
Например прокинул id в нее, а внутри фабрики уже сущности дернулись из репозитрриев и пропихали в сущность. Аплекуха поменьше стала, вроде хорошо. Но мне например лень)
Kirill
Архитектура ради архитектуры - это вы хорошо сказали)
Павел
Ну ещё можно для нейминга. Например у вас есть "активирована", "деактивированная", "супер", "вип". Factory->createVip() будет понятнее в коде, чем отсутствие фабрики.
Павел
Ну короче если сами не знаете за чем делаете и что с этого ловите или хотите поймать в будущем - стоит задуматься, надо ли
Юра
Логика в DATA transfer object
Юра
Логично
Юра
По идее дто придумали в статически типизированных языках чтобы работать с данными
Юра
Натянули на пхп
Юра
И вроде всем нравится
Павел
Юра
Я не понял просто фабрику и логику
Павел
тут по сути и дто не решает, можно на массив заменить (имею ввиду про обсуждение фабрики)
Юра
Фабрика энтитей. Понял. Я думал фабрика дто
Юра
Иногда такое прям в статический метод энтити выносят
Юра
Но тут как бы можно напороться что нужен сервис а его нет
Павел
Только привязывать эентити к той же дто будет не очень, и как верно после написал - что с сервисом будет беда, если понадобится. Можно конечно прокинуть через параметр, но смысл
Юра
Вообще все это получается если подумать как запрос внутри запроса. Внутри хттп запроса у нас запрос в приложении на создание энтити. Точками входа в этот внутренний запрос является сервис либо CQRS либо еще что-то. Ну а дто это так сказать апи схема
Павел
Юра
Получается у нас есть слой, на границе которого дто. Мы можем вызывать этот подзапрос и без хттп
Юра
Так что контроллер это просто один из способов вызова твоего реального домейн запроса
Юра
В этом плане само название контроллер стало атавизмом потому что он ничего не контролирует по сути. Просто мапер
Юра
Но это чисто в рест апи так вырождается. В других типах приложений контроллер всё-таки еще контроллером остаётся местами
Юра
Ну надо быть аккуратным потому что получатется твоя бизнес логика вшита и привязана к хттп
Юра
Например из консоли понадобится сделать и уже траблы начинаются
Павел
Юра
Дык я и говорю что в рест апи контроллер чисто больше как мапер
Юра
Или эти патологические случаи, когда внутри приложения создаётся рикаест риспонс чтобы дернуть контроллер
Павел
Опять таки, кейс ТСа: сделать создание, отдать сущность в рест апи. Тут скорее как должно быть 2 отдельные задачи: создание сушности, который вернет id, и query который вернет данные необходимые для read на фронте после этого. Удобненько вызвать подряд в контроллере
Vlad
😳
Юра
Юра
Вдруг не надо
Павел
Или какой нить большая форма с фронта, которая задейсвтует несколько модулей на изменение - вызвал подряд несколько модулей в контроллере и всё. Это же не какая то бизнесовая операция в рамках приложения - это BFF через контроллер, из-за раздутой формы
Юра
Юра
Когда каждое действие это докер контейнер
Юра
)
Павел
Павел
Ну не, вполне нормальный кейс без усложнения.
Профиль и управление нотификациями. Это два модуля. Но форма на фронте может быть под 1 кнопкой.
Юра
Ну а че. Во все новая парадигма. МикроРест(tm)
Юра
Запрос роутится сразу в контейнер
Юра
На каждый эндпоинт свой
Павел
)))
Юра
Серваки покупаются, железо продаётсч, экономика растет. Все в плюсе )
Юра
Кстати если заглянуть в нутри флекса, то там можно увидеть паттерн о котором я выше говорил, когда сначала заполняется дто с параметрами запроса, потом делается квери и получается дто респонс. Все внутри либы