DI，IoC的五個W因爲它使我的大腦爆炸

Question

所以控制反轉是一個模糊的描述，因此依賴注入成爲新的定義。這是一個非常非常強大的解決方案，對於從未遇到過這個問題的人來說，這可能會讓人感到困惑。

所以在我追求不成爲頭燈鹿的時候，我讀到了。我發現了幾本了不起的書和在線帖子。但是像所有美妙的事物一樣，更多的問題出現而不是答案。

這個問題吸收了一個未知項目的變量，一旦它們被引入到我的項目中就會被執行。

解決辦法：

public interface ISiteParameter 
{ 
    Guid CustomerId { get; set; } 
    string FirstName { get; set; } 
    string LastName { get; set; } 
    string Phone { get; set; } 
} 

我的注射器：

public interface IInjectSiteParameter 
{ 
    void InjectSite(ISiteParameter dependant); 
} 

然後創建這樣的：

public class SiteContent : IInjectSiteParameter 
{ 
    private ISiteParameter _dependent; 

    #region Interface Member: 
    public void InjectSite(ISiteParameter dependant) 
    { 
     _dependant = dependant; 
    } 
    #endregion 
} 

然後用共享參考實現它被饋送變量我創建了一個類來實現，如：

public class SiteParameters : ISiteParameter 
{  
    public Guid Customer Id { get; set; } 
    public string FirstName { get; set; } 
    public string LastName { get; set; } 
    public string Phone { get; set; } 
} 

現在SiteParameters Class將被其他項目引用;這將讓我實際調用這些屬性隨時隨地用：

ISiteParameter i = new ISiteParameter(); 
MessageBox.Show(i.Guid + i.FirstName + i.LastName + i.Phone); 

這是執行，但我的問題是這樣的...... 什麼時候適合我？

• 構造器注入
• Setter注入
• 接口注入

你什麼時候會用一個或其他？對於我提到的任務，我應該執行這樣一項艱難的任務，以調整對其他項目所做的任何更改？

我在思考過程中是否脫離了曲線？

Answer 1

馬克塞曼

構造方法注入從Dependency Injection in .NET 4章拉應爲DI默認選擇。它解決了一個類需要一個或多個依賴關係的最常見場景。如果依賴類絕對不能在沒有保證有價值的依賴的情況下運行。

只有當你正在開發的類具有良好的本地默認值時，才應該使用屬性注入，並且你仍然希望調用者提供該類的依賴項的不同實現。屬性注入也可用於框架要求您具有默認構造函數（如ASP.NET頁面）的情況。

當依賴關係隨每個方法調用而變化時，最好使用方法注入。當依賴本身表示一個值時，情況就是這樣，但當調用者希望向消費者提供關於調用操作的上下文的信息時，經常會看到這種情況。

Answer 2

只要有可能，我使用構造函數來傳遞depdendencies，而不是通過方法調用注入。

例如：

public interface IWebHost 
{ 
    string DoSomething(string input); 
} 

public class FooManager 
{ 
    private IWebHost _host; 
    public FooManager(IWebHost host) 
    { 
     _host = host; 
    } 

    public void Process() 
    { 
     // do something with _host 
    } 
} 

有許多的這種好處，但兩個我覺得最有利的：

• 我的依賴性指定的前期，有一個機會少被錯過。
• 我可以使用依賴注入存儲庫自動爲我執行構建。

有些情況下，這樣做是不可能或不切實際的，但其中大多數情況下可以通過注入一個工廠來解決問題。

又如：

public interface IConnection : IDisposable 
{ 
    string DoSomething(string input); 
    // implement IDisposable 
} 

public interface IConnectionFactory 
{ 
    IConnection CreateConnection(); 
} 

public class DerpConnection : IConnection 
{ 
    // implementation 
} 

public class DerpConnectionFactory : IConnectionFactory 
{ 
    // We only return DerpConnections from this factory. 

    IConnection CreateConnection() { return new DerpConnection(); } 
} 

public class BarManager 
{ 
    private IConnectionFactory _connectionFactory; 
    public BarManager(IConnectionFactory connectionFactory) 
    { 
     _connectionFactory = connectionFactory; 
    } 

    public void Manage() 
    { 
     using(var connection = _connectionFactory.CreateConnection()) 
     { 
     // do something here. 
     } 
    } 
} 

的DI框架，只需要知道在這個例子中IConnectionFactory和工廠實現直接構建DerpConnection。在單元測試中，我可以輕鬆地嘲笑工廠和IConnection響應。

場景中這是不可能的，通常表明某種cross-cutting concern，或者類比它需要很多更復雜的（和違反SRP）