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

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

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