2010-08-21 65 views
1

我經常看到人們通過創建接受委託來執行驗證的規則對象來驗證域對象。像這樣的例子「:http://www.codeproject.com/KB/cs/DelegateBusinessObjects.aspx如何在領域層進行驗證

我不明白的是這是怎麼有利地說只是製作方法

舉例來說,特別是文章中有它創建的代表來檢查方法?字符串爲空

但是,這是不一樣的只是有一樣的東西:。

Bool validate() 
{ 
    Result = string.IsNullOrEmpty(name); 
} 

爲什麼經過時,這些在委託製作的對象來保存規則和定義規則的麻煩規則a對上下文敏感並且可能不會被共享。用方法可以達到完全相同的效果。

回答

1

有幾個原因:

SRP - 單一責任原則。對象不應該對自己的驗證負責,它有自己的責任和存在的理由。

此外,當涉及到複雜的業務規則時,明確聲明它們使驗證代碼更易於編寫和理解。

業務規則也傾向於變化很多,比其他域對象更多,所以將它們分開有助於隔離更改。

您發佈的示例太簡單,無法從完全成熟的驗證對象中獲益,但它非常方便,一個系統變得龐大,驗證規則變得複雜。

1

這裏最明顯的例子是一個webapp:填寫表單並點擊「提交」。你的一些數據是錯誤的。怎麼了?

  • Something引發異常。某些東西(可能更高)會捕獲異常並將其打印出來(也許您只會捕獲UserInputInvalidExceptions,但假定其他異常只需記錄)。你看到的第一件事是錯的。
  • 你寫了一個validate()函數。它說「不」。你向用戶展示什麼?
  • 您編寫了一個validate()函數,它返回(或拋出一個異常,或附加到)消息列表。你顯示消息...但按字段分組不是很好嗎?或者將它顯示在錯誤的字段旁邊?你使用元組列表還是元組列表?你想要規則佔多少行?

將規則封裝到對象中可讓您輕鬆地遍歷規則並返回被破壞的規則。您不必爲每個規則編寫樣板附加消息到列表代碼。你可以在破壞他們的領域旁邊粘上破碎的規則。