почему не норм?
Потому что наружу модель не должна напрямую выводиться - только через JSON ресурс. А объявление этой переменной обязательно выстрелит в ногу.
почему? зачем городить еще какой-то класс вместо просто JsonResponse?
Оно призначено для других кейсов. Если у тебя апи - то есть апи ресурс при формирования ответа
это всмысле какая-то ларавская концепция? просто как бы в чем проблема вывести уже готовые данные? зачем их еще прогонять через какой-то дополнительный класс? не понимаю идею. Ну то есть в DDD, например идея того же DTO вполне понятна, а тут в чем смысл?
Теперь представь что результат модели нужно вывести в таком виде. Как это сделаешь без трансформера?
Проблем пока нет, пока что... В будущем труднее будет поддерживать приложение с таким подходом.
проблемы нужно решать по мере поступления. Я вообще изначально хотел сразу применить DDD, описать каждый бизнес-процесс отдельным пакетом а потом уже подружить эти пакеты с ларой через прослойки, но на текущем этапе это overhead
https://laravel.com/docs/10.x/eloquent-resources#generating-resource-collections
А не легче сразу создать ресурс и использовать их, чем потом по всему проекту бегать менять?
тогда получается контроллеры не нужны?
Я уже не понял. Почему?
По такой логике можно всё в public.php писать и на фиг эти контроллеры, ресурсы, модели, джобы...))
ну если роутер может сразу обращаться к ресурсу и передавать ему модель, то зачем тогда контроллер
вот тут вы уже перегибаете =)
DTO это не DDD ))) DTO это про трансфер даты между слоями
А JsonResource это трансформер для преобразования данных, отдаваемых наружу. Он не имеет отношения к внутренней логике
К чему они? Тут вспомнил - https://t.me/laravel_web/1018181
ну просто у меня по проекту получается что я только json и отдаю, тогда зачем мне контроллеры, если будут эти jsonResource
ты разраб, тебе видней, может и не нужны )
в ларе есть уже трейт для uuid в моделях
Обсуждают сегодня