2012-03-18 241 views
2

依賴注入的一個優點是類的依賴性在其接口(即構造函數)中顯式定義。但是,如果使用依賴注入容器,則這些依賴關係中的很多依賴項會合併到一個依賴項(容器)中。因此,許多類的真正依賴關係隱藏在容器後面。如何避免這種情況,以便依賴關係在使用依賴注入容器時仍被明確定義?使用依賴注入容器時明確依賴關係

+1

沒有一貫地採用構造器注入類取決於DI容器。你*可能*使用一個容器來連接這些類,但是你不需要。這不夠明確嗎? – 2012-03-18 08:15:02

+0

如果A類是使用DI容器構造的,並且A具有-A B,​​B具有C,那麼C如何訪問其所需的依賴關係?如何將類放在調用堆棧訪問相關的幾個級別上? – orourkedd 2012-03-18 16:10:31

+0

它們也使用構造函數注入。所以如果C依賴於D,它就通過它的構造函數獲取它。 – 2012-03-18 17:21:42

回答

0

我3年前問這個問題,並有因爲來了解和熱愛DI在靜態類型語言。

它看起來就像當我問這個問題我不明白「服務定位器」和「依賴注入容器」(DIC)之間的差異。

甲DIC操作「下面」的應用程序,負責構造對象,建立對象圖,通常在自舉,但如果充分自舉的應用之前。 班級不應該知道DIC,不應該依賴它。 DIC應該構造該類的所有依賴關係,並將它們注入,就好像類正在手動實例化一樣。

服務定位器是一個傳遞給系統並用於查找依賴關係的對象。使用服務定位器掩蓋了依賴關係(我在學習這些東西時注意到的原始問題),並創建了系統範圍的依賴關係(即服務定位器本身)。

一般來說,我會避免的服務定位器模式(有人稱之爲「反模式」)。使用Ninject或Symfony 2的DIC等良好的DIC將讓您的課程專注於其中的業務邏輯 - 而不是尋找依賴關係。

上依賴注入閱讀馬丁福勒斯文章:http://www.martinfowler.com/articles/injection.html

0

是一個類似的問題也沒有,這真的取決於你如何依賴注入容器的作品。

我看不出有任何問題,這種代碼:

class Class1 { 
    /** 
    * @Inject 
    * @var Class2 
    */ 
    private $class2; 
} 

即使依存度將通過容器注入,即Class1取決於Class2其實是相當明確的。 (這裏使用依賴注入容器是PHP-DI