클라이언트 쪽 유효성 검사(프레젠테이션 계층의 유효성 검사)

원본이 도메인 모델이고 궁극적으로 도메인 모델 수준에서 유효성 검사가 있어야 하는 경우에도 도메인 모델 수준(서버 쪽)과 UI(클라이언트 쪽) 모두에서 유효성 검사를 처리할 수 있습니다.

클라이언트 쪽 유효성 검사는 사용자에게 매우 편리합니다. 그렇지 않으면 유효성 검사 오류를 반환할 수 있는 서버로의 왕복을 기다리는 데 소요되는 시간을 절약합니다. 비즈니스 측면에서, 매일 수백 번 곱한 초의 몇 분수조차도 많은 시간, 비용 및 좌절을 더합니다. 간단하고 즉각적인 유효성 검사를 통해 사용자는 보다 효율적으로 작업하고 더 나은 품질의 입력 및 출력을 생성할 수 있습니다.

보기 모델과 도메인 모델이 다른 것처럼 보기 모델 유효성 검사 및 도메인 모델 유효성 검사는 유사하지만 다른 용도로 사용될 수 있습니다. DRY(반복하지 않음 원칙)에 대해 우려하는 경우 이 경우 코드 재사용은 결합을 의미할 수도 있으며 엔터프라이즈 애플리케이션에서는 DRY 원칙을 따르는 것보다 서버 쪽을 클라이언트 쪽과 결합하지 않는 것이 더 중요합니다.

클라이언트 쪽 유효성 검사를 사용하는 경우에도 서버 API가 가능한 공격 벡터이므로 항상 서버 코드에서 명령 또는 입력 DDO의 유효성을 검사해야 합니다. 일반적으로, 둘 다 수행하는 것이 최선의 선택입니다. 클라이언트 애플리케이션이 있는 경우, UX 관점에서 사전 대응하여 사용자가 잘못된 정보를 입력하지 않도록 방지하는 것이 가장 좋습니다.

따라서 클라이언트 쪽 코드에서는 일반적으로 ViewModels의 유효성을 검사합니다. 서비스에 보내기 전에 클라이언트 출력 DDO 또는 명령의 유효성을 검사할 수도 있습니다.

클라이언트 쪽 유효성 검사의 구현은 빌드하는 클라이언트 애플리케이션의 종류에 따라 달라집니다. .NET에서 대부분의 코드를 사용하여 MVC 웹 애플리케이션에서 데이터의 유효성을 검사하는 경우와 JavaScript 또는 TypeScript의 유효성 검사 코드를 사용하는 SPA 웹 애플리케이션의 경우는 다릅니다.

추가 리소스

ASP.NET Core 앱의 유효성 검사

• 유효성 검사 추가
  https://learn.microsoft.com/aspnet/core/tutorials/first-mvc-app/validation

SPA 웹앱의 유효성 검사(Angular 2, TypeScript, JavaScript, Blazor WebAssembly)

• 양식 유효성 검사
  https://angular.io/guide/form-validation

• 유효성 검사. 브리즈 설명서.
  https://breeze.github.io/doc-js/validation.html

• ASP.NET Core Blazor 양식 및 입력 구성 요소 \ </aspnet/core/blazor/forms-and-input-components>

요약하면 유효성 검사와 관련하여 가장 중요한 개념은 다음과 같습니다.

• 엔터티 및 집계는 자체 일관성을 적용하고 "항상 유효"해야 합니다. 집계 루트는 동일한 집계 내에서 다중 엔터티 일관성을 담당합니다.

• 엔터티가 잘못된 상태를 입력해야 한다고 생각되는 경우 다른 개체 모델(예: 최종 도메인 엔터티를 만들 때까지 임시 DTO 사용)을 사용하는 것이 좋습니다.

• 집계와 같은 여러 관련 개체를 만들어야 하며 모든 개체가 만들어진 후에만 유효한 경우 팩터리 패턴을 사용하는 것이 좋습니다.

• 대부분의 경우 애플리케이션이 사전 예방적일 수 있으므로 클라이언트 쪽에서 중복 유효성 검사를 사용하는 것이 좋습니다.