Size: a a a

2021 June 25

S

Sergey in symfony
1) нарушением паттернов
2) в модели в симфони нельзя прокинуть сервисы(например, если часть данных забрать с другой сервера через httpclient)
3) модели инициализуются при гидратации многократно, а сервисы однократно, это может повлечь падение производительности и ошибки
4) модели раздуваются, становятся не читабельными
источник

睫膏

睫毛 膏蛇 in symfony
Можно, если ваш план архитектуры тому способствует и вы сможете держать их более-менее чистыми
источник

AT

Adilet Tussupbekov in symfony
Я к тому, что если ваша логика получения значения, к примеру как вы и сказали годность продукта, зависит только от значении в самой сущности, то вы можете описать метод с логикой в самой сущности.
источник

睫膏

睫毛 膏蛇 in symfony
Rich Domain Model вроде как раз про это
источник

D

Dmitry in symfony
а нельзя ли у вас сделать $entity->exportToDto ?
источник

D

Dmitry in symfony
я у себя сделал SomeDtoHydrator куда передаю сущность, сервисы и другие данные
источник

D

Dmitry in symfony
а если нужно просто отображение сущность в виде дтошки то делаю entity->toDto
источник

S

Sergey in symfony
Это плохо по вышеуказанным причинам, и у меня в сервисе еще много вещей связаных с определением годности(например просмотр логов для определения температурного режима)
источник

AT

Adilet Tussupbekov in symfony
Ну тогда логика зависит не только от данных в самой сущности, и это не подойдет
источник

AT

Adilet Tussupbekov in symfony
Я поэтому и спрашивал
источник

S

Sergey in symfony
вот с гидратором у меня были смутные идеи, но очень хочется сделать так, что бы:
1) при работе с коллекциями не перебирать их вручную
2) убрать вообще модели из контроллеров и минимумом кода заставить doctrine работать именно с dto(что бы другие разработчики не перепутали реализации в своих контроллерах и все было однотипно)
источник

D

Dmitry in symfony
у меня тонкие контроллеры, по сути он делает десериализацию входящих данных в некий дто
этот дто передается в хендлер запроса куда подключаются уже сервисы, билдеры и тп
источник

D

Dmitry in symfony
если это чтение - то есть рид модель где нет сущностей как таковых вообще, все даныне летают в дто
если изменение - то просто модель с сущностями от доктрины
источник

D

Dmitry in symfony
хендлер, по сути тот же usecase можно вызвать откуда угодно, главное правильно заполнить ему дто на вход и он сделает что нужно
источник

S

Sergey in symfony
угу, идея понятна, попробую, спасибо. Оверхеда по коду не много получается на простых методах вроде show/index и тд?
источник

D

Dmitry in symfony
если немного, но я сторонник дабы слегка оверхдеить но чтобы было понятно какой код выполняется
источник

VM

Volodymyr Melko in symfony
$model->calculateSomething($calculatorService)

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

D

Dmitry in symfony
не люблю хитрых схем валидации через аннотации и тп
мне проще сделать в каждом хендлере
Assert::notNull($incomingDto->someField,'Specify some field')
источник

Р

Роман in symfony
Мне вот любопытно какое место занимает ReadModel в слоях DDD?
источник

Р

Роман in symfony
и вообще есть примеры реализации рид модели потыкать?
источник