2013-07-18 3 views
19

client validation이 완료되면 언제 domain level validation을 수행해야합니까?모델 유효성 검증 vs 도메인 모델 유효성 확인

저는 웹 응용 프로그램에 ASP.NET MVC을 사용합니다. 내 domain modelsview models을 구분하고 싶습니다. 내 도메인 모델에는 내 데이터베이스에서 가져온 데이터가 포함되어 있고 내 뷰 모델에는 내 뷰/페이지의 데이터가 들어 있습니다.

내가 고객 데이터로 작업하고 있다고 가정 해 보겠습니다.

데이터베이스에 Customers이라는 테이블이 있습니다.

I는 다음과 같이 볼 수있는 고객 클래스해야합니다 :

public class Customer 
{ 
    public int Id { get; set; } 

    public string FirstName { get; set; } 

    public string LastName { get; set; } 

    public DateTime DateOfBirth { get; set; } 
} 

을 그리고 나는 내보기에있는 데이터 만 표현하기 위해 고객 뷰 모델을 만들 것입니다 :

[Validator(typeof(CustomerCreateViewModelValidator))] 
public class CustomerCreateViewModel 
{ 
    public string FirstName { get; set; } 

    public string LastName { get; set; } 

    public DateTime DateOfBirth { get; set; } 
} 

CustomerCreateViewModel을 허용하고 내 입력 필드를 내보기 모델에 바인딩하는보기를 만들 것입니다 :

@model MyProject.ViewModels.Customers.CustomerCreateViewModel 

@using (Html.BeginForm()) 
{ 
    <table> 
      <tr> 
       <td> 
        @Html.TextBoxFor(x => x.FirstName) 
        @Html.ValidationMessageFor(x => x.FirstName) 
       </td> 
      </tr> 
      <tr> 
       <td> 
        @Html.TextBoxFor(x => x.LastName) 
        @Html.ValidationMessageFor(x => x.LastName) 
       </td> 
      </tr> 
    </table> 

    <button id="SaveButton" type="submit">Save</button> 
} 

알 수 있듯이 유효성 검사 규칙이 포함 된 CustomerCreateViewModelValidator이 있습니다. 사용자가 텍스트 상자에 데이터를 입력하면 제출 버튼을 클릭합니다. 일부 필드가 비어 있으면 유효성 검증이 실패합니다. 모든 필수 필드가 입력되면 유효성 검사가 성공합니다. 내가 가지고

Customer customer = Mapper.Map<Customer>(viewModel); 

이 고객의 도메인 모델을 내 저장소 층에 그것을 통과하고 내 테이블에 데이터를 추가 : 나는 다음과 같이 내 도메인 모델을 내보기 모델의 데이터를 매핑합니다.

도메인 모델에서 유효성 검사를 수행해야하는시기는 언제입니까? 내 모든 뷰 모델에 대한 유효성 검사를 수행합니다. 도메인 모델에서 데이터를 데이터베이스에 추가하기 직전에 데이터를 검증 할 수 있지만 뷰 모델에서 유효성이 검증 된 것이 클라이언트 측에서 동일한 유효성 검사를 복제하는 것만은 아닐까요?

누군가이 인증 문제에 대해 의견을 나누시겠습니까?

+0

레이어 사이에 별도의 유효성 검사 규칙이 있습니까? 그 말은, UI에서 유효한 무언가를 도메인에서 유효하지 않은 것으로 간주 할 수 있습니까? –

+0

현재 둘 다 동일해야합니다. 저는 프로젝트에만 국한되지 않는 검증에 대해 일반화하고 있습니다. –

+1

DDD가 유효성을 검사하는 모든 도메인 객체에 대해'Validate()'인스턴스 메소드쪽으로 기울어 졌을지라도 나는 가질 것입니다. 나는 DDD 전문가로부터 멀리 떨어져있다. +1 흥미로운 질문입니다. –

답변

9

두 레벨 모두에서 항상 유효성을 검사하십시오.

사용자가 잘못된 결과를 얻은 경우 가능한 한 신속하고 쉽게 피드백하기 위해보기 모델의 유효성을 검사해야합니다. 또한 모델이 유효하지 않은 경우 도메인 로직의 나머지 부분에 신경을 쓰고 싶지 않습니다.

그러나보기 모델의 유효성을 검사하고 나면 도메인에서 모든 것이 행복하다는 것을 확인할 수도 있습니다. 간단한 모델의 경우 이러한 검사가 동일 할 수 있으므로 논리가 중복되는 것처럼 보이지만 응용 프로그램이 커지 자마자 동일한 도메인 모델을 사용하는 여러 사용자 인터페이스 또는 여러 응용 프로그램이있을 수 있으므로 도메인 내에서 확인하십시오.

예를 들어 응용 프로그램이 증가하여 고객에게 프로그래밍 방식으로 응용 프로그램과 직접 상호 작용할 수있는 API를 제공하게되면 사용 된 사용자 인터페이스가 응용 프로그램과 직접 상호 작용할 것을 보장 할 수 없으므로 도메인 모델의 유효성을 검사해야합니다. 데이터를 필요로하는 표준에 맞게 (또는 심지어 유효성을 검사 할 때까지). API가받은 데이터는 뷰 모델의 유효성을 확인하는 것과 거의 같은 방법으로 유효성을 검사해야한다는 의견이 있습니다. 뷰 모델 유효성 검사와 동일한 목표를 달성하고 있기 때문에 좋은 생각입니다. 하지만 (UI 또는 API에서 제공되는) 경로에 관계없이 항상 데이터가 유효하다는 것을 보장해야하므로 중앙 위치에서 정의하는 것이 이상적입니다.

두 가지 유효성 검사 수준의 목적도 다릅니다. 보기 모델 유효성 검사에서 모두 (예 : 성이 없거나 성이 너무 길고 DoB가 날짜가 아님)을 알릴 것으로 기대됩니다. 그러나 첫 번째 오류가 발생하면 도메인 논리가 실패하여 문제가 해결 될 것이라고 생각합니다. 다시 간단한 모델의 경우 모든 오류를 수집하여 모두보고 할 수 있지만 응용 프로그램이 복잡해질수록 모든 오류를 예상하기가 더 어려워집니다. 특히 데이터가 논리에 따라 변경되는 경우 더욱 그렇습니다. 그러나 좋은 데이터 만 지나면 괜찮습니다.

0

모델에 대한 클라이언트가 여러 개인 경우에 대비하여 모델 유효성 검사기가 있어야합니다. 예를 들어 모델 및 WPF 응용 프로그램을 호출하는 ASP.NET MVC가있는 경우이 경우 모델에 유효성 검사 논리가 있어야합니다. 하지만 과도 할 클라이언트가 하나 뿐인 경우에는

+0

그렇다면 데이터베이스를 사용하는 애플리케이션이 1 개 밖에없는 경우 뷰 모델에 대한 유효성 검사이면 충분하다고 말하는 것일까 요? –

+1

무엇을 말하자면, 한 클라이언트에서만 리포지토리를 사용한다면 분명히 유효성 검사 논리를 호출하는 컨트롤러를 통해서만 리포지토리에 접근 할 수있는 다른 방법이 없으므로 ViewModel에 대한 유효성 검사로 충분합니다. –

+2

This leads 빈혈 도메인 모델로 도메인 모델은 불변성을 보호해야합니다. – JefClaes

2

나는 클라이언트 유효성 검사가 UI 수준에서 데이터를 더 많이 위생적이라고 생각하는 경향이 있습니다. 즉, 예를 들어 번호 인 입력 필드에 사용자가 숫자를 지정했는지 확인합니다. 또는 텍스트 입력 길이가 최소 길이 요구 사항을 충족시키는 지 여부. 그런 것들.

도메인 수준에서 비즈니스 도메인 규칙을 확인해야합니다. 예를 들어 사용자가 새 제품에 대한 세부 정보를 입력하는 경우 제품 이름이 이미 있습니까? 또는 해당 사용자의 기술을 기반으로 새 사용자를 구성 할 때 사용자에게 유효한 부서가 선택되어 있는지 확인하십시오. 이것은 공기의 예에서 벗어나지 만, 나는 그들이 내가 의미하는 바를 알기를 바랍니다.

6

일반적으로 나는 도메인 모델을 가장 중요한 코드로 간주하여 그 상태를 거룩하게 관리한다고 생각합니다.그 이유는 유효성을 강요하기로되어있는 프리젠 테이션 레이어에서 도메인 모델이 작동했기 때문에 도메인 모델이 유효한 상태에 있다고 가정하지 않습니다. 이는 도메인 계층이 프레젠테이션 계층과 밀접하게 연결되어 있음을 의미합니다.

도메인 모델 밖에서 생각하는 것이 가장 좋습니다 (onion architecture). 이 모든 배경에 대한 추론은 도메인 모델이 시간이 지남에 따라 변할 가능성이 가장 적고 서로 다른 계층의 단점을 보완하여 애플리케이션의 핵심 역할을한다는 것입니다.

고유 한 유효성을 적용하는 도메인 모델부터 시작하여 유효성 검사 코드가 중복되는지 묻습니다. 이것을 피할 수있는 몇 가지 방법이 있습니다. 보기 모델은 예를 들어 도메인 개체를 만들고 유효성 검사 오류로 throw 된 모든 예외를 변환하려고 시도 할 수 있습니다. 유효성 검사기는 추출하여 재사용 할 수도 있습니다. 사용 사례에 따라 가장 적합한 것이 무엇인지 확인해야합니다. 간단하게 유지하십시오. 아마도 유스 케이스가 그렇지 않은 경우에는 유효성 검사를 복제하는 것이 가장 쉽다. 중복 제거는 복잡성을 증가시킵니다.

도메인 계층과 프레젠테이션 계층에서 유효성 검사가 처리 된 코드베이스를 도메인 계층에서만 처리하는 코드 기반을 보았습니다. 도메인 유효성 검사 오류를 컨텍스트 기반 사용자 인터페이스에 의미있게 매핑하는 것이 얼마나 힘든지 알았 기 때문에이 시점에서 유효성 검사 논리를 단순히 복제하는 것이 좋습니다.