АС
не допускай вообще невалидность сущности
Size: a a a
2020 May 12
АС
если ты понимаешь, конечно, что такое "валидность"
АС
в чем у меня сильные сомнения
M
не допускай вообще невалидность сущности
Ну вот выше я привел кейс, когда это невозможно
АС
я всё сказал
это не кейс, это херня
или у тебя сущность валидна - то есть проходит правила валидации
или она не должна существовать вообще
объект не должен память занимать
стейт должен быть уничтожен
это не кейс, это херня
или у тебя сущность валидна - то есть проходит правила валидации
или она не должна существовать вообще
объект не должен память занимать
стейт должен быть уничтожен
M
я всё сказал
это не кейс, это херня
или у тебя сущность валидна - то есть проходит правила валидации
или она не должна существовать вообще
объект не должен память занимать
стейт должен быть уничтожен
это не кейс, это херня
или у тебя сущность валидна - то есть проходит правила валидации
или она не должна существовать вообще
объект не должен память занимать
стейт должен быть уничтожен
Ну пускай она валидна, но не согласована. Все равно, это ошибка данных, и не поможет от нее спастись никакое ограничение.
M
Никакой тест
DE
Ну пускай она валидна, но не согласована. Все равно, это ошибка данных, и не поможет от нее спастись никакое ограничение.
Сущность всегда согласована.
DE
Это и есть её валидность/инвариант.
M
Это и есть её валидность/инвариант.
Тем более
АС
да не спорьте вы
АС
там уже упоротость, а не конструктив
АС
"валидна, но не согласована"
"запорожец исправен, но не заводится", бля
"запорожец исправен, но не заводится", бля
DE
Тем более
Говоря про валидность/инвариант ООП-сущности мы говорим не про валидность полей формы, а про это.
Когда у любого объекта открыты только конструктор и методы, напичканные проверками на notEmpty, unique, inArray и т.п, всегда гарантирующими его согласованность. И поведение этих методов снаружи перепроверено юнит-тестами.
В итоге такой объект всегда контролирует себя. Присвоить ерунду или что-то в нём рассогласовать невозможно без хаков вроде рефлексии чисто физически.
Если у сущности есть только четыре метода, то это гарантия, что все программисты в проекте с ней работают только через них. Если два поля всегда должны меняться вместе, то меняем их одним методом. И никто в обход этого метода их неприсвоить не забудет.
Если все поля приватные и без прямых сеттеров, то можно эти поля внутри как угодно переименовывать/переносить не боясь, что какой-то сервис сломается.
В итоге имеем полный контроль над полями, полную предсказуемость поведения, самодокументированный интерфейс и возможность удобного юнит-тестирования логики методов.
А если сущность разрастается, то целесообразно разбить её по ответственностям на несколько мелких.
Когда у любого объекта открыты только конструктор и методы, напичканные проверками на notEmpty, unique, inArray и т.п, всегда гарантирующими его согласованность. И поведение этих методов снаружи перепроверено юнит-тестами.
В итоге такой объект всегда контролирует себя. Присвоить ерунду или что-то в нём рассогласовать невозможно без хаков вроде рефлексии чисто физически.
Если у сущности есть только четыре метода, то это гарантия, что все программисты в проекте с ней работают только через них. Если два поля всегда должны меняться вместе, то меняем их одним методом. И никто в обход этого метода их неприсвоить не забудет.
Если все поля приватные и без прямых сеттеров, то можно эти поля внутри как угодно переименовывать/переносить не боясь, что какой-то сервис сломается.
В итоге имеем полный контроль над полями, полную предсказуемость поведения, самодокументированный интерфейс и возможность удобного юнит-тестирования логики методов.
А если сущность разрастается, то целесообразно разбить её по ответственностям на несколько мелких.
2020 May 13
SP
Ну вот выше я привел кейс, когда это невозможно
кейс не оч понятный. Ты просишь модельку "сделай кой чего, только не делай... dry run типа"... ощущение что ты модельку на запись юзаешь и на чтение для каких-то мерзских своих задумок. Аля какой-то оч сложный и непонятный способ что-то проверить без каких-либо гарантий.
Словом, проблема с тем что это "не невозможно", это попросту не нужно. Вот этот флаг "dry run" не про то что бы не флашить, он про то что бы стэйт не менялся. А если стэйт не менялся то и от случайного флаша проблем не будет
Ну либо ты оч плохо описал свой кейс
Словом, проблема с тем что это "не невозможно", это попросту не нужно. Вот этот флаг "dry run" не про то что бы не флашить, он про то что бы стэйт не менялся. А если стэйт не менялся то и от случайного флаша проблем не будет
Ну либо ты оч плохо описал свой кейс
SP
ну а вот эти кул стори что "мы json мэпим на сущности и они не валидны а мы флашим" - ну кул стори да, это не про сущности, это про пишем json в базу. Не оч понятно для чего тут писать код когда есть варианты делать ровно то же без кода
DE
Окей, сущность валидная, но пришел от юзера месседж, что новые данные сущности сохранять не надо. При обработке месседжа ты забыл вернуть сущности первоначальные данные, случайно зафлашил ее. А юзер ожидает, что данные не зафлашены. В итоге, для него она не валидна получается )
Всё временное и невалидное сохраняем куда-нибудь массивом, JSON-ом или DTO в сессию или временную таблицу. И только когда юзер согласен уже создаём ему настоящую сущность по этим данным. Тогда и никаких "забыл/не то зафлашил/джуна недопроверил" вообще не будет.
A
Итого, чтобы написать 101 сервис, нужно будет держать в голове все 100 предыдущих, чтобы не нарушить инварианты сущности, проверку которых ты зачем-то на сервисы переложил?)
А чтобы добавить 101 метод в сущность, не надо держать инварианты?
SP
А чтобы добавить 101 метод в сущность, не надо держать инварианты?
101 метод у корня агрегата это что-то пошло не так
SP
коль уж мы в php чате, то еже ли мы прям так хотим что бы "весь стэйт был immidiate consistent" то лучше тогда пусть обмазываются сервисами и валидируют сущности/полагаются на предикаты в базе