Лапшекодим валидацию, или запрещаем вводить неправильные данные?
Т.е. это не проблема.
ну вот как назвать поле в котором список разрешенных символов для контрола?
А атрибуты валидации
А атрибуты вываливаются по подсказке и после выбора атрибута сразу известны его параметры.
Поэтому и придумали контролы типа NumericUpDown со свойствами Min и Max
А проперти для связи с ними хто придумаль? 
Ctrl+Shift+F
А зачем вообще что то искать? Да и что именно?
Приводить в качестве минуса мисклик какого-нибудь программиста - передёргивание.
вообще то это минусы дополнительной работы.
В вашем случае надо не забыть
Блин, ну ничего не надо делать каждый раз для новой формы. Один раз делается и потом только используется.
Вы так и не сказали, как будете атрибуты модели прокидывать во вью модель.
Это пусть рассказывает тот, кто считает, что это нужно делать 
Вы так и не сказали, как будете атрибуты модели прокидывать во вью модель.Это пусть рассказывает тот, кто считает, что это нужно делать
Как вы будете в этом коде доставать атрибуты модели, если класс - во вью модели? Варианты есть - один другого лапшекодинговее, но меня интересует, как именно вы будете это делать.
доставать атрибуты модели
Вообще то нет интереса и времени писать код согласно требований.
Как пример, которому не обязательно нужно подражать
https://www.codeproject.com/Articles/97564/Attributes-base...
http://danielvistisen.com/validate-using-attributes-in-mvv...
И даже немного по другому
https://www.engineeringsolutions.de/validation-in-mvvm/
https://stackoverflow.com/questions/19498485/proper-valida...
Вы, похоже, не понимаете, что я имею ввиду. Все ваши примеры - это валидация на стороне вью модели. А атрибуты обычно устанавливают для модели. По всем вашим ссылкам авторы пишут MVVM, но модель куда-то у них подевалась.
Вот классическая статья от одного из первых авторов по WPF и MVVM, и в этой идее валидации изначально была реализация IDataErrorInfo в обоих слоях (модель и вью модель), при этом на каждом своя валидация. Обратите внимание на объект _person там - это переменная для хранения модели во воью модели. При присваивании свойству Age вью модели значения, сначала проходит валидация вью модели, затем идёт присвоение свойства модели, и там происходит своя валидация. По вашим ссылкам авторы всё упростили и извратили, забыв про модель - а нафига она им вообще нужна тогда? Ваши авторы фигачат атрибуты прямо для вью модели и называют это MVVM. С таких подходом им не нужна модель. Ну или роль модели у них выполняет вью модель. Так тоже можно, но это не MVVM. А они просто засоряют мозги неадекватными названиями себе и другим.
Для такой валидации как в ваших статьях, вам нужно кинуть ссылку на модель в базовый класс вью модели, где у вас реализован интерфейс IDataErrorInfo и где проходит валидация. А так как модель может быть любым типом, надо делать базовый класс дженериком, и чтобы параметр типа этого дженерика реализовывал какой-то валидирующий интерфейс, и это будет не IDataErrorInfo, а что-то с методом Validate - чтобы чтобы однообразно вызывать валидацию модели для любого типа модели. Без базового класса вы будете писать портянки валидации для каждого класса отдельно. В результате что в ваших примерах, только реальных, а не висящих в воздухе, что в подходе Джоша Смита - куча лапшы, переусложнённые модели (и вью модели) с параметрами типов. А в ваших примерах, в отличие от Джоша Смита, ещё и рефлексия вовсю дёргается.
А в моём подходе вы всё храните в свойствах, пробрасываете свойства модели во вью модель сразу, без преобразований, вам не нужен никакой интерфейс, вам не нужна базовая модель с валидацией, вы не испольузете дженерики, а вы сразу привязываете свойства и их ограничения к правильным контролам. И даже если вы не используете MVVM по факту, а всё делаете в одной модели, то хранить все ограничения в свойствах тоже лучше, чем в атрибутах.
Где-то надо использовать и атрибуты, но явно не в формошлёпстве с вышеописанными переусложнениями. IDataErrorInfo - это усторевший в формошлёпстве многословный интерфейс, как и всякие портянки валидирующих правил в разметке. Можно обойтись и без всего этого, если применять правильные инструменты.
Другое дело, если у вас приложение куда более сложное, чем три слоя MVVM, или MVC, или MVP. Тогда, возможно, вам стоит держать что-то в атрибутах, делать валидацию на каждом слое (мы не доверяем данным, передаваемым между слоями, например) и т.п. Но тут, где просто MVVM, писать такие простыни и реализовывать громоздкий IDataErrorInfo - это оверхеад. При этом ещё и упрощать во всех примерах M-V-VM до банального V-VM. Во втором случае вообще непонятно, нахрена все эти портянки.
Ещё я иногда для модели использовал атрибуты, но во вью модели доставал из них значения и сохранял в свойствах, которые и привязывал к контролам. Т.е. валидацию не использовал, а атрибуты использовал лишь как контейнеры для хранения валидационных данных. Точнее, валидация происходила в самих контролах.
Главное, не забыть, что это лишь один из подходов, и в случае возвращения к валидации через атрибуты непосредственно, не забыть реализовать интерфейс IDataErrorInfo, т.к. сами атрибуты ничего не валидируют. Я вот забыл и недоумевал потом - а чего это сообщений об ошибках нет, хотя в атрибутах всё установлено.
авторы пишут MVVM, но модель куда-то у них подевалась.
Вообще то хорошо бы вначале немного почитать о MVVM паттерне
https://stackoverflow.com/questions/3372939/is-it-ok-to-ha...
https://docs.microsoft.com/en-us/archive/msdn-magazine/200...
А после рассказать как будем обходится без сообщений в данном случае (И какие проперти будем добавлять?)
Можно обойтись и без всего этого, если применять правильные инструменты.
Безусловно, зачем нам эта тормознутая студия, когда в notepade всё так просто
А после рассказать как будем обходится без сообщений в данном случае (И какие проперти будем добавлять?)
Я тоже могу сказать, что не надо воспринимать всё и всегда буквально. В частности, эта картинка для дебилов - ну вдруг найдутся люди, которые не понимают, а чего это кнопка "Save" не нажимается, если я все поля пустыми оставляю. Написано тут всё лишь для иллюстрации, как можно использовать валидацию. А можно было бы не писать под каждым полем свой текст, а написать один общий для всей модели - "все поля должны быть заполнены". Или "обязательные для заполнения поля отмечены звёздочкой". И такой текст может быть вообще общим для всех моделей приложения, поэтому его можно затолкать в общие локализованные ресурсы под одним ключём. И эта одна запись - всё, что нужно будет для сообщений валидации во всём проекте.
Но можно, конечно, и выписывать простыни пояснений под каждым полем.
Я предлагал другой вариант - рядом с названием поля в скобках или ещё как писать, какой диапазон, какая длина строки позволены и прочее. Т.е. чтобы сразу видел пользователь, что можно, а что нельзя. И эту инфу можно положить в виде обычного свойства рядом с тем свойством, которое оно описывает.
Стремление всё затолкать в атрибуты - это такая детская болезнь максимально заюзать все новые модные фичи. Даже там, где они лишние. Вот например есть атрубит Display, где отображается свойство DisplayName. Почему это не может быть дополнительным свойством? - Может. У того же Джоша Смита в старых статьях по MVVM это и отображено в обычном свойстве. Но кому-то надо обязательно всё в атрибуты запихать.
Обычные свойства и атрибуты - суть одно и тоже. И там, и там хранятся какие-то данные, мы их достаём. Только с атрибутами работать сложнее и медленнее по производительности. А ещё они требуют громождения вокруг себя инфраструктуры.
Вот зачем вам, например, свойства объекта выписывать, если можно навешать атрибутов TypeProperty над объявлением класса и всё?
Или другой пример - перечисления. Можно навешать кучку атрибутов над каждым элементом перечисления - язык это позволяет сделать. А можно написать класс, где будет храниться свойство с перечислением и данные, которые раньше были в атрибутах, только теперь в виде свойств. Вам какой подход больше нравится:
enum Rarity
{
[Display(...)]
[Properties(Prop1 = ..., Prop2 = ..., ...)]
Common,
[Display(...)]
[Properties(Prop1 = ..., Prop2 = ..., ...)]
Uncommon,
...
}
class Rarity
{
Rarity Rarity { get; set; } // здесь это другое перечисление - без атрибутов
string Name { get; set; }
string DisplayName { get; set; }
... Prop1 { get; set; }
... Prop2 { get; set; }
...
}
чего это кнопка "Save" не нажимается
Я тоже могу сказать, что не надо воспринимать всё и всегда буквально
Не обязательно всё поля должны быть пустыми и на смартфоне обычно поля не помещаются все на экран.
А подобный вопрос пользователи задают очень часто. Помню был на нескольких сайтах,. а фиг его знает отчего дальше не пускает. Так и ушел.
И такой текст может быть вообще общим для всех моделей приложения
Страшно хочу увидеть общий текст для этого диалога
Стремление всё затолкать в атрибуты - это такая
А стремление затолкать всё в свойства это тогда что?
Вот например есть атрубит Display, где отображается свойство DisplayName. Почему это не может быть дополнительным свойством?
У меня приличных слов просто
уже не хватает. 
Кричать о модели и заявлять подобное...
Обычные свойства и атрибуты - суть одно и тоже
Я не могу это уже комментировать - мурка ты где?
А можно данный пример с готовым кодом?
А то болтать можно долго и нудно о преимуществе пропертей.
Очень интересует связка и заполнение между Rarity.Common и Rarity.DisplayName допустим при реализации комбобокса
https://brianlagunas.com/localize-enum-descriptions-in-wpf...
...
Нашел похоже http://oopbase.de/posts/localizing-enum-values-in-an-enter...
На какой вариант будет кричать ура! мой!
А это немедленно в Лувр - как самое удачное решение - сокровищница мирового искусства программирования
new UserModel(Gender.Female, "Anna"),
new UserModel(Gender.Male, "Scott")Очень интересует связка и заполнение между Rarity.Common и Rarity.DisplayName допустим при реализации комбобокса
https://brianlagunas.com/localize-enum-descriptions-in-wpf...
...
Нашел похоже http://oopbase.de/posts/localizing-enum-values-in-an-enter...
Когда Rarity это класс, то надо где-то создать коллекцию объектов этого типа - тогда будет полное соответствие enum Rarity.
Чего это челы по вашим ссылкам изобретают велосипеды, когда уже давно есть готовый описательный атрибут с локализацией в Дотнете? И он там лет 10, наверное, уже есть. Минимум.
https://docs.microsoft.com/en-us/dotnet/api/system.compone...