什麼時候應該使用依賴注入像Ninject

我有一些問題了解何時何地正好在我的代碼，我應該使用依賴注入像Ninject。

代碼

比方說，比如我們有下面的代碼：

//WITHOUT NINJECT:  
IMailSender mailSender = new MockMailSender(); 

//WITH NINJECT: 
IMailSender mailSender = kernel.Get<IMailSender>();

這個人是不是一個依賴注入所以它是有意義的在這種情況下使用Ninject？

另一個例子展示瞭如何我的代碼被真正使用依賴注入搞砸：

public void CalculateRevenueRecognitions(IContract contract) 
    { 
     //WITH NINJECT 
     var kernel = new StandardKernel(new DefaultModule()); 
     var arguments = new List<IParameter> 
     { 
      new ConstructorArgument("amount",contract.Revenue), 
      new ConstructorArgument("date", contract.WhenSigned) 
     }; 
     contract.AddRevenueRecognition(kernel.Get<IRevenueRecognition>(arguments.ToArray())); 

     //WITHOUT NINJECT: 
     contract.AddRevenueRecognition(new RevenueRecognition(contract.Revenue, contract.WhenSigned)))); 
    }

問題

當我應該使用依賴注入？

上構造注射，參數注入等
的對象創建（做的依賴注入更換新的？古典對象的創建）
是其他人呢？

時候不應該使用依賴注入？

來源

2013-08-23 MUG4N

在使用Ninject進行項目並獲得一些基本的熟悉之後，測試對我而言變得更加容易。開始使用用例相當困難，您的示例代碼不應該使用它。我想它更多，因爲你有一個查詢類，你想要使用依賴於數據庫類，依賴於設置類等等。您可以在ninject模塊中定義這些綁定，然後請求一個查詢對象，併爲您注入其他依賴類。 – jones6

它的絕對適用於這個代碼，正如我在下面提到的，它被配置在錯誤的地方。大多數依賴關係可以在應用程序啓動時解決。 –

在業務對象方法中使用kernel.Get <>對我來說似乎不適用。我對ninject仍然很陌生，所以我想我錯了。到目前爲止，我只需要使用構造函數注入。 – jones6

如果您想了解相關注射器並學會使用它們看看這篇文章。我很早以前就想知道同樣的事情，這篇文章幫了我很多。

Dependency Injection - Martin Fowler

來源

2013-08-23 19:54:51

我在其他頁面上偶然發現了這篇文章，但沒有閱讀它。我現在會這樣做。 – MUG4N

的事情是，我現在無法想象這樣一個場景，我只是將使用依賴注入自身。我更熟悉使用Inversion of Control（使用DI的IoC容器）的情況。在這種情況下，您的代碼實際上很乾淨，因爲您不必爲實例調用注入器。 IoC容器將爲你做。

所以我認爲，如果不是更好地使用的IoC/DI而不是使用只是DI的。最後，許多成功的框架使用這個組合，他們的非只使用對中的一個（假設他們使用DI可言，因爲其實還有另外一種模式是可能的國際奧委會聯合收割機）。

來源

2013-08-23 20:02:35

的基本前提是不依賴於具體的類（像你說的newing具體類），並注入實現（通過接口）。這取決於你正在執行的具體任務以及在什麼條件下（Windows服務，WCF服務，Asp.Net），但在大多數情況下，你有一個與你想公開公開的所有方法的接口，如

public interface IBar { 
    void DoStuff(); 
}

然後你再使用Ninject即

Bind<IBar>().To<BarClass>();

所以在啓動Ninject去，並得到執行配置這些綁定到特定的類。這樣做的好處是你的實現已經配置好了，所以只要它實現了接口，就可以很容易地切換到另一個實現。所以，如果你有你想現在使用的，而不是BarClass另一個類，你可以只重新綁定到它即

Bind<IBar>().To<NewBarClass>();

所以，你需要的地方使用此NewBarClass，你會通過它在這樣

public class UserOfNewBarClass { 

public UserOfNewBarClass(IBar newBarClass) { 
} 
    // Use the IBar interface 
}

另外，您可以在測試時模擬出接口，這意味着您可以隔離單個具體類並完全隔離地測試它們。你可以做更復雜的事情，稍後你可以學習如綁定基於屬性值和條件綁定你注入什麼。

爲切入點查閱這些

WCF - http://www.aaronstannard.com/post/2011/08/16/dependency-injection-ninject-wcf-service.aspx

MVC - http://www.shahnawazk.com/2010/12/dependency-injection-in-aspnet-mvc-3.html

Windows服務 - Using Ninject with a Windows Service

這很艱難，但是，集裝箱瞭解（在這種情況下Ninject ）根據您指定的綁定找出要注入的實現。最終目標是注入你的類需要的所有東西，以便執行它的方法，以便你可以獨立地測試它（它也有助於保持類的清潔和整潔）。首選的方法是通過構造函數注入，因爲類將在創建時具有所有的依賴關係。物業注入當然是可行的，但與物業一樣，你不能確保它已經設置。

來源

2013-08-23 20:14:25

我在這裏都和你在一起，到目前爲止我理解這個概念。但是，如果你的BarClass真的是一個像（var bar = new BarClass（））這樣的新對象，但是如果這個對象早就被創建了，然後被注入到一個類中，那麼這隻會起作用。那麼對於消費類使用Ninject是否有意義？ – MUG4N

我已經更新，因爲你已經評論，但我會盡量擴大。在應用程序啓動之前，Ninject應該確實已經解決了所有問題您嘗試使用它的上下文是什麼，即什麼類型的應用程序？也許我可以更具體些。 –

對不起，但你只是重複Ninject的用戶指南。我的問題不是如何使用Ninject，而是何時使用以及何時不使用它。不過，我非常感謝你的努力。 – MUG4N

我過去廣泛使用了依賴注入框架。地獄我甚至寫了一個（它執行註冊和分辨率光年快Ninject，雖然我很樂意借用它的有趣的忍者，KiteShields Shuriken等單元測試模型）

這些天，我幾乎沒有使用依賴注入框架。因爲如果我從使用（重）框架中學到了一件事情，那麼它如下：

您有一個技術問題。您可以搜索並試驗將爲您解決問題的框架。你選擇一個並隨處使用它。

現在你有2個問題。你的依賴注入框架只會讓你對整個代碼庫產生很大的依賴。

Greg Young（http://skillsmatter.com/podcast/agile-testing/simple-is-better）在框架上有一個很棒的SkillsMatter演示，聲明和意見可能看起來有點偏激，但其中不少人，我已經學會了艱難的方式，我同意。

來源

2013-08-24 00:04:13 Alex

感謝您與我分享您對IoC框架的看法我會看看您的參考 – MUG4N

我認爲大多數人會認爲，對一個相對容易換出的東西有一個依賴關係要比代碼中潛在的數千個具體依賴關係更好。這是一個相當矛盾的觀點，而不是許多開發人員共享的觀點。如果您的代碼庫將引用傳遞給容器，那麼您最好重新考慮您的架構。 –

@MarkWalsh我沒有爭辯說，管理你的依賴關係並不重要。我表達的觀點是，如果你設計得很好，你不需要一個框架來爲你做這件事，因爲你不可避免地會得到它的依賴，而它所做的「魔術」會讓你付出代價。你真的看了一下我連接的演示文稿，是否顯示了實現這一目標的一種方式？另外，我不能因爲「最爭論的」而煩惱。如果我考慮用最簡潔的方式解決問題，而不是尋找「最爭論」的配方，我發現它更好。 – Alex

什麼時候應該使用依賴注入像Ninject

回答

相關問題