Persons를 데이터베이스에 저장할 수있는 웹 응용 프로그램이 있다고 가정 해보십시오. 모든 사람은 고유 한 전자 메일 주소 (또는 사용자 이름 또는 기타)를 가져야합니다. 사용자가 이미 존재하는 이메일 주소를 가진 사람을 추가하려고 시도하는 경우 양식은 일반적인 유효성 검증 실패와 마찬가지로 오류 메시지와 함께 반환되어야합니다.웹 응용 프로그램에서 비즈니스 오류를 어떻게 처리해야합니까?
이 종류의 오류는 가장 일반적으로 서비스 계층에서 컨트롤러로 그리고 뷰에서 어떻게 발생합니까? 서비스 메소드가 컨트롤러가 catch하거나 값 또는 어떤 종류의 결과 객체를 반환하는 예외를 throw해야합니까?
웹 서비스를 생성하기 위해 내 서비스 계층을 사용하려는 경우 어떻게하면 계속 진행할 수 있습니까?
모범 사례/샘플 응용 프로그램에 대한 제안이나 링크를 제공해 주시면 감사하겠습니다.
예외를 처리하고 비즈니스 규칙 유효성 검증 결과를 리턴하는 기본적으로 두 가지 f}이 있습니다.
예외 : 각 방법은 장점과 단점이 있지만, 기본적으로이
비즈니스 규칙 유효성 검사 : 여러 비즈니스 규칙을 확인하고이 엉망으로 복귀하는 경향이 있기 때문에,
나는 접근 방식이 더 나은 응용 프로그램에 크게 의존한다고 생각하므로 간단한 대답은 없습니다. 오랜 시간 동안 비즈니스 규칙에 대한 예외를 성공적으로 사용 했으므로 이제 두 번째 접근법을 활용하는 경향이 있습니다.
이 문제를 처리하는 한 가지 방법은 상태 코드가있는 addPerson 작업에 대한 응답 개체를 만드는 것입니다. 예 :
class AddPersonResponse {
private Person person;
private AddPersonStatus status;
private AddPersonFailureReason failureReason;
}
enum AddPersonStatus {
SUCCESS, FAILURE
}
enum AddPersonFailureReason {
DUPLICATE_EMAIL_ADDRESS,
DUPLICATE_USER_NAME
}
사용자에게 보내는보기는 서비스에서 반환 한 응답 개체에 바인딩하고 적절한 피드백을 줄 수 있습니다.
나는 예외를 던질 것을 선택할 것이라고 생각합니다. Exception 클래스에서 파생 된 사용자 지정 예외를 만들 수 있습니다. 이 방법을 사용하면 클래스의 'Message'필드를 최종 사용자에게 친숙한 메시지로 사용할 수 있으며 기본 'innerException'필드에서 실제 예외 정보를 기록 할 수 있습니다. 이렇게하면 기본 예외 설명의 자세한 표시를 유지하면서 사용자가 실패한 이유에 대한 추악한 세부 사항을 숨길 수 있습니다.
이메일 주소가 이미 사용 중임을 사용자에게 알리는 것은 "못생긴 세부 정보"가 아니라 쉽게 확인 된 유효성 검사 단계입니다. –
이 토론은 오래되었으며 다른 캠프를 찾을 수 있습니다. 제 생각에는 명백한 독립형 기능을 가진 백엔드 시스템이있는 경우 먼저 API와 모든 것을 사용하여이를 개발 한 다음 뷰 레이어에서 해당 API를 사용해야한다는 것입니다. 이 경우 레이어가 필요합니다. 한 가지 예는 이미 개발 된 맞춤형 소프트웨어에 웹 프론트 엔드를 작성하는 것입니다.
그러나 대부분의 웹 응용 프로그램에서는 단일 구성 소스를 사용하는 것이 훨씬 쉽고 간단합니다. Django, RoR, JBoss Seam 등 모든 사람들이이 접근법을 사용합니다. 이들은 모든 유효성 검사 논리와 제약 조건이 적용되는 일련의 도메인 클래스를 중심으로 한 개념을 사용합니다. 모델 예외 (예 : NoSuchObject)는보기 예외 (404 찾을 수 없음)에 직접 매핑되며, 모두 프레임 워크에서 처리됩니다. 이 방법을 사용하면 레이어가 없으며 주 아이디어는 실제로 필요할 때까지 레이어를 적용하지 않는 것입니다. Django 문서는이 주제에 관한 정보의 훌륭한 원천이며 Seam 문서는 더 기술적이지만보다 자세합니다.
일부 논리를 웹 서비스로 노출하기로 결정한 경우 완전한 계층화 된 솔루션을 구축하겠다는 결정을 자동으로 보증하지 않습니다. 리팩터링하기 쉽고 YAGNI 및 DRY 규칙을 사용하면됩니다.
레이어링은 실제로 정보를 앞뒤로 전달하는 또 다른 차원의 문제를 추가합니다. 문제가 잘 맞지 않으면 레이어를 사용하지 마십시오.
필자는 "유효성 검사 오류는 예외입니다"패턴을 좋아하지 않습니다.
My 모델 Save() 메서드는 깨진 규칙 목록 (빈 목록)을 만들고 반환하기 만하면됩니다. ControllerBase (또는 서비스 계층)의 작업은 깨진 규칙을 처리하지만 적합하다고 생각합니다.
내 ControllerBase의 경우 AddModelError를 통해 MVC 유효성 검사 처리기에 하나씩 추가합니다. 서비스 계층에서 JSON 결과에 "isValid"플래그를 추가하는 것과 같은 결과를 낳습니다.
유효성 검사 오류 및 예외에 관한 진술에 전적으로 동의하십시오. 유효성 검사 오류는 예외를 throw하는 것보다 더 우아하게 예상되고 처리되어야합니다. 동의하지 않는 사람들에게 UI를 통해 하나의 레코드가 아닌 백엔드 시스템에서 10,000 개의 레코드를 처리한다고 가정 해보십시오. 예외가있는 유효성 검사 오류를 처리하는 것이 여전히 적합한가요? 이 경우에는 오류에 대한 메타 데이터에 약간의 메모를해야한다고 생각합니다. 오류 임계 값에 도달하기 위해 트랜잭션을 롤백할지 여부를 다운 스트림으로 결정해야 할 수도 있기 때문입니다. –
Spring MVC와 함께 사용하는 접근법은 my Validator 클래스 내에서 모든 유효성 검사를 수행하는 것입니다. 그래서 내 유효성 검사 메서드 내에서 전자 메일 주소가 이미 사용되었는지 확인하기 위해 서비스의 메서드를 호출합니다. 중복 된 경우 양식에 표시하기 위해 Errors 개체에 대한 바인딩에 오류가 추가됩니다. Person 객체가 유효하다면 서비스에 추가 될 때 발생하는 expections에 대해 걱정할 필요가 없습니다.
나는 이것을 처음에 고려했다. 그러나 어떤 이유로 나는 validation logic을 모델로부터 제거 된 단계로 생각한다. 아마도 유효성 검사기는 일반적으로 폼 입력을 검증하기 위해 컨트롤러에 의해 호출되기 때문입니다. 이 경우 중복을 피하는 구체적인 예가 비즈니스 규칙이므로 비즈니스 계층에서 확인해야합니다. 생각? – Boden
질문에 대한 모든 답변을 컨텍스트에 따라 다릅니다. 필자의 경우 컨트롤러는 객체가 서비스에 추가되는 유일한 장소이므로 유효성 검사기에서 중복 체크를 수행하는 것은 큰 문제가 아닙니다.그러나 웹 서비스를 통해 비즈니스 계층을 제공 할 수 있다고 말하면 비즈니스 계층에서 중복 된 부분을 확인하는 것이 가장 좋습니다. – Mark
Boden, 비즈니스 규칙을 비즈니스 계층에서 확인해야한다고 생각합니다. 그렇게하면 MVC 컨트롤러 나 웹 서비스를 통해 서비스 또는 모델 메서드를 호출하는 방법에 관계없이 해당 규칙이 검사됩니다. –
상태 코드를 사용하십시오. 나는 돌아 오는 값과 상태 코드가 무시 될 때마다 무시하는 결과를 보았습니다. 무효 한 데이터가 후속 비즈니스 로직에 깊숙이 들어가게되면 그 결과는 모호한 충돌로 이어집니다. –