Лапшекодим валидацию, или запрещаем вводить неправильные данные?
Странная ошибка - при редактировании есть после сохранения нет. Перезаписал.
У меня так тоже бывает.
Вы же сами видите, что на форме просто куча лишней и дублирующей информации (типа диапазона для возраста - и в названии поля, и в сообщении об ошибке). Для такой формы достаточно "поля со звёздочкой обязательны для заполнения".
Ещё интересно, что как раз, как я советовал, в названиях полей указаны допустимые интервалы и прочие подсказки. Человеку не интересно играть в вопрос-ответ с машиной. Его дико раздражает, когда очевидный фидбек приходит лишь после неправильных данных. Так же его раздражает читать портянку, написанную красным шрифтом. Всю эту писанину можно опустить, и оставить одну надпись, как я сказал и звёздочки. А ввести возраст вне диапазона поможет контрол, который просто не может принимать значения вне диапазона (офигеть рокет сайенс!). Валидация тогда будет проходить внутри контрола, без обращения к другим слоям. Причём валидация будет молчаливой - безо всякой красной мазни, знаков восклицания и красных портянок. А если кто-то не понимает, что "Пароль" и "Повторите пароль" должны совпадать, а "Возраст (от 18 до 70)" не позволяет ввести вне этого диапазона, то ему явно не нужно пользоваться вашим сервисом. Таким людям нужен помощник. Ну мало ли что, разные люди бывают - деменция там старческая, принципиальная жизненная позиция нигде и никогда не повторять пароли, ещё чего.
С паролем согласен - что-то нужно придумать. Скорее всего, тут нужна валидация (не обязательно в атрибутах). Можно, конечно, забайндить второе поле на первое, и проверять равность. Лучше, если это тоже всё будет внутри специального контрола инкапсулировано, чтобы не городить проверки в конвертерах, в модели или ещё где.
А как вы сделаете атрибутную валидацию повтора пароля? Ну чтобы добавил атрибут, типа [ConfirmationRequired], и всё само завертелось, без правки реализации IDataErrorInfo.
А как вы сделаете атрибутную валидацию повтора пароля?
точно также как и всё остальное
public string Password1 {get; set;}
[MustBeEqualValue(nameof(Password1), ErrorMessage="Two passwords must be equal")]
public string Password2 {get; set;}
...
var property = validationContext.ObjectType.GetProperty(_comparisonPropertyName); comparisonValue =(xxx)property.GetValue(validationContext.ObjectInstance) if (currentValue > comparisonValue) return new ValidationResult(ErrorMessage); return ValidationResult.Success;
Вот всю эту муру лучше бы внутри какого-то спецконтрола иметь. Я был бы не против атрибутов, если бы все портянки по работе с ними делались под капотом, автоматически и без моего вмешательства. А реализации каких-то дополнительных интерфейсов, возня с рефлексией - нафиг мне это надо? Я в атрибутах указал - пусть само берёт оттуда и валидирует.
В проектах ASP.NET MVC как-то это делается - там вы руками ничего не валидируете, интерфейсы не реализуете, а лишь прописываете атрибуты. Весь код валидации существует где-то в других библиотеках, о которых я могу даже не знать. Т.е. атрибуты там работают из коробки, а не конструктор "сделай сам".
все портянки по работе с ними делались под капотом, автоматически и без моего вмешательства
Ну после первого использования или создания либы так и происходит.
Если либы не нравится делать то это уже другая проблема.
По крайней мере, микрософту этот концепт нравится.
Почему в ASP.NET MVC смогли не парить мне мозги, а в других местах с этими же атрибутами нужна какая-то возня?
Не просто библиотеку заюзать, а как минимум указать ещё базовый класс с реализацией интерфейса. В ASP.NET MVC ничего не надо указывать и наследовать - прилепил атрибут, и он работает. Именно этого я от них и ожидаю. Я уже написал в атрибуте, что я хочу от модели. Даже сообщения об ошибках указал. Почему я должен снова сам в них внутрь лазить?
Просто команда ASP.NET MVC смогла накатать либку для автоматической валидации через атрибуты, а команда WPF забила. Она много на что забила. Да и МС сама на WPF давно забила.
Интересно, во всяких Blazor и MAUI тоже всё надо вручную делать, или они как-то подумали о разработчиках?..
Да и МС сама на WPF давно забила
А кто на впф еще не забил? Только те кому десктоп еще нужен.
во всяких Blazor
Да и МС сама на WPF давно забилаА кто на впф еще не забил? Только те кому десктоп еще нужен.
Только МС забила на ВПФ ещё лет 10 назад.
во всяких Blazorhttps://blazor-university.com/forms/validation/
Вот видите, как здорово - не надо врукопашную реализовывать всякие IDataErrorInfo. Прямо как в Razor Pages в ASP.NET MVC. Могут же, когда хотят.
Мне, пожалуйста, такое же в WPF, MAUI и остальных UI-фреймворках заверните.
А кто на впф еще не забил?
-----
Ну меня на последнем интервью спрашивали на предмет есть ли в активе...
Меня всё беспокоит эта ситуация. Вот добился ты типа всего, на Панамере по всяким деревням Гадюкино разъезжаешь... А всё равно как обычный рядовой Васян на поклон ко всяким девочкам-припевочкам на ресепшене ходишь. Я же себе на семи знаках это примерно так представлял:
Сидишь такой на террасе своего домика во Флориде, тебе звонит твой знакомый по прежним проектам и бизнесу - мол, хай, Алекс, не хочешь заработать лишний миллион? Я - почему бы нет. Что надо делать? - Да есть тут один проект. Надо его подшаманить. Серьёзные дяди деньги теряют, но хорошо заплатят, если успеешь быстро и качественно сделать. Сам понимаешь, вокруг одни идиоты, а таких как ты, семизнаков, мало. Выручай, брат! Бонусом пачка растущих акций впридачу. Ну ты такой конечно не отказываешь старому партнёру в услуге, тем более хорошо оплачиваемой. - No problemo, чувак. Но я ставлю свои сроки и хочу два миллиона. И плюс обязательные пончики с банановым кремом из одной нью-йоркской пекарни чтобы мне каждый день по спецзаказу подвозили - люблю я их. Запомни - свежие, из одной пекарни и именно с банановым - не вишнёвым. Это обязательное условие!
Только МС забила на ВПФ ещё лет 10 назад.
Ну не полностью
Сколько я этих планов видел. Вся эта поддержка - чисто для поддержания штанов старой технологии. Нового - ничего. Ну оно и понятно - сейчас у МС другие планы. Но 10-то лет назад такая же "поддержка" была - т.е. вообще голяк. После .NET Framework 3.5 на WPF считай забили.
Блин, снова эта валидация всплывает. Встречаю в коде такую лапшу:
- проверка, не пустое ли введённое значение - если пустое, то пишем сообщение об ошибке (типа "введите число");
- проверка через эксепшены, парсится ли введённое значение (типа метода int.Parse), и если нет - пишем сообщение об ошибке (типа "введите целое число");
- если парсится, то проверяем на неотрицательность числа - если отрицательное, то пишем сообщение об ошибке (типа "введённое число должно быть неотрицательным").
Вся эта лапша на десятки, если не сотни строк кода, куча сообщений об ошибках на все вкусы. Ещё и вся эта хрень логируется (ввёл пользователь отрицательное число - СРОЧНО В ЛОГ!) Я ещё удивился, а что так мало проверок и сообщений? Почему не минимум десять, например?
Мой вариант - пишем рядом с полем подсказку типа "значение должно быть целым неотрицательным" или ещё проще - диапазон (0 - 200) и дизейблим зависимые контролы, пока пользователь не введёт правильное число. И больше не пишем никаких сообщений об ошибках. Когда введёт правильное - енейблим контролы. ВСЁ! Проверки по сути те же самые, что и в первом варианте, с той лишь разницей, что мы не грузим пользователя бесконечными сообщениями на каждый неверный шажок и не лапшекодим менеджент всех этих сообщений. Разница в читаемости кода и понятности в разы... Единственный минус, что пользователи-олигофрены могут не понять - как это, мол, "введите целое неотрицательное число"? Поподробнее можно? Давайте я буду вводить буквы и знаки, а вы на каждый введённый символ мне кучку сообщений выдавать, чтобы я знал, где ошибся?
Я, конечно, понимаю, что некоторым прикольно сидеть и лапшекодить сотни строк на всю эту муйню - целый день был занят, один контрол закодил. И обязательно пачку юнит-тестов! А вто вдруг какое-то сообщение из десятка пропустил. И вот у нас пять экранов кода, которые делают, по сути, никуя, кроме как толкут воду в ступе... Смотрю на свой текущий проект - если весь этот олигофренский подход убрать и переписать, кодовая база на порядок уменьшится. Правда, команда тогда не получит по семь знаков на рыло (а фигли - серьёзный проект делали несколько лет индусским лапшекодом!) и не отъедет всем кагалом на пенсию в Майами. ))
