依賴注入問題

我有一個關於依賴注入模式的問題。我的問題是... 如果我去構造函數注入，注入我的類的依賴關係，我得到的是一個「大」的構造函數與許多參數。如果ie。在某些方法中我不使用一些參數？也就是說。我有一個暴露很多方法的服務。還有一個帶有10個參數的構造函數（所有依賴項）。但並不是所有的方法都使用所有的依賴關係。有些方法只會使用一個依賴項，另一個會使用3個依賴項。但即使使用非容器，DI容器也會解決這些問題。依賴注入問題

對我來說這是使用DI容器的性能損失。這是真的？

來源

2010-11-03 Luka

您還可以隱藏懶惰提供者背後的一些不需要的依賴關係。例如：

public DataSourceProvider implements Provider<DataSource> { 

    public DataSource get() { 
     return lazyGetDataSource(); 
    } 

}

的Provider interface是javax.inject包的一部分。

來源

2010-11-03 09:07:04

實際上，當您構建DI容器時，您無法知道在運行時使用哪些方法。您必須處理性能損失，或者如果您知道有很多情況只使用少量依賴關係，則可以將容器拆分爲幾個注入較少依賴關係的小容器。

來源

2010-11-03 09:01:32 MatthiasG

看來你的班級正在做很多事情，它不符合SOLID（單一職責原則）中的S，也許你可以將班級拆分成多個較小的班級，而且依賴性較少。並不是所有方法都使用所有的依賴關係這一事實表明了這一點。

來源

2010-11-03 09:02:13 Ruben

通常情況下，注入許多依賴項的性能損失很低，但它取決於您選擇的框架。有些人會在飛行中爲此編譯方法。你將不得不測試這個。許多依賴關係確實表明你的班級做得太多了（比如魯本說的），所以你可能想看看這個。如果創建通常不使用的依賴項的實例導致性能問題，則可能需要將工廠作爲依賴項引入。我發現使用工廠可以解決關於使用依賴注入框架的許多問題。

// Constructor 
public Consumer(IContextFactory contextFactory) 
{ 
    this.contextFactory = contextFactory; 
} 

public void DoSomething() 
{ 
    var context = this.contextFactory.CreateNew(); 
    try 
    { 
     // use context here 

     context.Commit(); 
    } 
    finally 
    { 
     context.Dispose(); 
    } 
}

來源

2010-11-03 10:20:51 Steven

由於rube說可能你應該複習你的課程的設計堅持固體原則。

無論如何，如果它不是真的有必要我已經習慣了屬性設置依賴而不是構造函數。這意味着您可以爲每個需要的依賴項創建一個屬性。這也有助於對類進行測試，因爲您只需將所需的依賴項插入到正在執行的測試的上下文中，而不是將所有依賴項即使不需要它也刪除掉

來源

2010-11-03 11:46:44

可變狀態應該完全避免成本。 – 2010-11-03 11:52:27

我同意你的意見。在我的回答中，我同意Rube說他可能會評論他的班級設計。我的第二個評論只是一個實用的:-) – 2010-11-03 17:47:42

依賴注入問題

回答

相關問題