데이터 검증을위한 디자인 패턴


23

이 문제에 가장 적합한 디자인 패턴은 무엇입니까?

개체 A가 있습니다. 사용자 요청에 따라 데이터베이스에서 개체 A를 등록하거나 삭제할 수 있습니다.

객체의 등록 또는 삭제 전에 데이터 유효성 검사가 수행됩니다. 객체를 등록하기 전에 확인해야 할 규칙 세트와 삭제를위한 다른 규칙 세트가 있습니다. 이러한 규칙 중 일부는 두 작업 모두에 공통입니다.

지금까지 Chain of Responsibility 디자인 패턴이 가장 적합 하다고 생각 하지만 구현에 문제가 있습니다.


6
책임 체인 디자인 패턴이 왜 가장 적합하다고 생각하십니까?
Adam Zuckerman

답변:


17

일반적으로 별도의 유효성 검사기 클래스를 사용하여 각 사용 사례의 유효성을 검사합니다. 예를 들어 데이터베이스에 제품을 추가하기 전에 AddProductValidator를 사용하여 비즈니스 규칙을 확인하고 제품을 삭제하기 전에 DeleteProductValidator를 사용하여 유효성을 검사합니다. 공통 비즈니스 규칙을 사양 클래스 (사양 패턴)로 추출하고 유효성 검사기 클래스에서 공유 할 수 있습니다.

구조 검증 클래스에, 나는 여기에 방법을 따르 http://lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/

.NET을 사용하는 경우 Fluent Validation ( https://github.com/JeremySkinner/FluentValidation ) 을 고려할 수 있습니다 . 나는 그것이 위에서 언급 한 기사와 매우 시원하고 아주 가깝다고 생각합니다.


1
Fluent Validation의 새로운 URL : github.com/JeremySkinner/FluentValidation
Brij

4

설명했듯이 아마도 옵션 유형을 구현할 것입니다 . 그렇게하면 "없음"또는 유효성이 검사 된 값 (아마도 게으름)을 반환 할 수 있지만 구현 세부 사항이며 Decorator 사용 아이디어로 멋지게 이어집니다 .

데코레이터 패턴

물론 인터페이스가보기 흉한 경우 나는 정면을 사용합니다 .


Decorator는 작동하지만 일반적으로 Decorator 패턴을 다른 클래스가 사용할 출력을 입력으로 변환하려는 경우 사용할 것으로 생각합니다. 이 경우 단순히 검증하는 것입니다. 나는 책임의 사슬이 더 잘 작동한다고 생각합니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.