좋은 사례

Question

일반적인 시나리오 :

계층 적 도메인 모델이 프리젠 테이션을 위해 평면 뷰 모델에 매핑되고있다.

내 도메인에 전체 유효성 검사 설정이 있으며 일부 속성이 유효하지 않음을 알기 위해 도메인을 개체에 매핑하지 않도록하고 싶습니다. 내 뷰 모델에서 유효성 검사 로직을 복제하고 싶지도 않습니다.

여기에 몇 가지 좋은 사례가 있습니까?

보기 모델은 일반적으로 문자열이 많고 평평한 반면 도메인 객체는 종종 중첩되어 속성에 대한 다른 많은 데이터 유형이 있기 때문에 뷰 모델과 도메인 객체의 인터페이스를 상대로합니다.

나는 도메인 객체와 뷰 모델을 모두 검증 할 수있을만큼 현명하지만 구현에 대해서는 다소 회의적 일 수있는 플러그 가능한 유효성 검사기를 생각하고 있습니다.

하지만 간단하게하기 위해 나는이 방법으로 기울고 있어요 :

서버 측 유효성 검사는 도메인 모델에서 발생; 뷰 모델은 유효성이 검사되지 않지만 JavaScript로 클라이언트에서 데이터 유효성이 검사됩니다. 따라서 대부분의 경우 내 뷰 모델은 유효하며 유효성 검사 논리는 한 곳에서 유지되며 도메인 모델에서만 발생합니다. 이 접근법은 asp.net mvc 2 유효성 검사가이를 지원할 수 없다는 단점이 있습니다. 당신은 어떻게 생각하십니까?

감사합니다.

Answer 1

Microsoft Enterprise Library는 메모리가 작동하는 경우 제네릭을 기반으로하는 'Pluggable Validation'라이브러리를 제공합니다.

다른 EL 구성 요소에 대한 종속성의 수는 말할 것도없고 작동하는 방식이 맘에 들지 않지만 여전히 가치가있을 것입니다.

필자는이 분야의 전문가는 아니지만 데이터를 검증하기 전에 데이터를 검증해야하고 저장소로 커밋하기 전에 항상 데이터를 검증해야한다고 굳게 믿습니다. 따라서 검증 논리에 가장 적합한 곳은 비즈니스 로직 계층입니다. 클라이언트 측 유효성 검사는 사용자에게 즐겁지 만 코드 유지 관리를 악몽으로 만들고 코드 중복을 유발하여 문제를 더욱 심각하게 만들 수 있습니다.

귀하의 프레젠테이션 객체는 제 생각에 DTO가되어야합니다.사용자가 컨트롤러 (및 BLL)에 데이터를 다시 제출하면 파서를 사용하여 프레젠테이션 개체를 비즈니스 개체로 변환 한 다음 유효성을 검사 할 수 있습니다.

나는 Rudy Lacovara의 블로그 (일명 The Angry .NET Developer)를 읽을 것을 권장합니다. 그는 이런 일에 대해 많은 좋은 말을하는 겸손한 녀석입니다.

HTH

Answer 2

There is no validation approach that fits always.

귀하의 경우에는 mvc2 유효성 검사 (클라이언트 유효성 검사 포함)를 사용하고 viewmodel 유효성 검사가 통과되면 도메인 유효성 검사로 되돌아갑니다.

Answer 3

저는 플러그 형/주사 형 유효성 검사기에 대한 아이디어를 좋아합니다. 이것은 일반적으로 유효성 확인 (예 : webforms, mvc, wpf 등)에 관계없이 진행됩니다. 왜? 유효성 검사 규칙은 시나리오 및 응용 프로그램 계층마다 다릅니다. 예 : 뷰 모델에는 도메인 또는 인프라 규칙이 아닌 UI 레이아웃 때문에 특정 유효성 검사 규칙이있을 수 있습니다. 규칙과 유효성 검사기를 구성 가능하게 만들면 각 계층/시나리오에서 많은 데이터 제약 조건 규칙을 재사용 할 수 있습니다.

Javascript 유효성 검사를 사용하면 사용자가 문제를 일으키지 만, VM에서 javascript 만 사용하는 것은 의심의 여지가 있습니다.