В одном из приложении реализовывали следующий механизм:
- все информационные объекты, подлежащие вводу/редактированию в систему реализованы в виде классов
- использовался механизм DDX (привязка классов к элементам управления на экранных формах)
- проверки реализованы в виде VB-скриптов (в скриптах обращение к методам и свойствам классов + функции VB + выполнение произвольных запросов к базе данных),
- проверки выполняются на клиентской части приложения
- проверки разделены на 2 категории: критические (не позволяют сохранить объект в базе данных), и не критические (позволяют сохранить со статусом "черновик")
- при нарушении условий проверок в пользовательском интерфейсе подсвечиваются поля ввода с выводом в хинтах пояснений в удобном для восприятия бизнес-пользователем виде.
- скрипты хранятся в настроечной таблице в базе данных, реализовано управление ими (привязка к данным, текст скрипта, комментарии и т.д.).

На реализацию механизма проверок (при готовом 3-х уровневом приложении) ушло две человеко-недели. Еще месяц ушел на "сочинение" и описание нескольких сотен проверок.

Petro123,
В нашем случае правила проверок всего лишь запрещают сохранить информационный объект в базе данных (c "кривым" личным номером, с датой выдачи паспорта меньшей чем дата рождения, контроль на допустимое подмножество кодов из справочника и многое другое), либо позволяют сохранить его со статусом "недоделанный", что в свою очередь не позволяет осуществлять дальнейшую обработку данного объекта различными категориями пользователей.

Т.е. мы здесь ведем речь о недопущении попадания мусора в БД при вводе оператором, а на бизнес-логику работы с "чистыми данными" этот блок проверок никоим образом не влияет.