Тут статья на Хабре вышла. Собственно, уже не раз о подобном говорили. И там с первых же комментов идёт предложение вариантов.

Я вот делаю так - на уровне доменной модели прописываю всю валидацию через атрибуты Range и т. п. Затем, если надо валидацию на модели в другом слое - делаю в моделях этого слоя свойства, аналогичные атрибутам. Т. е. если доменная модель была




то модель представления, например, будет




Почему я заюзал отдельные свойства для каждого свойства атрибута, а не сами атрибуты вкорячил в модель представления? Потому что работа с атрибутами в C# - боль. Я, конечно, написал себе хелперы для вытаскивания атрибутов, по типу такого



но это я использую при инициализации модели представления - достаю из атрибутов модели эти данные и присваиваю свойствам модели представления. В противном случае пришлось бы копировать атрибуты модели в атрибуты модели представления (та ещё морока), а затем в представлении вытаскивать атрибуты модели представления через конвертеры. Только конвертеры будут отрабатывать всякий раз при изменении занчения в контроле, а мой способ - только один раз при инициализации модели представления.

Ну а и далее валидация в модели представления. В WPF всё просто - юзаем контролы, в которых уже валидация встроена - всякие




Т. е. логику валидации на клиенте дублировать не надо - всё уже встроено в контрол, которому надо просто привязать соответствующие поля в соответствующие свойства.

С вебом также - не надо юзать голый HTML. Надо юзать продвинутые контролы. Тогда не будет надобности дублировать логику валидации в виде простыни кода, который копипастят по всем слоям, а потом забывают обновлять, если где-то в одном месте изменили. Если нет продвинутых HTML-javascript-контролов, то да - придётся писать самому эту кучку джаваскрипта для валидации.

Т. е., ещё раз - правильно валидировать на слоях:

1) юзать валидацию, разбитую на атомарные операции (типа валидация минимума, валидация максимума, валидация формата и пр.), и при этом каждая такая операция - в собственном классе, как приведённые атрибуты. Ну а то, что эти классы - атрибуты - просто такой удобный вариант исполнения. Удобно на модели атрибуты расставлять, а не заполнять методы типа Validate простынями кода, как в статье в примере;

2) юзать продвинутые контролы, в которые такая атомарная валидация (т. е. валидация по каждому аспекту, вынесенная в отдельный блок кода - класс) встроена и работает на их свойствах. Тогда остаётся только просто достать свойства из модели и присвоить их нужным свойствам контрола;

3) юзать модели для каждого слоя, в которых валидируемые параметры представлены в виде свойств (как у меня выше в примере LengthMinimum и т. п.) или тоже атрибутов (этого я в примере с Length не показал). При этом эти свойства заполняются из первоначальной доменной модели - т. е. вытаскиваем из неё максимумы, минимумы, шаблоны форматов в виде регулярок или там текстовых масок и прочее.

Что скажете и как делаете вы?

авторЕсли нет продвинутых HTML-javascript-контролов, то да - придётся писать самому эту кучку джаваскрипта для валидации.
Но, опять же, вытаскивать параметры валидации (максимум, минимум и т. п.) из доменной модели. А для этого сначала перенести эти параметры из доменной модели в модель представления. Вот что я имел ввиду.

автор1) юзать валидацию, разбитую на атомарные операции (типа валидация минимума, валидация максимума, валидация формата и пр.), и при этом каждая такая операция - в собственном классе, как приведённые атрибуты. Ну а то, что эти классы - атрибуты - просто такой удобный вариант исполнения. Удобно на модели атрибуты расставлять, а не заполнять методы типа Validate простынями кода, как в статье в примере;
Тут вот в чём штука. Автор в статье гонял код валидации по всем слоям копипастой. Но дело в том, что валидация, разбитая на атомарные операции представляет из себя скорее значения параметров валидации, а не сами действия и код проверки. Например, LengthMinimum всегда будет проверяться кодом типа

if (Length < LengthMinimum)

Т. е. именно на меньше, а не на больше или равно (для включающего интервала - т. е. для меньше или равно - надо заводить атрибут LengthMinimumOrEqual - т. е. собладать принцип атомарности). Поэтому нет смысла инкапсулировать сам код проверки в методах типа Validate, как у автора статьи. Достаточно инкапсулировать только параметры атомизированной валидации. Поэтому атрибуты, в которых в свойствах хранятся такие параметры, а сама логика - инкапсулирована в их коде как в отдельном классе, подходят для этого лучше всего.

Т. е. выносить валидацию в отдельный метод Validate, где писать простыню кода валидации (т. е. мешать всё в кучу, без атомарности - без разделения каждого аспекта валидации) - это устаревший подход и годится только в специфических случаях, когда валидация на атрибутах невозможно или слишком затруднена. Ну или когда не охота заморачиваться написанием полноценных моделей для слоёв и надо всё по-быстрому на коленке запиндюрить.

Подход автора статьи - вынесение валидации в некий атомарный объект Email. Плохо то, что если потребуются разные логики валидации, придётся либо городить два разных типа (Email и EmailWithSpecificValidation), либо расширять Email всякими параметрами. Кроме того, придётся расшарить тип Email между всеми слоями - даже между теми, где валидация не требуется. Ну и сам объект со свойством Email тоже надо будет расшарить на все слои с валидацией.

С атрибутами же подход вернее - выделяются на валидируемые объекты, а сама валидация.

Где-то в степиWebtester88,
все зависит от мечпохи работы с объектами, посмотрите как сделан IValidatable в хибернате, был там интерфейс и
реализующий beforeInsert() afterInsert() ( рыться не охота)
Что за выделенное слово?

Т. е. Хайбернейт вводит свой интерфейс, вместо того, чтобы использовать уже готовый в общеупотребительном фреймворке? Или как?

Я либо должен этот IValidatable на все модели с валидацией распространить, либо таки в методах beforeInsert и т. п. использовать таки свою доменную долику валидации. Я предпочитаю последний подход.

Где-то в степиWebtester88,
все зависит от мечпохи работы с объектами, посмотрите как сделан IValidatable в хибернате, был там интерфейс и
реализующий beforeInsert() afterInsert() ( рыться не охота)
Я не знаком с Хайбернейтом - юзаю EF. Там в code first фактически создаётся модель слоя данных. - Можно в этой модели создать те же свойства LengthMinimum и т. п. (только задать, чтобы они в БД не сохранялись - т. е. свойства только для валидации). Ну и при сохранении модели данных в БД валидировать её через эти свойства. Валидировать, например, в репозитории или затолкать код в подобия ваших beforeInsert().

Алексей КWPF: ValidationRule

HTML: Knockout-Validation

Главное, не надо ничего усложнять.
ValidationRule кажется какой-то устаревшей вещью. Т. е. она, конечно, работает, но не так удобно, как в контролах, в которых валидация уже встроена в свойства.

С этим ValidationRule ты должен заводить специальные поля напротив полей ввода, которые бы подсказывали, в чём ошибка и т. п. Контролы просто не дадут тебе сделать эту ошибку. Т. е. вот это или вот это - это какие-то лютые простыни кода.

Возьмём первый пример Джоша Смита. Там юзается банальный текстбокс для ввода числа и текстблок для вывода сообщения об ошибке. Плохое - в выделенном мной куске текста. Надо юзать готовый контрол для ввода именно чисел , в котором уже будет встроено:

- само значение
- нижняя граница
- верхняя граница
- формат числа
- (опционально) инкремент-декремент, если это контрол с кнопками увеличения-уменьшения значения
- ну и т. д.

Городьба простынь как у Джоша - из-за неразвитости контролов в WPF в то время, когда он писал свою букварь. Я тоже так раньше писал - и я, честно говоря, заманался в каждом проекте дублировать эти простыни однотипного кода. А вот подход с нормальными контролами упростил дело - завёл нужную модель представления с нужными свойствами и разметка чиста - одни контролы с привязками без всяких errorMessageTextBlock на каждый чих, которые ещё и место в UI кушают.

Согласен?

Ещё раз - Джош сам создал проблему (использовал голый текстбокс для ввода чисел - естественно, в этом текстбоксе нет никаких удобств для ввода именно чисел ) и сам с честью её преодолел.

Я не знаю, почему он так сделал. Возможно, просто для иллюстрации своего подхода. Т. е. вот так можно валидировать, но ИМЕННО ВОТ ТАК в реальных проектах валидировать не надо. Т. е. подход с числами для текстбокса был выбран только в качестве удобной и простой иллюстрации подхода, а не реально употрибемого кода. А может, просто не было в его время таких удобных контролов (в 2008 всё же мало ещё для WPF понаписали). Не знаю. Но сейчас мне его подход однозначно кажется архаичным и требующим кучи лишних телодвижений.

Вот когда у меня флюэнтовский спиннер отберут, а заодно и другие реализации спиннера и прочих контролов для ввода чисел, вот тогда "и снова здравствуй, Джош!".

С тревогой думаю, как переходить на store applications и всякие continuity с автртрансформацией интерфейса для различных режимов работы. Есть ли там из коробки готовые удобные контролы, или опять один тексбокс на все случаи жизни? В WPF уже столько сметаны с маслом и сосисками поналожили, что моему внутреннему коту уходить из этого рая очень не хочется.

Обрати внимание, Алексей

авторКонтролы просто не дадут тебе сделать эту ошибку.

Меня от этого пропёрло. Вместо того, чтобы валидировать каждый пользовательский чих - а пользователь обязательно придумает ситуацию, как сломать твою программу - лучше забрать у него возможность совершать сами ошибки. KISS , внатуре. Эппл-стайл с одной кнопкой на экран, если хотите утрированно. )))

Алексей К,

ладно, я согласен с тем, что кто как привык, тому так и удобно. Я ValidationRule не особо изучал и забил на это дело. Нашёл продвинутые контролы и они мне показались удобнее. Кстати, ValidationRule работает не только в контексте WPF? Или только? Оно работает в ASP.NET MVC, Store Apps из коробки? Т. е. есть смысл его изучать как универсальное средство?

А что насчёт общего подхода к валидации - атрибуты там и передача их в разные слои в виде дополнительных свойств на этих слоях (типа LengthMinimum и т. п.)?

Алексей КWebtester88А что насчёт общего подхода к валидации - атрибуты там и передача их в разные слои в виде дополнительных свойств на этих слоях (типа LengthMinimum и т. п.)?Я не вижу в этом смысла, но это моё субъективное мнение, я не настаиваю. :-)
А как ты делаешь валидацию? У тебя правила валидации хранятся в одном месте?

Я предложил подход, когда правила хранятся в одном месте, но их можно применять в разных местах, не выделяя для этого какой-то отдельный объект валидации (как класс Email, содержащий логику валидации, в статье автора по ссылке в первом посте). Этот подход можно применяь по всему стеку .NET, а не только в WPF или там в ASP.NET.

skyANAWebtester88Что скажете и как делаете вы?доменная модель отдельно, валидация отдельно
У меня тоже так. Только атрибуты валидации на доменной модели никому не мешают (они же не тормозят вычисления?).

Webtester88skyANAпропущено...
доменная модель отдельно, валидация отдельно
У меня тоже так. Только атрибуты валидации на доменной модели никому не мешают (они же не тормозят вычисления?).
В смысле, что я валидацию не в доменном слое провожу. Но храню граничные значения для валидации - в доменном слое.

skyANAWebtester88пропущено...

У меня тоже так. Только атрибуты валидации на доменной модели никому не мешают (они же не тормозят вычисления?).Как реализуете разные проверки в разных компонентах системы?
Вышеописанный мной способ - валидация для доменной модели. Вот так и реализую - вытаскиваю свойства валидации в нужный слой из доменной модели, как я выше описал, и валидирую.

Если надо какую-то валидацию, которой в доменной модели нет, но появляется в каком-то слое системы, то там, конечно, своя валидация будет. А как иначе? Т. е., например, в доменной модели валидация Range(1, 10), а в слое представления надо, чтобы ещё было "отмечено красной галочкой". Красной галочки в доменной модели нет - поэтому только в представлении-модели представлению эту галочку валидирую. Вы это имели ввиду?

kmawWebtester88Если надо какую-то валидацию, которой в доменной модели нет

не кажется что в консерватории что-то не то?
Конкретнее?

kmawWebtester88пропущено...

Конкретнее?

я уже выше писал.
Это вот это?

kmaw"валидация" - не хорошее слово. по сути - это (основная часть бизнес-логики) проверка состояния объекта на допустимость. место этой логике в слое сервисов. как эти ошибки показать в UI - это варианты реализации UI, не более

Т. е. вытащить валидацию в отдельный класс? Я так понимаю, что поэтом этот класс должен присутствовать на всех слоях, где надо дёрнуть валидацию? Т. е. подход как и у человека в статье - инкапсулируем валидацию в каком-нибудь типе Email и шарим этот тип по всем слоям?

kmawkmawпропущено...


вы меня не правильно поняли в принципе . проверка состояния - только в сервис-лейер. как можно "валидировать" поле "сумма оплаты", если там 100500 условий (пред и пост) для проверки корректности. а заморачиваться с "строка не пустая 150 макс" и т.п. на клиенте - нафиг

в том смысле что все эти "валидации" на сервис-лейер
Что у вас подразумевается под "сервисом"? Это специальный класс, в который выносится общая для многих других классов функциональность (т. е. это своего рода библиотека)? Или это конкретные веб-сервисы?

Под первым я и имел ввиду класс Email со встроенной валидацией и т. п.

А если второе - вы что, через эти сервисы прогоняете любой слой, который требует валидации? Допустим, у вас цепочка слоёв:

БД - доменная модель - ваш слой валидации - клиентское приложение

Получается, связка "доменная модель - ваш слой валидации" у вас жёсткая и между этими двумя слоями нельзя вставить ничего другого? Т. е. в доменную модель без валидации ничего попасть не может? Это первое.

А второе, как уже говорил skyANA - что, если нужно отвалидировать что-то на клиенте или ещё в другом слое, а вся логика валидации у вас в спец. слое валидации? Как прогнать другой слой через слой валидации?

skyANAWebtester88пропущено...

Вышеописанный мной способ - валидация для доменной модели. Вот так и реализую - вытаскиваю свойства валидации в нужный слой из доменной модели, как я выше описал, и валидирую.

Если надо какую-то валидацию, которой в доменной модели нет, но появляется в каком-то слое системы, то там, конечно, своя валидация будет. А как иначе? Т. е., например, в доменной модели валидация Range(1, 10), а в слое представления надо, чтобы ещё было "отмечено красной галочкой". Красной галочки в доменной модели нет - поэтому только в представлении-модели представлению эту галочку валидирую. Вы это имели ввиду?Я имел в виду то, что в одном месте допустим Range(1, 10), а в другом Range(10, 20). А еще условие может от времени зависить.
Доменная модель при этом не меняется.
По-моему, у вас противоречие в валидации. Надо наоборот, избавляться от того, чтобы один и тот же параметр встречался несколько раз - можно вот к такому противоречию прийти, когда в одном месте исправил на 10-20, а в другом оставил 1-10.

Вот когда слой вводит свои новые правила валидации, которые отсутствуют в доменной модели за ненадобностью их самой доменной модели - это да. А когда он заменяет правила валидации доменной модели - это ошибка целостности данных.

ViPRosWebtester88пропущено...

По-моему, у вас противоречие в валидации. Надо наоборот, избавляться от того, чтобы один и тот же параметр встречался несколько раз - можно вот к такому противоречию прийти, когда в одном месте исправил на 10-20, а в другом оставил 1-10.

Вот когда слой вводит свои новые правила валидации, которые отсутствуют в доменной модели за ненадобностью их самой доменной модели - это да. А когда он заменяет правила валидации доменной модели - это ошибка целостности данных.
не всегда это ошибка (случай который привел скайана - скорее в модели просто нет сужения домена свойства), есть всякие права и т.д. (допустим не всем позволено оперировать суммами в несколько миллионов рублей)
каждый слой должен провести свою валидацию, так как в других слоях границы валидации либо шире, либо их нет вовсе
Если в дело вступают роли, то да, одного Range может быть уже недостаточно. Тогда есть смысл написать свой Range - с поддержкой ролей и вообще.

Моя идея всё равно такая - атомизировать валидацию на элементарные валидирующие операции и хранить валидацию в одном месте. В вашем случае будет уже не один Range, а несколько - для каждой роли свой. Вот и надо написать так, что один комплексный Range будет атомизирован - разбит на более простые операции валидации - отдельно для каждого профиля. Суть в том, что всё равно это хранится в одном месте - у меня - в доменной модели (можете другое место для этого выбрать - главное, чтобы одно). Когда надо, данные для валидации загружаются для каждого слоя из доменной модели. Т. е., как я писал раньше, создаётся объект слоя - пусть это будет модель представления - в который из доменной модели подтягиваются правила валидации. Я сделал это в виде отдельных свойств LengthMinimum и т. п. С ролями это будет, скажем, LengthMinimum_CustomerProfile, LengthMinimum_AdminProfile и т. п. Если не нравится городить десятки свойств (например, профилей достаточно много) - можно придумать, как обобщить это дело. Возможно, придуматься специальный класс для хранения обобщённых параметров Minimum, Maximum и прочего для каждого профиля. Но суть от этого не изменится - подтянуть валидацию из доменной модели, из какого-то одного места, где хранятся правила валидации.

Ещё раз. Общие правила валидации, которые характерны для доменной модели, хранить в одном месте (в той же доменной модели, например), а производить саму валидацию можно на каком угодно слое - по требованиям каждого конкретного слоя. Правила валидации, характерные для только конкретного слоя, не затрагивающие доменную область, можно хранить и производить в этом конкретном слое (а куда деваться?). Вместо выдавания сообщений об ошибках валидации лучше использовать контролы, которые не дадут совершать такие ошибки - в них сразу граничные условия заданы в свойствах контрола.

Примертно так. Естественно, что можно подобрать условия, когда эта идиллия рассыпается. Тогда придумываешь другую схему. Но моя схема работает во многих случаях.


ViPRosиз за таких дебилов появляются всякие ДТО и т.д. и дребедень сопутствующая
В моей системе есть DTO! Если вы про Data Transfer Object. Ага, тупо набор свойств без методов. Анемичная модель (только не доменная). Я эти DTO использую для обмена между слоями, в котором (обмене) участвует сериализация. Поэтом ещё и DataMember и DataContract атрибутами их обрамил (хуже им от этого не будет, а WCF зато сразу подхватывает). Ну т. е. у меня эти DTO с датамемберами и датаконтрактами в отдельной сборке лежат. Точнее, в отдельных сборках.

И ваще, открываешь такой Студию, а так проектов видимо-невидимо, с кучей ссылок на другие сборки, службы, сайты. Сразу чувствуешь себя этаким РАЗРАБОТЧИКОМ, а не жалким клепателем формочек. Нужно больше сборок, проектов и солюшенов, собранных в одном месте! Обкладываешься ими, перебираешь их, разглядываешь их со всех сторон, протираешь тряпочкой от пыли и снова ложишь под стеклянный колпак. Затем выходишь из хранилища, запираешь за собой тяжёлую железную дверь с кодовым замком и поднимаешься из подземелья на поверхность.

Webtester88Вместо выдавания сообщений об ошибках валидации лучше использовать контролы, которые не дадут совершать такие ошибки - в них сразу граничные условия заданы в свойствах контрола.
Это, естественно, не подходит для секьюрных систем и прочих ответственных. В таком случае это просто для удобства пользователя, чтобы не вводил в голый текстбокс миллионы, когда ему положено не более нескольких тысяч. Окончательная проверка секьюрных даннхы должна происходить на сервере, ибо клиенсткие контролы можно и взломать или вообще вручную сформировать ответ на сервер.

Но тут, как я говорил, уже надо затачивать мой подход под конкретные требования системы или придумывать свой подход.

Вообще, вы правы. Я просто поделился своим опытом. Довольно узким, надо сказать.