и поставить это перед сериализатором либо же встроить в него (если он кастомный) как первый этап

Что srp? Srp не про данные отдельно процедуры отдельно

Когда у тебя поведение зависит от флагов которые ты передаешь это называется control coupling и лучше вместо флагов иметь два отдельных метода

Круто, спасибо)

Сделай отдельно сервис для "сгенерить юзера" и в одном месте просто генерь и отдавай а в другом генерь и сохраняй

Ну я решил просто флаш вынести в контекст

Некоторое дублирование из-за этого есть, но не страшно

Всем привет, возник вопрос по поведению api platform(2.6.5), переопределяю метод коллекции post без явного указания

input_formats

и получаю ответ:

The content-type \"application/ld+json\" is not supported

Если не переопределять метод po

st, 

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

put_formats в

ресурсе. И собственно интересует почему такое поведение из коробки стоит.

я про данные и не говорил. Просто логика размещенная в моделях часто приводят к нарушениям SRP.

srp нарушается не от факта наличия логики в сущностях а в том как сущность декомпозирована. То есть да можно сделать так что одна сущность будет содержать в себе разную логику так что будет нарушаться srp. но тебя никто не заставлял этого делать.

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

дык я и не тебе писал, а автору вопроса

чтобы он задумался на счет SRP

а я уточняю что просто написать srp недостаточно ибо srp не нарушается. Нарушить srp можно при любом раскладе. Хотя если опять же человек упомянул grasp (а там есть information expert) то шансы что srp будет соблюден выше

наоборот

нууууу по сути просто структура данных не влияет на srp, там проблемы посерьезнее вроде глобального а иногда поталогического каплинга...

хотя с другой стороны если рассматривать именно геттеры и сеттеры то да, у класса анемичного приичн для изменений больше одной будет (потому что для разных операций надо менять структуру)

и у 3 десятков других классов, которые едят эти геттеры

не, там просто каплинг выше. по сути srp нарушен или нет определяется набором операций которые класс реализует а не от кого зависит. В частности кому эти операции нужны и кто их использует (end user так скажем по всей цепочке). Геттеры сеттеры можно мысленно заменить на просто публичные поля (или мысленно на массивы что бы от объектов отойти) и тогда мы имеем нарушения кучи других принципов но не srp.

очень зависит от того, как вы построили своё приложение.
если у вас есть объекты, которые оперируют “некими данными” - то тогда эти самые данные не должны ничего уметь, они просто будут. и тут как раз в пригоде становятся анемичные модели которые сами себе ДТО.
если у вас объектами являются как раз сущности данных - то тут уже наоборот, количество обслуживающих сервисов должно максимально уменьшится, а сервисов, модифицирующих сущность вообще не  должно существовать, всё поведение складывается в саму сущность.
как-то так.

и везде есть проблема куда важнее, сошлюсь на Сергея
в обоих вариантах есть риск напороться на проблемы, если выкроить эти объекты без опоры на прцоессы