Ist dieses Design zur Datenvalidierung für eine Klasse eine gute Idee?

Question

Ich habe diese Klasse, nennen wir es Rückerstattung (weil es so genannt wird). Ich möchte einige Dinge über diese Rückerstattung und den Kunden validieren, an den sie angehängt ist, und ich möchte diese Validierungen wiederbestellbar machen, da der erste Fehler, der ausgelöst wird, als Ablehnungsgrund auf der Rückerstattung gespeichert wird, und auch einige von ihnen sind Es ist wahrscheinlich ressourcenintensiver als andere und es ist wahrscheinlicher, dass es zu Stolperfallen kommt. Daher würde ich gerne in der Lage sein, ihre Ausführung einfach neu zu ordnen, um bei Bedarf etwas Leistung herauszuholen.

Alle Validierungsmethoden benötigen ein Refund-Objekt und geben einen booleschen Wert zurück, der angibt, ob die Validierung bestanden oder fehlgeschlagen ist. Also, ich dachte, warum nicht eine Warteschlange (oder andere Datenstruktur) machen Delegaten/Lambdas/anonyme Funktionen, die jeweils eine Validierungsmethode darstellen? Übergeben Sie dann die Rückerstattung einfach an eine statische Validate (Refund refundToValidate) -Methode für eine bestimmte Validator-Klasse. Diese Methode würde durch das Array von Delegaten gehen, jedes in der Reihenfolge aufrufen und false zurückgeben, wenn eines von ihnen falsch erzeugt würde.

Ist das eine gute Idee oder eine dumme Idee? Wenn es eine gute Idee ist, kannst du mich irgendwo auf eine Ressource hinweisen oder ein Muster benennen, das ich unabsichtlich implementiere, damit ich weiß, dass ich es richtig mache? Wenn es eine dumme Idee ist, warum und was soll ich anders machen?

EDIT: Hier ist, was ich habe so weit

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; 

     } 
    } 

Answer 1

Sie beschreiben im Grunde eine Optimierung des Chain-of-responsibility Entwurfsmusters. Dies hat Vor- und Nachteile, ist aber eine gute Option, wenn Sie die Möglichkeit haben möchten, jederzeit andere Operationen in Ihre Warteschlange aufzunehmen.

Answer 2

nicht unbedingt eine schlechte Idee. Möchten Sie verfolgen, welche Validierung fehlgeschlagen ist? Wenn Sie eine statische Methode verwenden, die es durch eine Warteschlange ausführt, wie werden Sie das sagen?