Лапшекодим валидацию, или запрещаем вводить неправильные данные?
Надеюсь, вы не будете привязывать AgeMin к NumericUpDown.Max и наоборот?
Тоже может быть как и не не то поле. Еще и найти нужно куда привязывать.
Как раз с подключением проблемы могут быть в вашем подходе
Явно опять извращенное понимание действительности.
Кроме добавления атрибута не нужно делать больше ничего 
кстати, по стилю на каждый тип контрола надо добавлять
Не нужно работать обезъяной и копировать всё что видно в рабочий проект
Потому что этот подход используется для тупейших контролов
Видимо я зря давал ссылки на дев экспесс и телерик
Какой-то кастомный атрибутЭто было один к одному что тулза делает можно и так
[DisplayName("My sample text")]--> [DisplayName(Translate(1, "My sample text"))]
Что за тулза? Чего вы всё время недоговариваете? )))
У вас кастомный атрибут с делегатов в параметрах конструктора?
У меня всё честно и открыто - вот список пропертей, вот контролы. Привязываем просто и без дополнительных костылей. А у некоторых помидоры примерно так объясняют, как работает их новый фреймворк.
А интеллисенсе куда завернем?
А сколько всего нужно дописать чтобы добавить новое правило?
Куда заворачивать, какое правило? Вы чего?
MyField
MyFieldMin
MyFieldMax
NumericUpDown
Value={Binding MyField}
Min={Binding MyFieldMin}
Max={Binding MyFieldMax}
Всё. Не надо никаких сообщений об ошибке, не надо подсветок, не надо валидирующих правил, не надо конвертеров, не надо реализаций дополнительных интерфейсов, не надо тормозов с выполнением портянки с рефлексией НЕСКОЛКЬО РАЗ на каждое срабатывания привязки. Ведь если привязка прошла валидацию, значит для всех свойств всех атрибутов каждого свойства выполнилась эта портянка. И это происходит на каждое срабатывание байндинга, повторюсь. Вы курсор в поле ткнули, символ ввели, а у вас уже куча событий произошла. И часто байндинг по 2-3 раза лишь за эти короткие действия срабатывает. Дарю Мурру идею - меняем ваш подход на мой и пишем в заслугах - ускорил прогу в 30 раз.
Всё это отобразится интеллисенсе из коробки.
Ваш юзер, который спросит, а чего это я не могу больше и меньше определённых значений ввести - он и вашим сообщениям об ошибке возмутится. Хочу мол ввести и всё тут.
Но если прямо хочется дать инфу юзеру, в каких диапазонах вводить, то лучше это делать не после ввода во всплывающем тултипе (самый дурацкий, тормозной и раздражающий способ), а сразу дать понять перед вводом, в каких диапазонах будет валидное значение. Я иногда делаю такой лейбл перед полем ввода:
DisplayName = $"{MyFieldName} ({MyFieldMin} - {MyFieldMax}):"
TextBlock Text={Binding DisplayName}
Т.е. лейбл будет выглядеть примерно так:
Параметр (0-100):
Тут я сразу вижу, что и сколько могу ввести, а не пишу наугад, жду тормозной тултип и вчитываюсь в мелкий серый текст на белом фоне (дефолтный стиль для тултипов), который ещё и через 5 секунд исчезает автоматически.
Кроме добавления атрибута не нужно делать больше ничего
С какой стати? А лапшу в вашем же примере кто будет писать, как и наследовать все модели от базового класса с этой лапшой? А во вью модель из модели как перетаскивать эти атрибуты? А сериализация? Где весь обслуживающий код для задач реального приложения?
Мой подход - представьте себе мир безо всей этой муры.
Куда заворачивать, какое правило? Вы чего?
Очень ломит объяснять всё в подробностях как первокласснику.
Validation rule - так понятнее?
Нужно добавить минимум (1)
MyFieldMin
MyFieldMax
При этом кто как будет называть суффиксы для других правил и какие вообще правила существуют дело темное.
и (2) При этом во все формы которые еще нужно найти. Как уже говорил, ошибки ввода попадаются
Min={Binding MyFieldMin}
Max={Binding MyFieldMax}
Не надо никаких сообщений об ошибке, не надо подсветок, не надо валидирующих правил
Не надо рассматривать какой то конкретный случай и рекламировать его как золотую пулю. Не кажется странным, что все остальные такие тупые и до подобного метода никак не додумались?
Когда то действительно хорошо без ошибок, типа в цифровое поле поле вводить только цифры.
жду тормозной тултип
Если кто то делает сообщения об ошибке в тултипе то это не означает что так делают все.
Важна именно система. И для системы ручные проперти никак не подходят.
А лапшу в вашем же примере кто будет писать, как и наследовать все модели от базового класса с этой лапшой?
Не нужно думать только в одном направлении.
Система пишется/покупается один раз а после только используется.
А сериализация?
А в чем проблемы сериализации данных? Хот и не вижу смысла делать это для UI модели.
Как раз то в вашем подходе будет очень много мусора.
Мой подход
Да пожалуйста, делайте сколько хотите, главное чтобы подальше от нас было.
При этом кто как будет называть суффиксы для других правил и какие вообще правила существуют дело темное.
А атрибуты валидации у вас стандартизированы, чтоли? Только если вы прикажете по фирме не использовать что-то не из установленного набора. Есть МСовская поставка, и есть куча сторонних, плюс самописные.
Покажите мне, кто не понимает, что такое Min и Max. А ещё есть люди, которые не знают, что означает префикс подчёркивания перед полем. Да мало ли кто каких соглашений не знает. Придёт на фирму - узнает, как на этой фирме делается. Т.е. это не проблема.
Не кажется странным, что все остальные такие тупые и до подобного метода никак не додумались?
Не кажется. Поэтому и придумали контролы типа NumericUpDown со свойствами Min и Max, и тому подобные. Я же их не от фонаря в пример приводил.
и (2) При этом во все формы которые еще нужно найти
Ctrl+Shift+F, ограничение по типу файлов .xaml - и вот вам все упоминания свойства.
Как уже говорил, ошибки ввода попадаются
Типа когда минимум максимуму присвоил или наоборот? Приводить в качестве минуса мисклик какого-нибудь программиста - передёргивание. Вы и в атрибуте можете минимум с максимумом перепутать. До выполнения кода ничего мне не мешает написать так
[Range(2.0, 1.0)]
Только после выполнения у вас сработает валидация и вывалится исключение. У меня Студия 2019 для .NET 5 не показывает ошибок при компиляции.
Единственное, с чем могу согласиться - атрибуты валидации это уже готовая валидация. Вам не надо писать свой код. А в моём случае надо написать самому проверку попадания значения между свойствами Min и Max. Но как я уже писал, если применять правильные контролы и изначально не допускать приход неверных значений, то можно и без этой проверки обойтись.
С другой стороны, атрибутами все случаи не покроешь. Поэтому у вас будет частично атрибутная валидация, частично кастомная - либо дополнительные проверки в реализации IDataErrorInfo, либо самописный атрибут.
И отчего бы не написать просто так?
NumericUpDown
Value={Binding MyField}
Min=0
Max=10
А что мешает так написать?
[Range(10, 1000, ErrorMessage = "Все оно, а я конфетка!")]
В вашем случае надо не забыть реализовать IDataErrorInfo (или отнаследоваться от базового класса с его реализацией), прикрутить стили с сообщениями об ошибках, и так - на каждую модель. Вобщем, в вашем случае целый список, что нужно сделать. А вы мне говорите, что человек забудет привязать границы и захардкодит их.
Вы просто не open minded и не пробовали сделать, как я говорю. А я пробовал и так, и так. И возьба с атрибутами меня не вдохновляет. Пока не будет нормального простого интерфейса для вытаскивания данных из них, а не портянки с рефлексией и указанием кучи данных из перечислений по типам свойств (ещё поди разберись, какие сочетания правильные).
Вы так и не сказали, как будете атрибуты модели прокидывать во вью модель.
А вообще, валидация пользовательского ввода должна быть максимально жёсткой. Т.е. нужно не валидировать постфактум, а вообще не давать пользователю вводить неправильные данные. Держать его, так сказать, в ежовых руковицах. Ну это как банкоматы - тупые и железные, с железными кнопками, чтобы ничего не сломалось. Максимально ограничить свободный ввод. По-возможности давать выбирать лишь из готовых выпадающих значений. В банкоматах можно вводить лишь цифры и несколько знаков. Никаких печатаний "Kontostand" и тому подобного вручную - только выбор из предлагаемого меню, тыкание цифры.
Вот есть на экране одна кнопка "Сделай мне круто!". Её можно нажать, а можно не нажимать. Валидация простейшая - её тупо нет. Что может пойти не так?
Validation rule - так понятнее?
-----
Не-не, надо сделать... правильно...
Мин и Мах - это - не правильно! Это всего один регион!
Надо нарисовать произвольное количество регионов в которое может входить значение!!!
Для начала - штук 200... т.е. дописываем 400 полей для одного поля данных и думаем над проблемой как их добавить в ран-тайме! 