Проверка данных класса - PullRequest
Новая
       9

Проверка данных класса

0 голосов
/ 18 марта 2009

В моем приложении я создаю серию классов проверки, чтобы проверить, например, что введенное пользователем свойство Name класса (из WinForm) не превышает размер varchar () в базе данных.

В настоящее время код проверки будет выдавать пользовательское исключение, если поле Имя слишком большое. (При обнаружении пользовательского интерфейса пользовательское исключение будет отображать пользовательское сообщение об исключении в MessageBox, в отличие от моей общей формы ошибок для обычных исключений.) Классы проверки находятся в библиотеке классов приложения и определены как Friend. Поток выглядит так:

  • Уровень публичной службы DLL, используемый WinForms - (вызовы) -> Уровень проверки друзей
  • Уровень публичной службы DLL, используемый WinForms - (вызовы) -> Уровень доступа к дружественным данным, если проверка прошла успешно.

Упрощенный пример: 

Public Shared Sub CreateCustomer(cust as Customer)
    Validation.Customer.ValidateForCreate(cust) ' scoped as Friend
    Dal.Customer.Create(cust) ' scoped as Friend
End Sub

Является ли "умным" дизайном, чтобы слой проверки выдавал пользовательские исключения обратно в пользовательский интерфейс при сбое проверки?

Лучше ли просто возвращать значение True / False из слоя проверки вместе со строковым сообщением о том, что не удалось, и обработчик уровня обслуживания обрабатывает исключения?

Лучше ли просто возвращать значение True / False из слоя проверки, и чтобы уровень служб выдавал пользовательскому интерфейсу значение True / False вместе с сообщением String о том, что не удалось?

Я пытаюсь сохранить объектно-ориентированный подход. Мое мнение таково, что создание пользовательских исключений не нарушает принципы ООП, но я хотел бы, чтобы другие мнения:)

1 Ответ

1 голос
/ 18 марта 2009

AFAIK механизм исключений фактически лежит в основе методологии ООП, и его поощряют там, где он встроен в язык программирования. Я бы сказал, что ваша проверка выдает пользовательское исключение - очень хорошая вещь, особенно если у вас есть несколько пользовательских исключений (NameTooLongException, NameIncludeNonStandardCharactersException ...), которые являются самодокументируемыми и легко читаемыми для будущих сопровождающих кода.

Как только ваше исключение достигнет уровня обслуживания, вы можете решить, следует ли его перехватить и обработать (это зависит от вашей бизнес-логики) или позволить ему пройти весь путь до пользовательского интерфейса. Если исключение содержит значимое сообщение об ошибке, которое всегда уместно, возможно, позволить пользовательскому интерфейсу представить его пользователю - неплохая идея. (Имейте в виду, что в какой-то момент вы можете захотеть интернационализировать свое приложение, и в этом случае сообщение должно быть на правильном языке.)

Мое мнение таково, что разделение слоев, хотя иногда и чисто логическое, имеет свои причины, и исключения не должны быть выброшены из конца в начало, но это скорее ориентир, чем правило. Итог, делай то, что нужно, не задумывайся над дизайном.

Надеюсь, это как-то поможет ...

Ювал = 8 -)

...