각 속성을 설정할 때 도메인 엔터티를 확인하거나 나중에 모두 확인하십시오.

Question

도메인 엔티티의 유효성을 검사 할 때 값이 설정되면 유효성을 검사하는 것이 더 좋습니까? 아니면 나중에 (예 : Symfony2와 같은) 유효성 검사기를 사용하여 값을 한 번에 확인하는 것이 더 좋습니까? 예를 들어

:

public function setEmail($email) 
{ 
    if(!filter_var($email, FILTER_VALIDATE_EMAIL)) { 
     throw new EntityException('The specified email address ' . $email . ' is invalid.'); 
    } 

    $this->_email = $email; 
    return $this; 
} 

옵션 2. 검증 나중에 설정되는 동안

옵션 1. 검증 ...

$user = new UserEntity(); 
$user->setEmail('johnnie@duh.com'); 
$validator = new Validator(); 
$validator->validate($user); 

옵션 3. 두 위의 (비록 약간의 중복 및 오버 헤드 가치가없는 것).

나는 첫 번째 것이 더 밀폐 된 엔티티를 만들지 만 두 번째 것은 더 사용자 친화적 인 오류 처리를한다는 것을 알고있다.

또한 두 번째 옵션은 설정자를 조정할 필요가 없으므로 구성 및 유지 관리가 더 쉬워 보이며 유효성 검사 논리를 단일 클래스로 중앙 집중화 할 수 있습니다. 그 귀결은 무엇

...
그래서 기본적으로,이 옵션이 같은 소리가 나는 것을 잊어 버리면 내가하고 싶은,하지만 (예를 들어 기업의 밀폐 다움을 희생 같은 느낌 것입니다 유효성 검사기를 통해 엔티티를 실행), 어리 석을 수 있습니다.

Answer 1

단일 책임 원칙 최선가 분리 층에 필요한 모든 검증을하는 것이다

. 이를 통해 유효성 검사기를 유지 관리하고 테스트하는 것이 더 쉬울 것입니다. 또한 응용 프로그램에서 데이터를 손쉽게 검증 할 수 있습니다.

는 자신이

당신은 각각의 개체에 대한() 유효성 검사를 호출 할 필요가 없습니다 반복하지 마십시오.

저장소 계층 또는 서비스 계층이있는 경우 유효성 검사를 구현하면됩니다. 사용자의 저장소

UserRepository extends AbstractRepository {} 

그리고 모든 엔티티의 공통 검증에 따라서

$user = new User(); 
// [...] 
$user->setEmail('myinvalidemail#blah,com'); 
$repository->save($user); 

: 모두 완료했다 때

abstract class AbstractRepository { 
    public function save($entity) { 
     $validator = // Get your validator based on the entity's name or something else 
     $validator->validate($entity); // Throws exceptions or flag the fields for future use 

     // Now save it... 
    } 
} 

Answer 2

의심 할 여지없이 응용 프로그램 수준에서 유효성 검사가 필요하지 않은 상황이 발생할 수 있습니다 (즉, 특정 지점에서 유효한 데이터로 작업하고 있음을 알고 있음). 이러한 경우에 유효성 검사를 적용해도 아무런 문제가 없지만 확실히 불필요합니다.

또한 들어오는 데이터의 "대량 유효성 검사"를 수행하려는 시나리오에서 찾을 수 있습니다. 이것은 예를 들어 Symfony의 양식 유효성 확인 프레임 워크를 사용하지 않는 서비스 나 맞춤 구현 양식에 더 많이 적용됩니다.

이것들은 옵션 2가 더 바람직한 방법임을 나타낼 수 있습니다. 예를 들어, 모델의 사전 저장 이벤트 중에 유효성 검사기가 객체를 지속하려고 시도 할 때 자동으로 호출되어야한다고주의해야합니다. Doctrine 2에 아직 익숙하지 않지만, Doctrine 1.2 does have its own validation framework that can accomplish this).

유효하지 않은 데이터가있는 것은 결코 바람직한 시나리오는 아니지만 유효하지 않은 데이터가 지속되지 않는다는 것을 확신 할 수 있다면 데이터베이스에서 가져온 데이터가 유효하다는 것을 자유롭게 신뢰할 수 있습니다 (I 여기서 "유효하다"라고 말하고, "신뢰할 수 없다"라고 말하십시오!).