2010-10-12 75 views
3

我有一個通用的倉庫 - 應該庫能夠拋出異常,或者我應該保持它的愚蠢?如果我選擇拋出異常,那麼服務層是否應該在捕獲它之前用一個更友好的消息拋出一個異常,然後再發送給Controller?ASP.NET MVC - 拋出異常?

  • POS1:倉庫(擲)=>服務(捕捉,拋出新的)=>控制器(捕捉)
  • POS2:存儲庫=>服務(拋出)=>控制器(捕捉)

回答

2

如果存儲庫能夠拋出 異常或應我保持愚蠢?

是 - 庫應該能夠拋出異常。 「保持某種」愚蠢「並不意味着它不是自我意識:)

」例外應該是例外「的警告仍然適用 - 你可能會發現這個」Creating More Exceptional Exceptions「文章的利益,它也與你的題。

如果我選擇從 拋出異常的,應在服務層,然後 抓它,它去 到控制器之前拋出了 更友好的消息的異常?

通常,我沒有重新拋出異常,雖然有這樣做的好處。一個實用的中途之家應該爲那些你想由於某種原因優雅地處理的異常類型做這件事。

如果你使用像可以設置一個政策(通過配置)耳鼻喉科女士利布斯應用程序日誌模塊,使您可以控制何時發生異常時會發生什麼 - 重新投擲他們或以其他方式;所以這將是一種有用的方法,可以停止對特定結果進行硬編碼。

而且這可能會感興趣:Are exceptions really for exceptional errors?

1

一般來說,你應該簡單地從你的資料庫返回null如果您的查詢返回數據。然後,您可以在將數據發送到視圖之前測試存儲庫中的空值,如果願意的話。

public ActionResult Details(int id) { 

    Dinner dinner = dinnerRepository.FindDinner(id); 

    if (dinner == null) 
     return View("NotFound"); 
    else 
     return View("Details", dinner); 
} 

http://nerddinnerbook.s3.amazonaws.com/Part4.htm

對於編輯我願意讓你的數據訪問層或存儲庫拋出異常,並且抓住它的控制器,就像這樣:

[AcceptVerbs(HttpVerbs.Post)] 
public ActionResult Edit(int id, FormCollection formValues) { 

    Dinner dinner = dinnerRepository.GetDinner(id); 

    try { 

     UpdateModel(dinner); 

     dinnerRepository.Save(); 

     // Success! 
     return RedirectToAction("Details", new { id=dinner.DinnerID }); 
    } 
    catch { 

     // Old-school data validation from ASP.NET MVC 1.0 
     foreach (var issue in dinner.GetRuleViolations()) { 
      ModelState.AddModelError(issue.PropertyName, issue.ErrorMessage); 
     } 

     // Return original view, so user can correct errors. 
     return View(dinner); 
    } 
} 

http://nerddinnerbook.s3.amazonaws.com/Part5.htm

+1

如果我需要更新記錄,那麼我將不得不在我的存儲庫或服務中引發異常? – ebb 2010-10-12 20:04:49

2

絕對選項1

我還要與你的思維「的關注點分離」一詞取代「啞巴」。存儲庫沒有理由愚蠢。它有一個工作要做,而且會涉及例外。

這也將涉及把他們的原因有兩個:

  1. 要打包已經發生的消費代碼真正的錯誤。

  2. 在給定條件下拋出異常,違反了你想讓這個類做什麼。這些條件可能不涉及框架拋出的異常,並且可能僅與您希望存儲庫具有的「智能」有關。

倉庫裏面涉及到封裝所有這一切情報,而使調用代碼只需要知道如何處理一組有限的例外。否則,你的調用代碼需要處理,例如,LINQ異常的全部全部,將它連接到一個應該是存儲庫專用域的技術。

因此,Repositiory智力的一部分必須拋出一個衆所周知的但與其特定目的有關的例外情況。

相同的推理適用於服務層,如果有的話。它需要以完全相同的方式處理異常情況:封裝特定於其任務的「情報」。再次,控制器也是如此。它應該根據自己的目的和關注解釋它從服務層(如果有的話)收到的例外情況。

所以分離的擔憂,但從來沒有愚蠢。甚至不靜音:每個圖層必須在必要時尖叫。