直接在方法代碼中調用DI容器（MVC操作）

我在玩DI（使用Unity）。我學會了如何做構造函數和屬性注入。我有一個靜態容器通過我的Global.asax文件（MvcApplication類）中的屬性公開。直接在方法代碼中調用DI容器（MVC操作）

我需要在我的控制器中的許多不同的對象。將這些注入到構造函數中看起來不太合適，部分原因是它們的數量很大，部分原因是它們僅在某些Actions方法中需要。

問題是，是否有任何錯誤，直接從Action方法內調用我的容器？

public ActionResult Foo() 
{ 
    IBar bar = (Bar)MvcApplication.Container.Resolve(IBar); 
    // ... Bar uses a default constructor, I'm not actually doing any 
    // injection here, I'm just telling my conatiner to give me Bar 
    // when I ask for IBar so I can hide the existence of the concrete 
    // Bar from my Controller. 
}

這似乎是最簡單和最有效的做事方式，但我從來沒有見過這樣的例子。

這有什麼不對嗎？我是否以某種方式遺漏了這個概念？

來源

2010-06-15 fearofawhackplanet

是的，有是使用靜態服務定位器有什麼問題，因爲it's an anti-pattern。

構造注射劑是您的最佳選擇。如果構造函數變得太大，這表示控制器違反了Single Responsibility Principle，您應該refactor to aggregate services。

來源

2010-06-15 10:45:19

感謝馬克，他們是非常好的博客文章。也許tou是正確的，我的控制器違反了SRP。這似乎是一個容易陷入MVC中......與Orders有關的一切都應該進入OrdersController，對吧？好吧，我想也許畢竟不是。但是，您如何知道何時在確定責任方面有足夠的細化程度？我的Controller的職責是在Respository和Views之間轉發數據。我想你可能會認爲這是一項單一責任。但它仍然需要6個輔助對象，具體取決於視圖的哪個位正在改變。 – fearofawhackplanet 2010-06-15 11:15:43

控制器發生了很多事情，並不一定有什麼問題。我的觀點是，我們經常可以將那些許多原子依賴性聚合成更高階的抽象。這給了我們更多的圖層，但是每個圖層都變得不那麼複雜。 – 2010-06-15 11:18:43

直接在方法代碼中調用DI容器（MVC操作）

回答

相關問題