Но она неправильная. Простую валидацию реквеста все равно надо делать

Просто идея валидировать данные с помощью во сладка и манит

☺️

В хорошем приложении ошибки уровня несоотвествия данных для во, не должны происходить

Но она неправильная. Простую валидацию реквеста все равно надо делать

я делаю валидацию реквеста при помощи этого класа https://github.com/Wixel/GUMP

Вот тут я страниц двадцать на тему валидации уже написал. В январе надеюсь выложу.

https://leanpub.com/architecture-of-complex-web-applications

Вот тут я страниц двадцать на тему валидации уже написал. В январе надеюсь выложу.

есть два слоя...в каком валидировать данные?)

Данные валидируются в куче мест и в куче слоев

есть два слоя...в каком валидировать данные?)

Во всех)

Начиная от электрического сигнала в сетевухе, который валидируется кодами хемминга

В каждом своя. Валидация в vo обычно повторяет валидацию веб запроса

Во всех)

а ты хорош)

В каждом своя. Валидация в vo обычно повторяет валидацию веб запроса

нет же валидации в vo)

Всякие ларавельки дают возможность лезть прям в базу в валидации запроса...

нет же валидации в vo)

Иммутабельность, всегда валидный (это главное)

нет же валидации в vo)

VO money не должно дать себя создать с отрицательной суммой. Это тоже типа валидация. Внутренняя

Иммутабельность, всегда валидный (это главное)

уооот

В каждом своя. Валидация в vo обычно повторяет валидацию веб запроса

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

нет же валидации в vo)

VO - должен быть всегда валидным, если мы создаем объект, значит мы уверены в достоверности данных

VO money не должно дать себя создать с отрицательной суммой. Это тоже типа валидация. Внутренняя

ну не клади туда отрицательную сумму и не создавай его

ну не клади туда отрицательную сумму и не создавай его

Я и не кладу. Проверяю в реквеста на положительность

Вот и получается некое дублирование валидации

Но это нормально

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

Я и не кладу. Проверяю в реквеста на положительность

потому что есть S в solid и vo сделан не для валидации?

потому что есть S в solid и vo сделан не для валидации?

Ты предлагаешь не проверять на положительность в money?

Ты предлагаешь не проверять на положительность в money?

в vo точно не нужно, на мой взгляд

Ну тут мы расходимся

В большом проекте кто-то по-любому не проверит и полетят невалидные данные

Во могут создаваться много где

Просто идея валидировать данные с помощью во сладка и манит

вот жеж)

В большом проекте кто-то по-любому не проверит и полетят невалидные данные

?

в vo точно не нужно, на мой взгляд

Представь у тебя API для сбебанка)

ну в php могут и контрактом брезговать разные.. минусы в карму им..что теперь)

Смотри. Валидация в во есть. Но если вдруг туда попали невалидные данные - это значит кто-то в коде ошибся

Т.е. Это валидация не юзерских данных а кода который должен был отвалидировать

и vo не место, где мы должны это понять. Вот там где мы их возьмём оттуда, там и поймём

Я не хочу вычищать бд от невалидных данных

слава богу валидация и в других слоях есть

Я не хочу вычищать бд от невалидных данных

ну тут я согласен, невалидные данные не должны попадать в БД. Но что значит валидные данные, если смотреть со стороны БД?

Ничего. Домен только понимает что в поле percent должно быть от нуля до ста

Ты предлагаешь не проверять на положительность в money?

отрицательное money это признак того, что кто то украл деньги из кассы например )

А в поле email не просто строка а мыло

отрицательное money это признак того, что кто то украл деньги из кассы например )

Шуточки всякие. Серьезную тему же обсуждаем!

в vo точно не нужно, на мой взгляд

vo нельзя создавать с невалидным состоянием

)

vo нельзя создавать с невалидным состоянием

+1

Шуточки всякие. Серьезную тему же обсуждаем!

я не шучу, деньги бывают отрицательными (

vo нельзя создавать с невалидным состоянием

я о том же. если данные не валидны - не создавай

Вы кажецца путаете уровни валидации

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

я не шучу, деньги бывают отрицательными (

Ну ладно. От домена зависит, но я против отрицательных денег

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

про это просто никто не говорит, но все это понимают)

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

Вот кстати да, вот только я хорошего примера не смог найти в своё время

Ну ладно. От домена зависит, но я против отрицательных денег

я тоже против, но они бывают в реальном мире

я тоже против, но они бывают в реальном мире

Смотря как построить модель предметной области

Вот кстати да, вот только я хорошего примера не смог найти в своё время

Можно легко придумать не очень реалистинчый но валидный пример. Допустим один пользователь в интернет магазине может купить только один товар и всё. userId=1 купил товар fooId=1 и в базу записалась реляция (1;1). Потом он жмет купить товар fooId=2. В системе при работе появляется VO со полями {userId:1, fooId:2}. Эти данные валидны с точки зрения VO, но невалидны с точки зрения бизнес логики, так как такой пары не может существовать.

И когда этот VO дойдет до валидатора логики, то станет ясно что в базе уже есть (1;1) и VO будет признан ошибочным.

В такой схеме сам VO конечно не должен в базе проверять что нет уже заказа.

Можно легко придумать не очень реалистинчый но валидный пример. Допустим один пользователь в интернет магазине может купить только один товар и всё. userId=1 купил товар fooId=1 и в базу записалась реляция (1;1). Потом он жмет купить товар fooId=2. В системе при работе появляется VO со полями {userId:1, fooId:2}. Эти данные валидны с точки зрения VO, но невалидны с точки зрения бизнес логики, так как такой пары не может существовать.

точно так же как и отрицательные деньги

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

и место этому валидатору, на мой взгляд, не в VO. Иначе принцип описанный выше, рушится

хоть и очень хочется)

Ну если у тебя в системе нигде вообще не должно существовать отрицательных сумм, то можно и это в VO проверять

наверное тогда лучше создать объект, который не INT, а какой то диапазон, и его уже передавать в VO

VO создает фабрика, может эванса почитаете?!

и относиться к такому значению не как к int, которое может иметь отрицательное значение, так как это не простой int, ну или что там для денег))

VO создает фабрика, может эванса почитаете?!

это что то меняет?)

unsigned тип и все. Че вы тут нагородили хз)

unsigned тип и все. Че вы тут нагородили хз)

мы тут про валидацию не на уровне БД)

мы тут про валидацию не на уровне БД)

Это нужно только чтобы не досить базу, а типы должны проверяться на её уровне.

Это нужно только чтобы не досить базу, а типы должны проверяться на её уровне.

ну тык)

ну тык)

Нужен ЯП с нормальной типизацией, но лучше не валидировать, просто закрыть доступ пользователям и спать спокойно.

Нужен ЯП с нормальной типизацией, но лучше не валидировать, просто закрыть доступ пользователям и спать спокойно.

лучший вариант) но за это денег не платят)

Это нужно только чтобы не досить базу, а типы должны проверяться на её уровне.

Олдскульщики подъехали )

Это нужно только чтобы не досить базу, а типы должны проверяться на её уровне.

Это как?

Это как?

Что именно как? Просто ограничивать тип и его точность/округление на уровне базы. В нормальных бд есть расширения дающие беззнаковые типы с подходящим округлением если речь о деньгах.

Можно конечно и на уровне орм ограничивать, либо миграции, если фреймворк используется, но это все фигня уже

Можно конечно и на уровне орм ограничивать, либо миграции, если фреймворк используется, но это все фигня уже

Да не фигня, сойдет

Олдскульщики подъехали )

Тут фигня в том, что доки устаревают, разработчики увольняются, тесты писать лень, а людям свойственно совершать ошибки. Т. е. Валидация на уровне кода - обязательно сломается. Потому если продукт будет поддерживаться иного пути нет.

Да не фигня, сойдет

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

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

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

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

Так и пилим ?

Так и пилим ?

А почему топчешь нашу радугу и всех пони уже распугал)

Мне нравится куда идет пхп, особенно когда я только пресс релизы читаю, стараюсь быть в курсе)

Мне нравится куда идет пхп, особенно когда я только пресс релизы читаю, стараюсь быть в курсе)

Ну хоть кто то их читает))

Что именно как? Просто ограничивать тип и его точность/округление на уровне базы. В нормальных бд есть расширения дающие беззнаковые типы с подходящим округлением если речь о деньгах.

о, а потом пол копейки после такого ограничения точности очень сложно искать.

Привет, ребят

Да, я пью

И развлекаюсь

Так что джмми джефриз говорит, что все крутго

Короче, я хреновый шутник

чатик перепутал?

Не, у нас надо шутить

Это ты перепутал

Выгони меня, Лех)

А точно

Ты не можешь)