-Ваше политическое кредо?
-Всегда!
(с) "12 стульев"
Свойство Mandatory у полей таблиц работает безусловно; если логика заполнения поля настолько проста, разумеется, лучше использовать метаданные и положиться на ядро, но если логика предусматривает необходимость заполнения полей по определенным условиям, тут уже Mandatory не поможет. Аналогично с AllowNegative на расширенном типе: никакие расширенные типы не позволят автоматом проверять условия вида "при одном значении поля A сумма в поле B должна быть неотрицательной, а при другом - неположительной" или "значение в поле А должно быть меньше или равно значению в поле B". Кроме того, скажем, для полей-enum'ов нельзя задать на уровне метаданных какие-либо проверки, кроме обязательности заполнения (т.е. что нельзя выбрать значение enum'а, равное нулю), в то же время в коде порой приходится проверять условия вида "статус документа должен быть меньше, чем «Накладная»" - такие проверки в любом случае надо программировать.
Вообще же, дабы не раздувать дальнейшие дискуссии, открою небольшой секрет: изначально моей целью была публикация переписанного семейства классов SysExcel (см.
Взаимодействие с Excel через .NET (семейство классов SysExcel), однако, эта модификация отчасти базировалась на двух других - представленных здесь классах проверки условий и утверждений и
классе для преобразования значений между различными значимыми типами. Поскольку мне показалось, что эти две модификации представляют некоторую самостоятельную ценность, я опубликовал их отдельно. Это, в частности, позволит мне в дальнейшем не включать их во все публикуемые модификации, которые их используют, а просто делать ссылки в сообщении. Пользоваться ими в своей работе или же просто импортировать как довесок к семейству SysExcel (если для кого-то актуальна стабилизация работы с Excel), каждый может решить самостоятельно.
Я лично пришел к выводу, что от императивных проверок лучше переходить к проверкам декларативным, в идеале - описывать нужные граничные условия с помощью атрибутов, хотя в 2009-й они еще не поддерживаются. Часть декларативных проверок реализуется свойствами расширенных типов и полей, и этим безусловно надо пользоваться, но возможности эти покрывают лишь наиболее примитивные сценарии. Инструмент для более затейливых сценариев у меня получился вот таким, возможно, для кого-то он покажется чем-то чужеродным на фоне стандартного приложения, но мне он позволяет 1) писать больше проверок в коде, 2) писать их более лаконично и наглядно, 3) получать достаточно детализированные сообщения в случае нарушения проверяемых условий без необходимости писать логику вывода сообщений во всех тех местах кода, где выполняются проверки. Да, где-то нужно "подготовить контекст" для выводимых сообщений, тот же setprefix() вызвать, но в целом текстовых строк в коде получается меньше, чем при "традиционном" подходе с кучей if и checkFailed().