Юра
Мне кажется это немного не то
Юра
Или то?
Vlad
а что тебе надо? мы используем все ок
Юра
Та не все то. я не понял сначала
Dmitriy
В 5-10 раз быстрее
быстрее чем preload?
Юра
быстрее чем preload?
Ну если ч правильно понимаю о чем ты, то всеравно на каждый запрос идет инициализация приложения
Dmitriy
Ну вот интересно писькомерство с прелоад
Юра
Кто-то знает как это работает? Какой-то канал с четырьмя видео за год, у которого почти 5к подписчиков
Юра
Юра
Боты и накрутки?
Spider
Кто-то знает как это работает? Какой-то канал с четырьмя видео за год, у которого почти 5к подписчиков
5к подписчиков это совсем немного. Начал пилить видосы раскидал по соццсетям, люди приши а часть отписаться забыла
Gleb
Немного уточню - для англоязычных видосов это действительно немного. На русском набрать сложнее. Где у нас миллион подписчиков это много, в англоязычном сегменте это небольшой канал.
Юра
Понял, спасибо
Shokha
Видимо надо целиком доклад посмотреть )))
В итоге что получилось у вас? Вот у меня новый проект есть, хотел сделать папки типа таким структурами
Alexey Mishurovskiy
В итоге что получилось у вас? Вот у меня новый проект есть, хотел сделать папки типа таким структурами
Сколько ж лет назад это было)) Я пошел по другом пути - взял на работу правильного сеньора и он все сделал )
Игорь
В итоге что получилось у вас? Вот у меня новый проект есть, хотел сделать папки типа таким структурами
Нормально все получается, если вы делаете максимально приближено к своим бизнес процессам/коммуникациям (http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/)
artem
Сколько ж лет назад это было)) Я пошел по другом пути - взял на работу правильного сеньора и он все сделал )
Тут поспорю) лучше взять миддла и манагера. Сеньор не факт что поймет бл
Maks
/listwarnings@BanWarnBot
Ban Warn Bot
/listwarnings@BanWarnBot
User Maks Ze was never warned.
Null
/listwarnings@BanWarnBot
Ban Warn Bot
/listwarnings@BanWarnBot
User Channel was never warned.
Null
Пхе пхе пхе. Об каналы радостно ломается.
Null
/listwarnings@BanWarnBot
А администратор, получается, даже не знает кто скрывается за каналом?
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 без указания типа в третьем параметре
Павел
У вас есть экшен "создание". Почему он отвечает за респонс http - вопрос.
Kirill
Скорее всего последнее лишнее. sqc нарушается. Id на вывод достаточно, а то и его не надо
Меня больше мапперы интересуют. Я задумался, зачем они нужны, почему не сериалайзер. Там внутри маппера берется энтити и вызываются все сеттеры
Павел
Меня больше мапперы интересуют. Я задумался, зачем они нужны, почему не сериалайзер. Там внутри маппера берется энтити и вызываются все сеттеры
В начале это фабрика, то что вы назваете маппером. Можно юзать можно нет. Практика наверное хорошая, но часто бессмысленная. Особенно если тупо сеттеры. В ней удобно логику заинкапсулировать. Или единую точку обозначить (например если создание есть из разных мест). Если нет ни того, ни другого - имхо, архитектура ради архитектуры
Павел
Например прокинул id в нее, а внутри фабрики уже сущности дернулись из репозитрриев и пропихали в сущность. Аплекуха поменьше стала, вроде хорошо. Но мне например лень)
Kirill
Архитектура ради архитектуры - это вы хорошо сказали)
Павел
Ну ещё можно для нейминга. Например у вас есть "активирована", "деактивированная", "супер", "вип". Factory->createVip() будет понятнее в коде, чем отсутствие фабрики.
Павел
Ну короче если сами не знаете за чем делаете и что с этого ловите или хотите поймать в будущем - стоит задуматься, надо ли
Юра
Логика в DATA transfer object
Юра
Логично
Юра
По идее дто придумали в статически типизированных языках чтобы работать с данными
Юра
Натянули на пхп
Юра
И вроде всем нравится
Павел
Логика в DATA transfer object
Не понял поинт
Юра
Я не понял просто фабрику и логику
Павел
Павел
тут по сути и дто не решает, можно на массив заменить (имею ввиду про обсуждение фабрики)
Юра
Фабрика энтитей. Понял. Я думал фабрика дто
Юра
Иногда такое прям в статический метод энтити выносят
Юра
Но тут как бы можно напороться что нужен сервис а его нет
Павел
Иногда такое прям в статический метод энтити выносят
Это да, фабричный метод/именованный конструктор. Удобненько.
Павел
Только привязывать эентити к той же дто будет не очень, и как верно после написал - что с сервисом будет беда, если понадобится. Можно конечно прокинуть через параметр, но смысл
Юра
Вообще все это получается если подумать как запрос внутри запроса. Внутри хттп запроса у нас запрос в приложении на создание энтити. Точками входа в этот внутренний запрос является сервис либо CQRS либо еще что-то. Ну а дто это так сказать апи схема
Юра
Получается у нас есть слой, на границе которого дто. Мы можем вызывать этот подзапрос и без хттп
Юра
Так что контроллер это просто один из способов вызова твоего реального домейн запроса
Юра
В этом плане само название контроллер стало атавизмом потому что он ничего не контролирует по сути. Просто мапер
Юра
Но это чисто в рест апи так вырождается. В других типах приложений контроллер всё-таки еще контроллером остаётся местами
Павел
В этом плане само название контроллер стало атавизмом потому что он ничего не контролирует по сути. Просто мапер
Почему. Часто приходится заюзать несолько экшенов подряд, не охото для этого прослойку создавать еще одну и еще один слой маппинга.
Юра
Ну надо быть аккуратным потому что получатется твоя бизнес логика вшита и привязана к хттп
Юра
Например из консоли понадобится сделать и уже траблы начинаются
Юра
Дык я и говорю что в рест апи контроллер чисто больше как мапер
Юра
Или эти патологические случаи, когда внутри приложения создаётся рикаест риспонс чтобы дернуть контроллер
Павел
Опять таки, кейс ТСа: сделать создание, отдать сущность в рест апи. Тут скорее как должно быть 2 отдельные задачи: создание сушности, который вернет id, и query который вернет данные необходимые для read на фронте после этого. Удобненько вызвать подряд в контроллере
Vlad
😳
Юра
Вдруг не надо
Павел
Или какой нить большая форма с фронта, которая задейсвтует несколько модулей на изменение - вызвал подряд несколько модулей в контроллере и всё. Это же не какая то бизнесовая операция в рамках приложения - это BFF через контроллер, из-за раздутой формы
Юра
Когда каждое действие это докер контейнер
Юра
)
Павел
Ну не, вполне нормальный кейс без усложнения. Профиль и управление нотификациями. Это два модуля. Но форма на фронте может быть под 1 кнопкой.
Юра
Ну а че. Во все новая парадигма. МикроРест(tm)
Юра
Запрос роутится сразу в контейнер
Юра
На каждый эндпоинт свой
Павел
)))
Юра
Серваки покупаются, железо продаётсч, экономика растет. Все в плюсе )
Юра
Кстати если заглянуть в нутри флекса, то там можно увидеть паттерн о котором я выше говорил, когда сначала заполняется дто с параметрами запроса, потом делается квери и получается дто респонс. Все внутри либы