클래스 데이터 유효성 검사

Question

내 응용 프로그램에서 일련의 유효성 검사 클래스를 만들어 예를 들어 WinForm에서 클래스의 Name 속성을 입력 한 사용자가 varchar()의 크기를 초과하지 않았는지 확인합니다. 데이터베이스

현재 이름 필드가 너무 큰 경우 유효성 검사 코드가 맞춤 예외를 throw합니다. (사용자 정의 예외는 UI에 걸리면 일반 예외에 대한 내 일반 오류 양식과 달리 MessageBox에 사용자 정의 예외 메시지를 표시합니다.) 유효성 검사 클래스는 앱의 클래스 라이브러리에 있으며 친구로 범위가 지정됩니다. 흐름은 다음과 같습니다 다음 윈폼에서 사용

• DLL의 공공 서비스 레이어 - (전화) -> 친구 유효성 검사 계층
• 윈폼에서 사용하는 DLL의 공공 서비스 레이어 - (통화) - -> 친구 데이터 액세스 레이어 유효성 검사가 성공하면

간단한 예 : 그것은 다시 유효성 검사가 실패 UI에 대한 유효성 검사 레이어 던져 사용자 정의 예외를 가지고있는 "스마트"디자인은

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를 반환하고 실패한 String 메시지와 함께 서비스 레이어 핸들에서 예외를 throw하는 것이 더 나은 설계입니까?

유효성 검사 레이어에서 True/False를 반환하고 실패한 문자열 메시지와 함께 UI에 True/False로 버블 링하는 것이 더 좋은 설계입니까?

저는 객체 지향 접근법을 유지하려고합니다. 내 생각에 OOP 원칙을 위반하지 않는 사용자 정의 예외를 던지면 다른 의견도 표시됩니다. :)

Answer 1

AFAIK 예외 메커니즘은 사실 OOP 방법론의 핵심이며 실제로 어디에 빌드되어 있는지 장려됩니다. 프로그래밍 언어 나는 당신의 validation이 사용자 정의 예외를 던지는 것이 매우 좋다고 말하고 싶다. 특히 여러 가지 커스텀 예외 (NameTooLongException, NameIncludesNonStandardCharactersException ...)가있을 때 특히 그 자체의 문서화가 가능하며 향후 관리자에게 쉽게 읽을 수있다.

예외가 서비스 계층에 도달하면이를 catch하고 처리할지 (비즈니스 논리에 따라 다름) 또는 UI로 끝까지 전달할 것인지 결정할 수 있습니다. 예외가 항상 적절한 의미있는 오류 메시지를 전달하는 경우 UI에 사용자에게 제시하는 것이 좋지 않은 것은 아닙니다. (어떤 점에서 응용 프로그램을 국제화하고 싶을 수도 있습니다.이 경우 메시지는 올바른 언어로 작성되어야합니다.)

내 생각에 레이어 분리는 순수하게 논리적이지만, 이유 및 예외는 백엔드에서 프런트 엔드로 던져서는 안되지만 규칙보다 더 많은 지침입니다. 최종선, 할 일이 무엇인지, 디자인을 과장하지 마십시오. 이 어떻게 든 도움이

희망 ...

Yuval 교수 = 당신이 한 번에 모든 위반을 포착하고이를 제시 할 일 "새로운 고객"여러 비즈니스 규칙 위반 사실이 있다고 가정하면 8)