ASP.NET MVC3依賴注入誤解

public object GetService(Type serviceType) 
{ 
    object resolvedObject = null; 
    try 
    { 
     resolvedObject = _unityContainer.Resolve(serviceType); 
    } 
    catch(ResolutionFailedException e) { } 

    return resolvedObject; 
}

這是最佳實踐來捕獲異常並返回null嗎？默認情況下，mvc嘗試解析IControllerFactory和IViewPageActivator，即我得到兩個捕獲異常。我不喜歡這個解決方案。ASP.NET MVC3依賴注入誤解

我的朋友建議檢查的serviceType上IControllerFactory，IViewPageActivator如果拋出一個異常 - 捕獲和記錄的錯誤。但就我而言 - 這不是最好的解決方案，它就像一種硬編碼。

來源

2011-05-05 Antony Blazer

這看起來像您正在使用服務定位器在運行時解析來自IoC容器的依賴關係。就你所知，這是一個非常糟糕的主意，有很多方面。 – 2011-05-05 15:14:26

我應該使用DefaultControllerFactory就像在MVC 2？你能解釋爲什麼這是真的不好主意嗎？ – 2011-05-05 15:16:52

標題說明了這一切... – 2011-05-05 17:57:42

MVC3的DependencyResolver是一個服務定位器，第一位的。它本質上是MVC和Common Service Locator的共同愛好者（commonservicelocator.codeplex.com）。一個CSL服務定位和MVC3的DependencyResolver之間的差異是，MVC建築師決定，他們需要處理，其中服務無法通過它來解決的情況下更安全的方式，以及他們選擇的答案是的IDependencyResolver實施應在這種情況下返回null 。

對於IServiceLocator的CSL實現，標準實踐是拋出ActivationException，它允許處理這些情況的標準化異常。

在MVC中，該框架將調用DependencyResolver嘗試解決一個配置的服務。如果找不到合適的服務，則使用默認服務。

例如，當它想要找到一個IControllerFactory時，它首先檢查DependencyResolver。如果失敗存在，它將使用通過ControllerBuilder.SetControllerFactory(...)配置DefaultControllerFactory。由於這種先檢查方法，最好返回null，然後讓容器特定的異常冒出來。

這意味着您必須在此處捕獲/吞下任何異常，因爲它不是MVC框架的責任，無法爲您處理（責任應該在容器上/ IDependencyResolver本身）。

你可以在這個階段記錄，但其中包含的MVC3做法是在這些情況下返回null。

來源

2011-05-05 15:29:04

感謝您的回答。 – VikciaR 2011-07-07 13:00:52

這顯然不是最佳實踐，但ASP.NET MVC的實施方式是，當IoC無法解析服務時，它應該返回null，以便mvc框架可以回退到默認值。請注意除控制器/視圖工廠以外的其他服務數量取決於它，因此拋出異常將會破壞正在運行的那些服務。

我與內部asp.net郵件列表的設計決策論證，但該如何目前爲:-(。

來源

2011-05-05 18:04:14 kazimanzurrashid

對於IControllerFactory可以

.RegisterType<IControllerFactory, DefaultControllerFactory>()

我不知道哪些類實現IViewPageActivator和ModelMetadataProvider事件雖然可以吞噬異常，但是抑制異常並不是一種好的做法，因爲一般情況下異常會影響性能，一旦遇到異常，框架就會填充堆棧跟蹤，這需要花費時間。

來源

2012-04-03 15:41:07

ASP.NET MVC3依賴注入誤解

回答

相關問題