Да, это правда, что основная цель «Контрактов кода» - проверить мой код на соответствие дизайну моего класса, но он также описывает действительные состояния моего объекта.
Все, что я могу придумать для сценариев проверки, относится к этим трем типам:
- Проверка входных данных (проверка пользовательского интерфейса)
- Проверка домена (DbC)
- Проверка выходных данных (постоянство
Валидация, например: NHibernate
Валидатор )
Я рассматриваю проверку как логический вопрос, находится ли целевой объект в допустимом состоянии или нет.
DbC состоит из трех частей,
- Правила проверки
- Статическая проверка
- средство проверки времени выполнения
Первая часть (правила) является общей для всех трех сценариев проверки. Когда я отмечаю свойство с помощью «Not Null», используя «Code Contracts», чтобы проверить его дизайн, разве не уродливо пометить его «Not Empty» с помощью «System.ComponentModel.DataAnnotations» для MVC (проверка пользовательского интерфейса)?
В абстрактном виде определение действительных состояний является основным, и общая часть платформ валидации и «Контрактов кода» предоставляет его, с одним дополнительным элементом, который является «Статическим проверяющим» для разработки домена (не I / O).