最近我一直在使用很多依賴注入,測試驅動開發和單元測試,並開始喜歡它。構造函數注入/依賴注入 - 處理「根」類
我在類中使用構造函數依賴關係,以便我可以爲單元測試注入模擬依賴關係。
但是,當您真正需要生產環境中的對象時,處理它的最佳方法是什麼?
您是否在使用DependencyInjectionContainer.Get<MyClass>()
來創建課程?或者,爲類創建一個空白構造函數會更有意義,它可以通過DI容器解析所有依賴關係?
最近我一直在使用很多依賴注入,測試驅動開發和單元測試,並開始喜歡它。構造函數注入/依賴注入 - 處理「根」類
我在類中使用構造函數依賴關係,以便我可以爲單元測試注入模擬依賴關係。
但是,當您真正需要生產環境中的對象時,處理它的最佳方法是什麼?
您是否在使用DependencyInjectionContainer.Get<MyClass>()
來創建課程?或者,爲類創建一個空白構造函數會更有意義,它可以通過DI容器解析所有依賴關係?
沒有必要有一個默認的構造函數。
在您的產品代碼中,您通常只需要在應用程序中調用DependencyInjectionContainer.Get(someRootType)
來獲取根類型(例如MVC中的HomeController
類)。由於所有類型都是使用構造函數注入創建的,因此容器將能夠爲您創建相關對象的整個圖形。所以從生產的角度來看,不需要有多個構造函數。
因爲在你的單元測試中你通常要注入所有的模擬對象,你的測試也不會使用默認的構造函數。另一方面,讓每個測試都直接調用被測試類的構造函數很快就會導致難以維護的代碼,因爲當構造函數發生變化時,您將不得不更改所有測試。相反,將該邏輯集中到測試類中的工廠方法。這個工廠方法可以有多個重載,以便測試創建被測試的類。
謝謝,我很希望的解釋對於:)然而,當你想'new()'這個項目時,你會做什麼,例如'var product = new Product();'。你會做'var product = DI.Get
實體壽命短,通常不是由容器創建的。它們通常由「IUnitOfWork」或「IRepository
@KarlCassar:添加到Steve所說的內容:「Serivce」類型對象由DI容器構建並連接在一起。服務對象可以創建「實體」對象。 DI定義定義哪個服務與哪個服務對話,這些服務本身通過傳遞實體彼此對話。 – 2013-02-15 02:18:45
相關:http://stackoverflow.com/questions/4835046/why-not-use-an-ioc-container-to-resolve-dependencies-for-entities-business-objec – Steven 2013-02-15 16:21:27