barserА если речь об атрибутивном механизме в целом - то что плохого в том, что на класс и/или какое-либо из его полей понавешано несколько атрибутов из различных библиотек (в том числе и самописных)? Это ж удобно! Если не ошибаюсь, в таком подходе как раз один из плюсов аспектно-ориентированного программирования...
1. Локализация
2. Более медленная работа при массовой заливке
3. Невозможность составления более сложных валидационных формул
4. Для ASP.NET - ставим крест на клиентской js-валидации, следовательно - дополнительные нагрузки на сервер
5. Да и вообще... ребячество это.

barserПонимаю, о чем Вы .... Так что пишем мессаджи по-русски.
То есть, Вы представляете себе какое это зло хардкодить сообщения в бизнес-классе?

P.S. Совет - ну уж хотя бы в константы выносите, ибо атрибуты прекрасно работают с константами, без всяких левых грабель типа этих .



P.S2. StoredMessages храните в отдельной сборке. Если вдруг что - можно элементарно просто и за быстрые сроки сделать новую сборку с иной интернационализацией и подпихнуть программе. Быстро и просто, причём никаких трудозатрат. Но гадить в бизнес-классах - за это и расстрелять могут :)

barserСмотря что понимать под более сложными формулами... Там довольно просто свои правила писать.
Пример:
1. Есть 3 поля: "номер документа" (int), "тип документа" (int), "дата документа" (datetime)
2. Задача: произвести валидацию по следующему правилу:
а) Если "номер документа" находится в диапазоне [1000-10000], то "тип документа" и "дата документа" являются обязательными
б) Если "номер документа" находится в диапазоне [10001-20000], то "тип документа" является обязательным, а "дата документа" являются не обязательной
в) Если "дата документа" < DateTime.Today.AddDays(-7) и "тип документа" = [1; 10], то "номер документа" должен начинаться с цифры 9
г) ...

barserНа стороне клиента простую валидацию входных данных пишем на ExtJS. Наверное, это неправильно, так как логика проверки дублируется, но ничего лучше мы не стали выдумывать.
Во-первый, не ExtJS, а - Sencha (ExtJS погиб).
Во-вторых, чем обычные одные js-валидаторы не устроили?
В-третьих, - Вы дублируете валидационную логику и при изменении этой логики нужно вносить правки в двух местах, что есть совсем не гуд.
И в-четвертых, при сложной валидации (примеры я привел), которую невозможно описать аттрибутивно, всё-равно нужно спуститься на отдельный блок кода бизнес-класса (пусть это будет метод). А теперь представьте, что у Вас этих методов может быть сотня. И прикиньте мозгами, какой срач мы устроим в бизнес-классе?

barserА вообще, насколько я понял Курдля, речь шла немножко не о том. И отвечал я про то, что атрибутами легко и удобно контроллировать различные аспекты поведения, а не только валидацию.
Да, я понял, просто вставил свои пять грабель. И самое существенное - атрибутами легко и красиво описать модель класса хеллоуворлд. На более сложных моделях данных аттрибутивно контроллировать различные аспекты поведения будет невозможно. По опыту.

barserНапример, у нас используются атрибуты, определяющие изменения, которые необходимо журналировать. Хотя преимущества атрибутов для различных задач должны быть понятны и без моих слов... :)
Не всё так просто, коллега, не всё... :)

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

http://msdn.microsoft.com/ru-ru/library/ms173119.aspx
При ссылке на значения констант, определенных в другом коде, например DLL, следует соблюдать осторожность. Если новое значение константы определяется в новой версии DLL, программа по-прежнему будет хранить старое литеральное значение вплоть до перекомпиляции в новую версию.

Курите обычный статик в DLL и будет счастие.

barserУ нас такие "проверки" в serviceLayer встречаются... Беру в кавычки, потому что я считал, что это к бизнес-логике больше относится (хотя и более простая валидация тоже может быть отнесена к бизнес-логике; как-то размыто получается...)
Вот и я о том же :)

Получается что:

1) Аттрибутивная валидация
2) Service Layer валидация (сложная)
3) Валидация js (GUI)
4) Валидация code behind (сложная, GUI)

Каша и только.

barserА где рекомендуете хранить такого рода проверки?
Фанатам MVC и прочих ребяческих шалостей не читать
Конечно же при гуе! Б о льшую часть бизнеса (простая валидация) покроют родные js-валидаторы, которые определены декларативно. Плюсы, думаю, прорисовывать не нужно (избавляемся от лишних постбеков на сервер, при изменении правил/сообщений валидации не нужно перекомпилировать аппликацию, сообщения хранятся в ресурсниках, всё как в детском саду). Более сложную валидацию, как Вы правильно заметили, выносим в Service Layer (или при гуе) и используем там же по месту - гуевский code behind.

Имеем 2 возможных варианта:

1) Service Layer валидация (сложная)
2) Валидация js (GUI)

или

1) Валидация code behind (сложная, GUI)
2) Валидация js (GUI)

И никаких нахлёстов и дублирования, как в Вашем случае. Лично я применяю оба подхода. К примеру, если я знаю, что реально замудрёная валидация больше нигде не будет использоваться - буду юзать второй вариант. Быстро и просто.

P.S. Но не подумайте, что я против аттрибутивной валидации. Это очень красивое решение, но, к сожалению, на более серьезных и сложных проектах покрыть все проблемы не получится. Да и отказываться от родной клиентской js-валидации (опять же, вопросы по разгрузке сервера приложений) - никогда в жизни. Поэтому, это не имеет правл на жизнь, как-бы красиво оно не выглядело. Как-то так.

Кстати, забыл отметить, что иногда полезно и дублирование валидации (js + code behind), когда возможны атаки в обход js-валидации. Тут, глядишь, в бой вступает СУБД с обязательными полями, чеками, триггерами. Но, если ни чеков, ни триггеров нет, а обязательность необязательная (сорри за тафтологию) (надеюсь, Вы поняли о чём я) - то приходится проверять и на стороне сервера приложения. Ибо безопасность.