Юра
Так нельзя
Юра
Потому что валидация в ДТОоо
Anonymous
Мне надо достать энтити и сделать инкремент поля
$entity = $this->repository->getById($id);
$entity->updateProperty($dto->getIncrementable);
Eugen Su
О, "эта песня хороша, начинай сначала",)))
Юра
Любое изменение энтити жолжно теперь проходить через дто
Anonymous
Примерно
Юра
В смысле
Юра
Так валидный стейт в ДТО
Maxim Kainov
С такой уверенностью в себе можно вообще не использовать типы и объекты, всё делать на массивах, типа что за бред писать неправильно
Сохранить невалидную сущность это ошибка логики. С таким же успехом ты можешь в эту сущность сохранить левые данные.
Maxim Kainov
И они будут валидными.
Anonymous
О, "эта песня хороша, начинай сначала",)))
Да я уж не знаю чего я жду от этих обсуждений.
Anonymous
Наверное, когда меня ткнут в мой код и скажут "это говно", но пока к сожалению не происходило таких событий :(
Юра
Дак как обычно ответа ч не получил на свой вопрос
Юра
Он не укладывается в рамки ДДД модели наверное
Maxim Kainov
$entity = $this->repository->getById($id);
$entity->updateProperty($dto->getIncrementable);
Тебе надо данные поместить в дто, инкрементировать, провалидировать и отправитб обратно
Anonymous
Дак как обычно ответа ч не получил на свой вопрос
Какой вопрос-то? Я написал как бы я делал "инкремент"
Юра
Тебе надо данные поместить в дто, инкрементировать, провалидировать и отправитб обратно
Ну вот я об этом и говорю
Anonymous
Тебе надо данные поместить в дто, инкрементировать, провалидировать и отправитб обратно
Не, просто в дто сразу новое значение (на которое увеличивается)
Юра
Короче в идеальном мире ддд я так понимаю у тебя на каждое действия над моделью должен быть свой дто. Так сказать твое намерение изменить что-то. Ты его валидируеешь, потом херачишь это все в умную модель и ты в шоколаде
Anonymous
Ну так да.
Anonymous
Плюс минус, чтоб без говнокода
Egor
Так дто в этом случае нужно чтоб данные от пользователя проверять, если нужно инкрементировать значение в уже валидной модели, зачем ещё раз перегонять в дто?
Anonymous
Так дто в этом случае нужно чтоб данные от пользователя проверять, если нужно инкрементировать значение в уже валидной модели, зачем ещё раз перегонять в дто?
Ни за чем) но условия доеба были такие что надо все через дто. Допустим у нас инкремент тоже от пользователя идёт)
Юра
Потому что в модели нет валидации
Юра
А там может быть условие к примеру что значение не более чем 100
Юра
а после инкремента стало 101
Юра
Поэтому будь добр все в ДТО
Anonymous
Ну ты ж понимаешь что мы оба щас ради стеба будем городить хуйню?) или ты на серьёзных щщах все это пишешь?
Юра
Что?
Юра
Я асболютно серьезно пишу
Юра
потому что твой подвхиод выглядит так
$dto = Dto::createFromEntity($entity);
$dto->incrementCounter();
$validator->validate($dto);
$dto->map($entity);
$em->flush();
Юра
ну в псевдокоде
Юра
И я не понимаю зачем мне это все писать )
Anonymous
Штоооо
Anonymous
Дто создавать из энтити
Anonymous
Что вообще
Юра
Короче дто полумера какая-то. Если нужно прям все супер энтерпрайз то надо делат через Workflow всякие компоненты, где инкапслуриется вся логика и трекается состояние модели и т.д.
Anonymous
Я признаю поражение, я недостаточно стар чтобы это понять
Anonymous
Юра
Ну на практике в мире ПХП если чувак использует ОРМ это уже круто и похвально.
Maxim Kainov
Разработчики симфони вроде ничего не говорят про рич модел. Им наверное виднее как лучше, чем разработчикам доктрины
Юра
Ладно сори всем. Чет я прям негодую сразу когда вижу все эти энтерпрайз из джава мира подходы в симфони
Юра
Но видимо мы к этому прийдем, судя по доктрине 3
Юра
Поэтому всем учить ДДД )
Юра
И будет на каждый чих по пять классов
Egor
Разработчики симфони вроде ничего не говорят про рич модел. Им наверное виднее как лучше, чем разработчикам доктрины
В симфони нет ни одного компонента, касающегося сохранения состояния бизнес моделей, они предлагают использовать Доктрину для этого, ссылки на позицию которой я скинул. Причём тут Симфони? Что именно они должны сказать про рич или анемик модел?
Egor
На самом деле нет причин использовать богатую модель вместо анемичной, если с анемичной проблем нет, это же всего лишь рекомендация. Я так понимаю все, кто перешёл на богатую модель, начали испытывать проблемы с анемичной.
Egor
Это всё описано тысячу раз, в том числе в документации Доктрины, ссылку я скидывал
Anonymous
На самом деле нет причин использовать богатую модель вместо анемичной, если с анемичной проблем нет, это же всего лишь рекомендация. Я так понимаю все, кто перешёл на богатую модель, начали испытывать проблемы с анемичной.
Ну честно говоря непонятно, как будет выглядеть переход на третью доктрину для большинства народа
Anonymous
Хотя вряд ли доктрина 2 перестанет быть lts
Maxim Kainov
Ладно сори всем. Чет я прям негодую сразу когда вижу все эти энтерпрайз из джава мира подходы в симфони
В джаве так же нет рич модели
Egor
Ну честно говоря непонятно, как будет выглядеть переход на третью доктрину для большинства народа
Поддержка анемичной модели никуда не денется, Доктрина всего лишь маппит поля в базу, без разницы как они заполняются
Maxim Kainov
В симфони нет ни одного компонента, касающегося сохранения состояния бизнес моделей, они предлагают использовать Доктрину для этого, ссылки на позицию которой я скинул. Причём тут Симфони? Что именно они должны сказать про рич или анемик модел?
В том и дело, что доктрина всего лишь маппит, а симфони это фреймворк
Egor
😂
Maxim Kainov
https://javarush.ru/groups/posts/hibernate-java
Maxim Kainov
Такая же ерундень )
Anonymous
Поддержка анемичной модели никуда не денется, Доктрина всего лишь маппит поля в базу, без разницы как они заполняются
Ну, они по сути рекомендуют только, да.
Egor
Ну, они по сути рекомендуют только, да.
Типа если ты приложение выпускаешь в прод и больше не поддерживаешь сколько-нибудь долгое время, то это так называемый rapid application development и анемичные модели то что надо. Если приложение поддерживается 5+ лет и переписывать с нуля не хочется, то рекомендуется использовать богатые модели. Как то так.
Anonymous
https://javarush.ru/groups/posts/hibernate-java
https://medium.com/@nikos_k/how-to-avoid-the-anemic-domain-model-with-spring-and-hibernate-35495d6e2e94
Сергей
все те же, все о том же))
Maxim Kainov
Типа если ты приложение выпускаешь в прод и больше не поддерживаешь сколько-нибудь долгое время, то это так называемый rapid application development и анемичные модели то что надо. Если приложение поддерживается 5+ лет и переписывать с нуля не хочется, то рекомендуется использовать богатые модели. Как то так.
Вот в том и дело, каким это образом богатые модели помогут в этом, кем рекомендуется?
Maxim Kainov
https://medium.com/@nikos_k/how-to-avoid-the-anemic-domain-model-with-spring-and-hibernate-35495d6e2e94
Ну вот, значит там по умолчанию нет никаких рич моделей
Anonymous
Egor
Вот в том и дело, каким это образом богатые модели помогут в этом, кем рекомендуется?
Сообществом (ссылки скинул) и всякими умными дядьками типа Эванса, Фаулера и пр.
Anonymous
Рич домен это просто уровень middle+, мы ещё не познали
Maxim Kainov
Сообществом (ссылки скинул) и всякими умными дядьками типа Эванса, Фаулера и пр.
Ну разные есть мнения
Maxim Kainov
Ты читал эванса? Там муть какая то
Anonymous
Сообществом (ссылки скинул) и всякими умными дядьками типа Эванса, Фаулера и пр.
Ну кстати фаулера критикуют за то что из-за него стали анемики звать антипаттерном, это не так, мне кажется, ты сам подметил что эти две вещи реализуются для разных целей, и не являются по сути взаимоисключающими
Maxim Kainov
Роберт Мартин нормально пишет. Но он ничего не говорит за рич модель.
Anonymous
Тогда с чего там муть?
Maxim Kainov
И все время одно и то же повторяется
Maxim Kainov
Типа как в книге как бросить курить