Юра
Ну и весело когда тебе надо поправить что-то и тебе надо лазить по всему коду менять валидации, мапинги и т.д.
Иван
на определённом уровне сложности это позволяет декомпозировать по юзкейсам
Konstantin
Пришел запрос, он мапится в сущность ДТО, на которую навешены валидации
Потом мапиш это в сущность доктрины, на которой только доктрин аннотации
там на каждый чих придется дто своё писать, я скорее согласен, что лучше для каждого случая свой дто прокидывать, а не таскать везде по коду доктриновые сущности. но это легкий оверкилл по мне, реально будут сотни дтошек. и работать они будут только на чтение, как тебе у сущности поле нужно поменять, ты все равно прибегаешь к сущности. либо пишешь Command из CQRS - и тут реально у тебя становится МНОГО дтошек
Иван
у каждой сущности по количеству юзкейсов
Konstantin
именно
Konstantin
по 2-3 юзкейса на сущность довольно легко себе представить. равно как и 30 сущностей в системе
Konstantin
вот она и сотня, а это мы еще про запись не говорим, только чтение
Иван
на патч, например, можно все допустимые обновления в одной дто собрать
Konstantin
это не всегда удобно, иногда надо обновить таки одно поле
Konstantin
и тогда либо у нас будет "жидкая" дто - со всеми нуллабельными полями (из которых мы заполняем только одно нужное в данный момент), либо по дто на каждую операцию записи
Юра
По идее логично что запрос и запись в бд это две разные сущности
Юра
И валидировать в идеале нужно и то и то
Юра
Ибо доктрин сущность может быть сконструрована не только из запроса
Konstantin
первый случай, очевидно, не лучший, тк мы теряем контроль инварианта состояния дто. легко может быть что передали все поля пустыми, или какой-то невозможный инвариант (допустим нельзя менять и емейл и пароль в одном месте, тк смена емейла должна пройти через своё апи - с подтверждением нового
Иван
надо просто разрешить себе при валидации ходить в базу и смотреть, чо там
тогда все вопросы отпадут, будет много валидаторов, но лучше так, чем в одной куче и хрен поймёшь, где и что
Konstantin
и в таком случае с точки зрения надежности, это дто ничем не отличается от сущности - в ней точно так же есть вся помойка всех полей
Иван
первый случай, очевидно, не лучший, тк мы теряем контроль инварианта состояния дто. легко может быть что передали все поля пустыми, или какой-то невозможный инвариант (допустим нельзя менять и емейл и пароль в одном месте, тк смена емейла должна пройти через своё апи - с подтверждением нового
смена кредов - вообще отдельная операция
саусем отдельная
Konstantin
По идее логично что запрос и запись в бд это две разные сущности
согласен, так мы и приходим к CQRS и типизированным C и Q. только это, повторюсь, сотни дтошек даже на мелких проектах. в теории это крутая штука, но она разбивается об практику реализации текущих инструментов и вообще языка
Konstantin
смена кредов - вообще отдельная операция
саусем отдельная
я понимаю, но это не отразить только в "одна дто со всеми полями для всех операций обновления"
Konstantin
это вообще слабо отличается от ассоциативного массива, если честно, вместо класса. ну или stdClass если угодно
Иван
я понимаю, но это не отразить только в "одна дто со всеми полями для всех операций обновления"
одна дто на набор безопасных полей
две других на креды
Konstantin
Иван
зато это не PUT который как есть мапится в сущность
Konstantin
всё так, пут стремная штука, хотя бы вон в разрезе смены емейла
Konstantin
как в апи сказать "это поле можно создать через общий ПОСТ, но нельзя поменять через общий ПУТ" я так и не придумал
Konstantin
просто молча его игнорить на сервере - ну так себе идея, это не сильно помогает писать клиента апи.
Иван
согласен, так мы и приходим к CQRS и типизированным C и Q. только это, повторюсь, сотни дтошек даже на мелких проектах. в теории это крутая штука, но она разбивается об практику реализации текущих инструментов и вообще языка
> практику реализации текущих инструментов
это не значит, что практика хорошая
> вообще языка
нормально всё с языком
Konstantin
женериков нету 🙂
Konstantin
с ними проще было бы чуть шаблонные дтошки процессить
Konstantin
но в целом я этот тезис всецело поддерживаю, конечно
Иван
как в апи сказать "это поле можно создать через общий ПОСТ, но нельзя поменять через общий ПУТ" я так и не придумал
общий пут не нужен, потому что общий пут - нарушение сокрытия и идеи обмена сообщениями
Konstantin
всё так
Konstantin
но мы щас так вообще от доктрины уйдем, она это и нарушает в первую очередь
Konstantin
там любое обновление - это и есть "общий пут"
Иван
не, там патч частичный
Konstantin
ну я с точки зрения интерфейса разработчика
Konstantin
он делает персист на всю сущность
Иван
только обновлённые поля уезжают в базу
поэтому можно обломиться с дейттаймами
Konstantin
я понимаю, но разработчик, делая persist($entity) этого не видит. он не говорит "обнови только поле ххх". для него это и выглядит как "общий пут"
Иван
так persist только на создание
там да, целиком
Konstantin
а сохранение как?
Иван
просто флаш
Konstantin
мм а можно код?
Konstantin
я таки не совсем программист последние годы, иногда от нефиг делать иду руками куда-то потыкать. поэтому могу слегка отставать от трендов использования симфони и доктрины
Konstantin
но вроде бы это всегда
$em->persist($ent)
$em->flush()
Иван
только если новая сущность
если редактируешь, то персист не нужен
A
да
A
а можно как-то настроить симфу, чтобы при генерации названий переменных для автовайринга использовал snake_case стиль ?
Иван
хотел скинуть код, но у меня даже флаш в миддлваре
Konstantin
только если новая сущность
если редактируешь, то персист не нужен
так и не понял как это должно выглядеть.
мы просто пишем в сеттер
$ent->setFoo('bar')
и где-то там флаш?
Иван
https://github.com/Punk-UnDeaD/simplenews/blob/master/src/SimpleNews/UseCase/Create/Handler.php#L23
https://github.com/Punk-UnDeaD/simplenews/blob/master/src/SimpleNews/UseCase/Update/Handler.php
Konstantin
а если в этом story кто-то еще в соседнем коде поменяет свойство? оно тогда неявно запишется?
Konstantin
это ведь и есть то же самое - "большой общий пут", где ты не знаешь точно, какие именно данные у тебя записались
Иван
Иван
все обновления через команду
Nikolay
хотел скинуть код, но у меня даже флаш в миддлваре
Это чтобы вручную во всех хэндлерах не вызывать?
A
Можете пожалуйста в двух словах пояснить, что это за подход/паттерн? И в чем его профит?)
Елнур
Елнур
Лично мне не нравится, когда команда совсем ничего не возвращает... Но в остальном норм подход
Nikolay
Лично мне не нравится, когда команда совсем ничего не возвращает... Но в остальном норм подход
Так суть команды что то сделать и все
Nikolay
Можете пожалуйста в двух словах пояснить, что это за подход/паттерн? И в чем его профит?)
Логика чтения и записи разделяется, на запросы и команды
Юра
Не понимаю этот cqrs
Юра
Читал читал, мгого бувк, смысла нолб
Юра
А мы что не разделяем в апи? Пост запрос меняет, гет запрос получает
Юра
Короче обычная мутотень энтерпрайзная
Konstantin
😂
A
вспомнил fizzbuzz enterprise edition
A
Подскажите плз, у меня есть сущность User, у которого хочу реализовать callback-валидацию.
Реализовал метод валидации, но при самой валидации мне необходимо использовать другой сервис.
Каким образом лучше внедрять зависимость, чтобы не нужно было менять код, где уже используется эта сущность. В тех. же фикстурах..?
A
Т.е. конструктор и метод не подходит) неужели только хардкодить?)
Konstantin
необходимость внедрять зависимости в сущности вернейший признак ошибки в проектировании
A
Konstantin
это сильное нарушение срп и всего прочего, валидация внутри модели должна знать только о валидации инварианта своих полей (дата to должна быть больше даты from)
A
/**
* @Assert\Callback()
*/
public function validate(ExecutionContextInterface $context, $payload)
{
...
}
Konstantin
если требуется валидировать что-то с привлечением внешних источников знаний - это ошибка