2009-07-10 3 views
1

나는이 클래스를 가지고 있는데, 환불이라고 부르기로한다. 이 환불 및 고객이 첨부 된 고객에 대한 일부 사항을 확인하고 싶습니다. 여행에 필요한 첫 번째 항목이 환불 요청에 거부 이유로 저장 될 것이므로이 유효성 검사를 다시 주문할 수 있도록하고 싶습니다. 다른 사람보다 리소스 집약적 일 가능성이 높고 트립 될 가능성이 높기 때문에 필요한 경우 성능을 압박 할 수 있도록 실행 순서를 쉽게 재정렬 할 수 있기를 바랍니다.클래스의 데이터 유효성 검사를위한이 디자인이 좋은 아이디어입니까?

모든 유효성 검사 메서드는 Refund 개체를 사용하고 유효성 검사가 통과했는지 여부를 나타내는 부울 값을 반환합니다. 그래서, 나는 큐리스트 (또는 다른 데이터 구조)를 delegate/lambdas/anonymous 함수 (각각은 유효성 검사 메소드를 나타냄)를 보유하게 만드는 것이 좋을까요? 그런 다음 Refund를 일부 Validator 클래스에서 정적 Validate (Refund refundToValidate) 메소드로 전달합니다. 이 메서드는 각 대리자를 순차적으로 호출하고 그 중 하나가 거짓이면 false를 반환하는 대리자 배열을 따라 이동합니다.

이것은 좋은 생각입니까 아니면 어리석은 생각입니까? 좋은 생각이라면, 어딘가에서 리소스를 가르쳐 주시겠습니까? 아니면 부주의하게 구현하는 패턴의 이름을 지정할 수 있습니까? 어리석은 생각이라면, 내가 왜 다르게해야 하는가?

편집 : 여기에 내가 멀리있는

public static class Validator 
    { 


     delegate REFUNDDENIALREASONS validationHandler(BatchRefund refundToValidate); 

     public static List<REFUNDDENIALREASONS> ValidateRefund(BatchRefund refundToValidate) 
     { 
      List<Delegate> Validations = new List<Delegate>(); 
      List<REFUNDDENIALREASONS> DenialReasons = new List<REFUNDDENIALREASONS>(); 

      Validations = new List<Delegate>(); 

      validationHandler blockHandler = ValidateBlocks; 
      Validations.Add(blockHandler); 

      validationHandler accountHandler = ValidateCustomerAccountStatus; 
      Validations.Add(accountHandler); 

      foreach (validationHandler v in Validations) 
      { 
       DenialReasons.Add(v(refundToValidate)); 
      } 

      return DenialReasons; 
     } 

     public static REFUNDDENIALREASONS ValidateCustomerAccountStatus(BatchRefund refundToHandle) 
     { 
      REFUNDDENIALREASONS denialReason; 

      switch (refundToHandle.RefundCustomer.CustStatus) 
      { 

       case "C": 
        denialReason = REFUNDDENIALREASONS.None; 
        break; 
       case "Y": 
        denialReason = REFUNDDENIALREASONS.AccounthasrecentChargebackNSF; 
        break; 
       default: 
        denialReason = REFUNDDENIALREASONS.Fraud; 
        break; 
      } 

      return denialReason; 

     } 

     public static REFUNDDENIALREASONS ValidateBlocks(BatchRefund refundToHandle) 
     { 
      List<CustomerBlock> blocks = refundToHandle.RefundCustomer.Blocks; 
      //add new codes to block here 
      string[] illegalblockcodes = new string[] { "L1", "C1" }; 

      foreach (string code in illegalblockcodes) 
       if (blocks.Exists(b => b.BkClassCode == code)) 
       { 
        return REFUNDDENIALREASONS.Fraud; 
       } 

      return REFUNDDENIALREASONS.None; 

     } 
    } 
+0

나는 유효성 검사기 중 하나에서 여러 번 반환되는 것을 알고 있습니다! 선제 적 "내 등을 잡아라!" –

답변

1

기본적으로 Chain-of-responsibility 디자인 패턴에 대한 비틀기를 설명합니다. 여기에는 장단점이 있지만 어느 시점에서든 다른 작업을 큐에 추가 할 수있는 유연성을 원한다면 좋은 옵션입니다.

0

아니 반드시 그렇게 나쁜 생각을 가지고거야. 어떤 검증이 실패했는지 추적하고 싶습니까? 대기열을 통해 실행되는 정적 메서드를 사용하는 경우 어떻게 알 수 있습니까?

+0

오, 전화하세요. 아마도 나는 부울 값보다 좀 더 흥미로운 것을 반환 할 수 있습니다 ... –

+0

아마도 일반적인 ValidationFailed 항목의 일부 목록 일 것입니다. –

+0

나는 List 에서 REFUNDDENIALREASONS가 명백한 enum 인 곳을 결정했다. –

관련 문제