什麼時候使用依賴注入？

Question

我最近一直在使用StructureMap，並且徹底享受了體驗。然而，我可以看到一個人如何輕鬆地將所有東西接合起來，並最終得到一系列將接口帶入構造函數的類。儘管當你使用依賴注入框架時這確實不是一個大問題，但它仍然認爲有些屬性並不需要僅僅爲了連接它們而進行接口連接。

你在哪裏畫出接口的界限，而只是向類中添加一個屬性？

Answer 1

想想你的設計。 DI允許您通過配置更改更改代碼的功能。它還允許您打破類之間的依賴關係，以便您可以更輕鬆地隔離和測試對象。你必須確定這是否合理，哪裏不合適。沒有輕拍的答案。

一個很好的經驗法則是，如果它太難測試，就會遇到單個責任和靜態依賴問題。將執行單個函數的代碼隔離到類中，並通過提取接口並使用DI框架在運行時注入正確的實例來破壞靜態依賴關係。通過這樣做，你可以輕而易舉地分別測試兩個部分。

Answer 2

你是什麼意思的「只是增加一個屬性到一個類？」

我的經驗法則是讓類單元可測試。如果你的類依賴於另一個類的實現細節，那麼需要對其進行重構/抽象，以便可以單獨對這些類進行測試。

編輯：你在構造函數中提到了一堆接口。我會建議使用setter/getters來代替。我發現從長遠來看，維護起來要容易得多。

Answer 3

我這樣做只有當它有助於分離的擔憂。

也許就像跨項目，我將提供實施者的接口在我的庫項目之一，該項目的實施將注入他們想要的任何具體實施。

但僅此而已......所有其他情況它只會使系統不必要的複雜化

Answer 4

即使所有的事實和過程的世界..每一個決定歸結爲主觀判斷 - 忘記在那裏，我讀了
我認爲這更多的是經驗/飛行時間通話。 基本上，如果您看到依賴關係作爲可能在不久的將來被替換的候選對象，請使用依賴注入。如果我將'classA及其依賴項'視爲一個替代塊，那麼我可能不會將A用於DI的迭代。

Answer 5

最大的好處是它可以幫助你理解甚至發現應用程序的體系結構。您將能夠非常清楚地看到您的依賴鏈如何工作，並且能夠對各個部分進行更改，而無需您更改不相關的內容。你最終會得到一個鬆散耦合的應用程序。這會促使你進入更好的設計，當你可以不斷進行改進時，你會感到驚訝，因爲你的設計將幫助你繼續分離和組織代碼。它還可以促進單元測試，因爲您現在有一種自然的方式來替代特定接口的實現。

有一些應用程序只是一次性使用，但如果有疑問，我會繼續創建接口。經過一些練習，這不是什麼負擔。

Answer 6

我摔跤的另一項是我應該在哪裏使用依賴注入？你從哪裏獲得對StructureMap的依賴？只有在啓動應用程序？這是否意味着所有的實現都必須從最頂層到最底層完成交付？

Answer 7

依賴注入的主要問題是，雖然它給出了鬆散耦合架構的外觀，但它確實沒有。

你真正在做的是將這個耦合從編譯時移動到運行時，但是如果類A需要一些接口B工作，還需要提供一個實現接口B的類的實例。

依賴注入只能用於應用程序中需要動態更改而不重新編譯基本代碼的部分。

用途，我已經看到有用的控制模式的反轉：

• 一個插件架構。因此，通過提供正確的入口點，您可以爲必須提供的服務定義合同。
• 工作流式架構。您可以在哪裏連接多個組件，將組件的輸出動態連接到另一個組件的輸入。
• 每個客戶端應用程序。假設您有不同的客戶支付您的項目的一系列「功能」。通過使用依賴注入，您可以輕鬆提供核心組件和一些「添加」組件，這些組件僅提供客戶支付的功能。
• 翻譯。雖然這通常不用於翻譯目的，但您可以根據應用程序的需要「注入」不同的語言文件。這包括根據需要的RTL或LTR用戶界面。

Answer 8

依賴注入應該僅被用於 應用的需要被而無需重新編譯 基碼

動態地改變的部件

DI應被用於分離從外部資源的代碼（數據庫，webservices，xml文件，插件架構）。如果您正在測試數據庫上的DEPEND組件，那麼測試代碼中的邏輯所花費的時間對於很多公司來說幾乎是無法承受的。

在大多數應用程序中，數據庫不會動態變化（儘管可能），但一般來說，不要將應用程序綁定到特定的外部資源，這總是很好的做法。涉及資源變更的數額應該很低（數據訪問類在方法中很少有一個圈複雜度）。

Answer 9

我使用Castle Windsor/Microkernel，我沒有其他任何經驗，但我非常喜歡它。

至於你如何決定注入什麼？到目前爲止，下面的經驗法則對我很好：如果類非常簡單，不需要單元測試，那麼可以隨意在類中實例化，否則可能希望通過構造函數獲得依賴關係。

至於你是否應該創建一個接口，而只是讓你的方法和屬性變爲虛擬的，我認爲你應該去接口路由，要麼你可以看到這個類在不同的應用程序中有一定程度的可重用性（即記錄器）或者b）如果由於構造函數參數的數量或構造函數中存在大量邏輯，該類很難模擬。