這是IoC的正確實施嗎？

我想增加我的控制反轉知識，並發現了一些我想知道的代碼 - 這是真正的IoC嗎？這是IoC的正確實施嗎？

public class DepartmentLogic : IDepartmentLogic 
    { 
     private readonly IDepartmentRepository _departmentRepository; 

     public DepartmentLogic(IDepartmentRepository repo) 
     { 
      _departmentRepository = repo; 
     } 

     public DepartmentLogic() 
     { 
      _departmentRepository = new DepartmentRepository(Constants.CONNECTION_STRING_NAME); 
     } 
    }

如果單元測試調用這個類，它會傳入一個模擬的IDepartmentRepository。但是，所有主要的應用程序代碼都使用具有默認構造函數的類，然後將具體的DepartmentRepository記錄下來。

這是正確的嗎？我想我讀過你不應該在你的調用類中添加依賴類，就像在默認構造函數中發生的一樣，具體的DepartmentRepository的新增應該發生在創建這個類的類中。

來源

2016-09-14 Craig

你說得對。該代碼完全破壞了IoC的目的，並最終實現了緊密耦合的類型。看起來他們只是爲了單元測試而創建了IoC構造函數，而不是將其作爲整體設計方法論。 – itsme86

謝謝，@ itsme86 - 這就是我所擔心的。當我提問時，我被問到，「除了單元測試，IoC沒有其他原因」，我最終不確定如何迴應。我相信這個聲明是無效的，而且有很多原因，但我似乎無法挑選。你能幫忙嗎？ – Craig

我猜[this]（https://en.wikipedia.org/wiki/Coupling_（computer_programming）#Disadvantages）總結了緊密耦合的缺點。 – itsme86

您正在提供將依賴注入到類中的能力。

當你說你的應用程序只是使用默認的構造函數時，你說你沒有實際注入依賴項。它仍然是硬編碼的。

您需要再進一步，並提供一些機制，以便在運行時「動態」創建依賴項，然後將其注入到類中（通過依賴注入框架或其他自定義機制）。

來源

2016-09-14 23:18:54

謝謝@Justin ...當你說「爲動態」創建依賴項「提供某種機制」時，你的意思是Unity（IoC容器 - 我試圖更好地理解的下一件事） – Craig

@Craig - 正確（因此爲什麼我提到了依賴注入框架）。 Unity只是其中之一。我也喜歡Autofac和nInject。 –

只要在構造函數中使用「new」關鍵字，它就會引入緊密耦合， – loneshark99

這是IoC的正確實施嗎？

回答

相關問題