Было бы уместнее назвать ViewProviderData тогда было бы проще воспринимать его

Что конкретно вы хотите предложить/подсказать? Ведь если мы говорим о правайдере как о dto или value object то кажеться вовсе не уместным передавать в такой тип любые requests, q-builders.

В этом и суть, я предлагаю не рассматривать его исключительно как дто, в ином случае для этой модели нужен дополнительный класс обеспечивающий его данными, что кстати не мешает, просто зачем

Вместо ViewModel содержащей знание о построителе вы получите ViewFactory + ViewModel. Для чистоты наверное уместно, но для большинства проектов избыточно.

Я еще обдумаю эту мысль. Подводя, хотя бы промежуточный итог, мы имеем следующую позицию: view-model предлагается воспринимать не только как DTO, чем она концептуально и являяеся, но и как самостоятельный сервис для обработки данных необходимых во view. Если мы говорим о q-builder’е тогда это не меняет сути - view-model все равно обращаться к бд. Конкретно - лучше отдельный сервис внутри view-model или сам view-model воспринимать как сервис?)

Скорее сервис над ViewModel а не внутри.

Не понял, а при чем тут фабрика, что является признаком создания отдельных объектов, - сервис/q-builder для модели или сама модель?

спасибо

До того как данные попадут в модель их надо получить. Если вы не хотите получать их внутри модели значит должен быть сервис, фабрика знающая откуда получить данные и как создать объекты ViewModel. Следовательно можно разбить даже на 3 класса 🙂

значит правильно понял вашу мысль

но честно говоря это уже скорее дискуссия на главу книги по ооп чем о том как обработать данные в одном методе

Да, потому для себя, на текущий момент, определил данный подход как провайдер и делаю там что хочу 😄

Тем не менее, спасибо вам за помощь, я еще обдумаю предложенные вами мысли🙂

Обязательно поделитесь итоговым решением!)

Помните ли, есть ли Аделя мысли по поводу view-model в его книге?

Не видел

Это в другом материале

С вебхуком будет нерационально в данном случае. Во-первых, это будет чуть дольше, во-вторых, при большом кол-ве сообщений твой бэкенд могут положить. А так ты фетчишь сообщения в воркере, не отжирая много ресурсов.

Плюс ты сам выбираешь, когда забирать сообщения, как много, как часто. А тут тебе шлют вебхуки и делай с этим что хочешь.

Как у вас с английским? Есть ли смысл скинуть вам книгу Брента из команды Spatie - Laravel Byound Crud? Так есть глава посвященная view-model'ям