Здравствуйте, Sinix, Вы писали:

S>Имхо, такие проверки должны быть обязательно на "последнем фронте" — в триггерах БД/проверках при коммите в DAL(если с триггерами никак). Иначе в СУБД рано или позно окажется мусор.

S>Валидация в UI (а куда без неё?) обычно делаются силами самого UI-фреймворка. Остаются ассерты — им как раз самое место в классах БЛ/данных. По хорошему без них тоже никак — замучаетесь отслеживать точку, в которой в класс попали некорректные данные. Куда тут можно прикрутить целый фрейморк валидации — я не знаю.

речь идет про валидацию в доменной модели. Понятно что до определенного уровня валидация есть и в базе данных и в UI, но меня интересует именно применение фреймворков в бизнес-слое

S>*мы в форуме про архитектуру, так?
S>Вы уверены, что наличие фамилии в классе Покупатель — это вообще хорошая идея? Как быть с покупками на юрлицо?

будет другой подтип это только пример