Информация об изменениях

Сообщение Re[2]: Копипаст типов данных от 06.08.2021 17:39

Изменено 17.08.2021 0:57 VladD2

Re[2]: Копипаст типов данных
Здравствуйте, scf, Вы писали:

scf>Здравствуйте, rosencrantz, Вы писали:


R>>Я делаю вот так и мне очень стыдно:


R>>Самый настоящий копипаст со всеми вытекающими. Если надо что-то поменять, менять приходится в куче месте. Легко что-то пропустить, в итоге оно разъезжается и вылазят баги. Как вы боретесь с проблемой?


scf>Не копипастить. Структура БД не должна содержать бизнес-логику, поэтому констнейты в базе выбираются исходя из технических лимитов, а не бизнес. firstName varchar(256) not null


scf>Бэкенд делает полную валидацию и санирование данных, @MaxLength(100)


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

scf>А валидация на фронте — это обычный юзабилити, есть валидация — отлично, нет валидации — "server error: firstName length must be less or equal to 100"


Такая точка зрения имеет право на жизнь, но здесь многое от целевой аудитории зависит. На моей нынешней работе целевая аудитория глубоко не техническая и они от этого server error гарантированно отложат кирпичей, т.к. ожидают, что в процессе заполнения формочки им сразу скажут где что пропущено, а когда всё будет верно, разблокируют кнопку "отправить" и напишут "да умничка ж ты моя". Можно воспринимать как такой внутренний стандарт.

scf>Совместить бэковую и фронтовую валидацию многие пытались, но имхо это непрактично. Самое продвинутое из практичного — сервер возвращает результаты валидации на клиент в json по каждому полю на языке пользователя.


Пробовал делать почти так — только вместо языка пользователя — именованные коды правил ошибок на каждый аттрибут, а на фронте — маппинги от этих кодов к человеческим объяснениям. Много возни и вот эта вот необходимость всё вбить с ошибками, а потом нажать сабмит, потом только получить объяснение где ты неправ — так себе юзабилити.
Re[2]: Копипаст типов данных
Здравствуйте, scf, Вы писали:

scf>Бэкенд делает полную валидацию и санирование данных, @MaxLength(100)


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

scf>А валидация на фронте — это обычный юзабилити, есть валидация — отлично, нет валидации — "server error: firstName length must be less or equal to 100"


Такая точка зрения имеет право на жизнь, но здесь многое от целевой аудитории зависит. На моей нынешней работе целевая аудитория глубоко не техническая и они от этого server error гарантированно отложат кирпичей, т.к. ожидают, что в процессе заполнения формочки им сразу скажут где что пропущено, а когда всё будет верно, разблокируют кнопку "отправить" и напишут "да умничка ж ты моя". Можно воспринимать как такой внутренний стандарт.

scf>Совместить бэковую и фронтовую валидацию многие пытались, но имхо это непрактично. Самое продвинутое из практичного — сервер возвращает результаты валидации на клиент в json по каждому полю на языке пользователя.


Пробовал делать почти так — только вместо языка пользователя — именованные коды правил ошибок на каждый аттрибут, а на фронте — маппинги от этих кодов к человеческим объяснениям. Много возни и вот эта вот необходимость всё вбить с ошибками, а потом нажать сабмит, потом только получить объяснение где ты неправ — так себе юзабилити.