驗證的自定義案例的重構

我有一個用於驗證的類的層次結構，我在某個點想要重構（如果可能且有用），使代碼解耦。驗證的自定義案例的重構

public class DefaultValidation : ValidationList 
    { 
     public DefaultValidation(Cutomer customer, Dto dto) 
     { 
     DefaultRepository repository = new DefaultRepository(); 

     EntityBook entityBook = (EntityBook)repository.GetBookById(dto.IdBook); 
     this.Add(new BookMustBeValidValidation(entityBook)); 

     EntityVideo entityVideo = (EntityVideo)repository.GetVideoById(dto.IdVideo); 
     this.Add(new VideoValidation(entityTask)); 
     this.Add(new OtherNecessaryValidation(dto.OtherProperty)); 
     } 
    }

這個類是一個具體的驗證。我將所有規則添加到列表中，以便我可以添加各種類型的驗證。

（我用這個method似乎有趣）

需要一個refactory的是當我添加另一個同級：

public class SpecialValidation : ValidationList 
    { 
    public SpecialValidation(Cliente cliente, DtoRichiesta richiesta) 
    { 
     this.Add(new OtherNecessaryValidation(dto.OtherProperty)); 
     this.Add(new SpecialAnotherOneValidation(dto.AnotherProperty)); 
    } 
    }

根是共同的，所不同的是哪些類（規則）我注入名單。你認爲應該改變什麼？
感謝

來源

2016-03-31 Max Bertoli

有趣的方法。然而，我不喜歡的一件事是使用例外。異常有兩個缺點：1）它們是性能下降2）當拋出一個異常時，它會阻止你查看其餘的無效斷言。在[CSLA框架]中有一個類似的業務規則引擎（https://github.com/MarimerLLC/csla/blob/d3a2b0707f56b619d6ad46a517a572f3fdeb729d/Samples/ProjectTracker/ProjectTracker.BusinessLibrary.Shared/ValidRole.cs），它允許您查看所有的問題，所以你不必一直糾正和提交他們。 – NightOwl888

我不明白不同的驗證類

DefaultValidation vs SpecialValidation

你爲什麼不有一個大致的驗證類的列表，需要讓說IValidables是根據自己的需要填補。所以對於每個不同的列表，就像你有一個完全不同的驗證類一樣......它有道理嗎？

來源

2016-03-31 14:58:09

我說得很簡單，原因是每個驗證都實現了一個接口，所以我可以使用工廠模式來實例化正確的類。想象一下有不同規則的客戶。我實例化適當的類並附加規則。客戶必須知道什麼，但只有它的ID。換句話說，流程是：客戶傳遞客戶的ID，工廠返回適當的驗證類，並通過「IsValid」的簡單調用給出結果。我希望現在更清楚。 –

驗證的自定義案例的重構

回答

相關問題