Я могу говорить только из опыта , а не , использующего полную платформу валидации, поскольку я просто придерживался того, что изначально предлагает WPF.
В моем проекте я реализовал интерфейс IDataError в своих классах сущностей / данных, а также реализовал частичный метод "OnValidate", который соблюдает Linq-To-Sql, а затем в качестве статических / общих членов классов сущностей, например, проверенные домашние помощники, которые предоставляют внутреннюю логику для реализации методов IDataError.Items и OnValidation.
Тогда это просто случай добавления ValidatesOnErrors = True, ValidatesOnExceptions = True ко всем привязкам, описанным в XAML. Конечный результат обнадеживает - способность WPF предоставлять визуальную обратную связь по недействительным данным хороша, а усилия по внедрению проверки минимальны.
Я бы посоветовал следовать тенденции сохранения логики проверки пользовательского ввода отдельно от вашей логики установки свойств. Иногда срок действия одного свойства зависит от состояния другого свойства. Сохранение логики проверки вне установщиков свойств позволяет создавать приложения, в которых конечный пользователь может вводить два значения, которые приводят к действительному состоянию, при этом ни один из отдельных установщиков свойств не отклоняет значения при их вводе.