Да, и нет.
Это зависит от архитектуры вашего приложения. Мы предполагаем, что вы создаете n-уровневое приложение, поскольку подавляющее большинство приложений в наши дни склонны следовать этой модели.
Проверка в пользовательском интерфейсе предназначена для обеспечения немедленной обратной связи с конечным пользователем системы, чтобы предотвратить выполнение функций на более низких уровнях в первую очередь с недопустимыми входами. Например, вы даже не захотите пытаться связаться с сервером Active Directory без имени пользователя и пароля для попытки аутентификации. Валидация в этот момент экономит ваше время, затрачиваемое на создание экземпляра объекта, его настройку и ненужную обратную передачу на сервер, чтобы узнать что-то, что вы могли бы легко узнать с помощью простой проверки данных.
Проверка в ваших библиотеках классов - это другая история. Здесь вы проверяете бизнес-правила . Хотя можно утверждать, что валидация в пользовательском интерфейсе и валидация в библиотеках классов совпадают, я бы не согласился. Проверка бизнес-правил, как правило, гораздо сложнее. Ваши правила в этом случае могут быть более нюансированными и могут обнаруживать вещи, которые невозможно найти через пользовательский интерфейс. Например, вы можете применить правило, которое гласит, что пользователь может выполнять метод только после того, как все свойства класса были правильно инициализированы, и только если пользователь является членом определенной группы пользователей. Или вы можете указать, что объект может быть изменен, только если он не был изменен в течение последних двадцати четырех часов. Или вы можете просто указать, что строковое значение не может быть нулевым или пустым.
Однако, на мой взгляд, правильно спроектированное программное обеспечение использует общий механизм для принудительного использования DRY (если возможно) как из пользовательского интерфейса, так и из библиотеки классов. В большинстве случаев это возможно. (Во многих случаях код настолько тривиален, что это того не стоит.)