2013-08-19 3 views
16

나는이 문제에 직면 한 유일한 사람은 아니지만 지금까지 해결책을 찾을 수 없다고 확신합니다. 문제는 다음과 같습니다.유효성 검사를 위해 사용할 디자인 패턴

레거시 시스템에서 웹 서비스를 게시했습니다 (어떤 컨트롤도없고 변경할 수 없습니다). 모든 클라이언트가 사용하고 있습니다. 나는 웹 서비스와 객체로부터받은 요청을 매우 복잡한 것으로 받아 들인다. 그러나 예를 들어 객체 B, 객체 C와 같은 여러 객체를 포함하는 웹 서비스 호출에서 객체 A를받는다고 할 수있다. 또한 오브젝트 B & C에는 원시 데이터 유형과 그 안에 일부 다른 오브젝트가 있습니다. 내 문제는 내가 전체 개체 A (모든 개체 및 하위 개체 포함), 디자인 패턴을 여기에 권장 유효성을 검사할까요? 둘째, 여기에서 핵심은 웹 서비스에서 여러 유형의 객체 A를 가져올 수 있다는 것입니다. 다른 유형의 객체 A가 실제로 의미하는 것은 객체 A가 클라이언트에 의존한다는 것입니다. 즉, 일부 클라이언트는 포함 객체 B의 데이터를 채우지 않고 객체 A를 보내거나 객체 B를 부분적으로 채우고 객체 A에서 보낼 수도 있습니다 그래서 클라이언트를 기반으로 Object A의 유효성을 검사해야합니다. 일부 클라이언트는 Object B를 포함해야하고 일부는 Object B에 몇 가지 요소가 필요합니다. 즉 다른 말로하면 클라이언트 ABC가 객체 B의 abc 필드에 string 유형이 있고 최대 길이가 25 자이고 원하는 내용을 알려줄 각 클라이언트에 대한 유효성 검사 규칙을 저장하는 장소가 있습니다. 해당 필드에 데이터가 있어야합니다. 내가 수행하고자하는

일부 검증 데이터 유형에 대한 일부 개체의 필드 (개체 B라고) 확인

, 특정 필드의 길이가,이 클라이언트에 필요한 필드 또는 옵션 등 등입니다 ...

구체적인 작동 예제는 매우 유용합니다.

이 특정 예에 대한 객체 A의 구조는 다음과 같습니다.

public class A 
    { 
     private B objectB; 
     private C objectC; 
     // and so on 
    } 

    public class B{ 
     private E objectE; 
     private String name; 
     private int age; 
     // and so on 
    } 

    public class C 
    { 
     private F objectF; 
     private String address; 
     private String country; 
    } 

    public class E 
    { 
     // Members here 
    } 

    public class F 
    { 
     // Members here 
    } 

추신 : 일반 이해를 위해 클래스와 구성원에게 임의의 이름을 지정했습니다. O 예 저는 여기서 자바를 사용하고 있다고 언급하는 것을 잊었습니다. 그러나 디자인 원리 나 패턴이 어떤 언어에도 적용될 수 있기 때문에 정말로 중요하지 않습니다. 곧 너희들의 소식을 듣고 싶다. :)

+1

유효성 검사는 여러 가지 방법으로 수행 할 수 있으며 매우 많은 의견을 바탕으로합니다. [전략 패턴] (http://en.wikipedia.org/wiki/Strategy_pattern)을보십시오. – Bart

+0

전략 패턴 이외의 다른 방법을 권장 할 수 있습니까? –

+0

Visitor 및 Factory/AbstractFactory의 조합을 사용하는 것이 좋습니다. Factory는 특별한 규칙을 가진 클라이언트 타입에 의해 모든 validator 클래스를 생성 할 수 있습니다. 방문자 차는 validator 클래스를 사용하여 전체 구조의 유효성을 검사합니다. –

답변

6

유효성 확인은 교차 절단 우려입니다. 여러 가지 방법이 있으며 여러 가지 디자인 패턴을 구현할 수 있습니다.

Asp.net에서 속성을 통해 수행되고 있습니다. Java Spring에서는 코드를 깨끗하고 읽기 쉽고 유지할 수 있도록 Annotations를 통해 수행됩니다.

다양한 접근 방식을 찾을 수 있습니다.이 프레임 워크의 접근 방식은 다음과 같습니다. 즉 코드 유지 관리, 가독성 및 코드 정리가 필요합니다.

은색 총알이 없습니다. 코드에 유효성 검사를 작성할 수도 있습니다.

+0

당신은 매우 좋은 점을 언급했는데 (나는 그 사실을 잊어 버렸습니다.) 검증은 교차 절단 문제입니다. 고마워. 비즈니스 개체 또는 개체에 유효성 검사 코드를 작성하면 코드가 복잡해지지 않습니까? 나는 그것이 단일 책임 원칙을 위반할 것이라고 생각합니다. 당신은 무엇을 말합니까? –

+1

예, 그렇습니다. 유효성 검사는 로깅과 같은 교차 관심사인데, 때로는 피할 수없는 경우가 있습니다. 주의를 기울여야 할 것은 코드의 정확성, 깨끗하고 읽기 쉽고 반복적이지 않고 유지 보수가 가능한 코드입니다. – DarthVader

+0

전략 패턴 이외의 디자인 패턴을 제안 해 주시겠습니까? 나는 코드를 깨끗하고 읽기 쉽고 유지할 수 있도록 유지하려고 최선을 다하고 DRY 원칙을 따르고 있지만 손이 더러워 져야하는 지점에 도달했다고 생각합니다. :) –

0

각 클래스는 자신을 검증하는 법을 알아야한다. .Validate() 메소드가있는 인터페이스 (예 : IValidatable)에서 각 클래스를 파생시킬 수 있습니다. 개체 A에서 .Validate()를 호출하면 자체적으로 유효성을 검사 한 다음 모든 자식에서 .Validate()를 호출합니다. 그 아이들은 비슷한 방식으로 스스로를 검증 할 수 있습니다.

저는 이것이 명령 패턴의 아주 간단한 버전이라고 생각합니다. 일종의.

클래스에 연결할 수있는 유효성 검사기를 작성할 수도 있습니다. 검사기는 이메일 주소, 정규 주소 등을 검증하는 방법을 알 수 있습니다. 기본적으로 필요한 도구 만 포함하는 클래스에 첨부 할 수있는 도구 상자를 기본적으로 생성하므로 좀 더 확장 가능합니다.

+3

예 처음에는 각 클래스가 자체 유효성 검사를 담당 할 것이라고 생각했지만이 단일 책임 원칙을 위반하면 실제 코드가 비즈니스 코드. 이것에 대한 어떤 생각? –

+0

짧은 대답 : 그것은 다릅니다. 도메인 기반 디자인을 사용했다면 설정자의 모든 속성을 검증 할 수 있습니다. 단일 책임을 염려 할 경우 안전하게 수행 할 수 있습니다. Validator 전략 시나리오를 사용하면 여전히 안전하다고 생각합니다. 유효성 검사기는 유효성을 검사 할 책임이 있습니다. 그것이 유효성 검사를하는 객체에 의해 참조되는 것입니다. –

관련 문제