유효성 검사, 여기서 패턴의 형태로 존재 함

Question

MVC가 있다고 가정 해 보겠습니다. 우리의 C는 똑똑하고 라우터 역할 만하며, 비즈니스 계층에서는 Persistence 계층 (DAO)을 호출합니다.

우리는 우리의 검증을 어느 부분에 적용합니까? 모델이나 DTO 클래스의 필드에 배치되는 주석 기반 유효성 검사에 대해서는 설명하지 않지만 유효성 검사기 클래스 자체를 만들 때와 같이 다소 복잡한 것입니다. 공식적인 다이어그램에서 어떻게 설명 할 수 있습니까? 나는 그것이 비즈니스 논리 내에 있다고 가정했다. 그러나 Spring MVC 유효성 검사와 동시에 컨트롤러에 더 중점을 둔다.

적합하다고 생각되는 것을 알려주십시오.

Answer 1

나는 프레젠테이션, 비즈니스 및 데이터베이스와 같은 계층 구조로 검증 문제가 구성되어 있다고 생각합니다.

레이어 이름은 처음부터 유효성 검사 규칙에 아무런 의미가 없습니다. (이는 유효성 검사 규칙이 검사되는 레이어라는 것을 의미합니다.)

중요한 것은주의해야 할 점은 주로 웹 응용 프로그램을 개발하는 것이고이 규칙은 그러한 응용 프로그램에만 적용되지만 다른 응용 프로그램에는 적용되지 않습니다.

데이터베이스 계층 유효성 검사 규칙을 : 일괄 처리 작업 같은 것들

는 아래에서 위로 갈 수 있습니다. 이들은 주로 "not null"입니다 (필드 및 관계 용). 이 계층에는 구현 자체에 필요한 모든 유효성 검증 제한 조건이 존재하며 (데이터베이스에 의해 강제 적용됩니다). 이는 응용 프로그램이 충돌하는 유효성 검증 위반이있는 경우를 의미합니다. (비즈니스 로직이 잘못된 것을 계산할 수 있다는 의미는 아니며 실제로 애플리케이션이 결과를 반환하지 않음을 의미합니다). Database Layer 유효성 검사 규칙에서이 계층의 규칙 위반이 버그라는 것을 이해하는 것이 중요합니다. 따라서 이러한 규칙의 목적은 확인하지 않아야합니다. 그 목적은 중요한 유효성 검사 위반이 지속될 수 없도록하고 데이터베이스 레코드가로드 될 때마다 응용 프로그램이 중단되지 않도록하는 것입니다. - 따라서이 제한을 위반하면 직접적으로 미해결 예외가 발생합니다. 원인은 버그이므로 잘못된 데이터베이스 레코드를 수정하는 것은 불가능합니다.

비즈니스 계층 유효성 검사 이 유효성 검사 규칙은 주로 비즈니스 계층에 존재하며, 주로 서비스 기능에 있습니다. "사용자 이름은 고유해야합니다"와 같은 것입니다. 이 규칙을 위반하더라도 프로그램 자체가 중단되지는 않지만 잘못된 비즈니스 결과가 발생할 수 있습니다. 두 번째 중요한 점은 Bussiness Layer Validation 규칙이 데이터베이스에 의해 시행 될 수 있다는 것입니다. 그러나 해결되지 않은 예외 대신 위반 예외를 캐싱하고 처리해야합니다. 비즈니스 계층 유효성 검사 위반은 버그가 아니며 잘못된 입력입니다.

프레젠테이션 계층 유효성 검사 이 유효성 검사 규칙은 아무 의미도없는 규칙입니다. 대부분 이것들은 매일 바뀌는 어리석은 비즈니스 규칙이며 비즈니스 결과에 영향을 미치지 않습니다. 다음과 같은 규칙이 있습니다. "스택 오버플로 질문에 대한 주석은 적어도 10 자 이상이어야합니다". 프리젠 테이션 계층에서만 이러한 규칙을 확인합니다 (당연히 서버 측).

물론 비즈니스 또는 데이터베이스 계층 제약은 (너무 많은 작업을 할 수있는 한) 프레젠테이션 계층의 입력 양식에서도 확인해야합니다. 예를 들어, null이 아니어야하는 필드가있는 경우, 이것은 프리젠 테이션 레이어의 입력 폼 핸들러에서도 체크되어야합니다.