我建議您閱讀Martin Fowler關於Inversion of Control and Dependency Injection的偉大文章,以更好地理解爲什麼像Spring這樣的框架在編寫軟件時能夠解決衆所周知的一組常見的依賴注入問題。
正如其他人所說,沒有義務使用Spring;無論你使用Spring做什麼,你都可以通過抽象工廠,工廠方法或服務定位器等其他方式來完成。
如果你的項目足夠小,那麼你可能不會介意使用上面提到的那些設計模式來自己解決依賴注入問題。但是,根據項目規模的不同,很多人會傾向於使用已經爲這些經常性頭部劃痕器包裝了一堆解決方案的框架或庫。
關於依賴注入框架在進行單元測試時的優點是你不需要測試你的類的依賴關係,而只需要測試你的類。
例如,很可能您的應用程序具有分層設計。有一個數據訪問類或用於從數據源檢索數據的存儲庫是很常見的。從邏輯上講,你也有一個使用該DAO的課程。
很明顯,您已經爲您的DAO編寫了單元測試,因此,當您測試業務類時(使用DAO的位置),您不必再次測試DAO。
幸運的是,由於Spring需要某種形式的DAO依賴注入,這意味着您的類必須提供一個構造函數或setter方法,通過它可以將該DAO注入到我們的業務類中,對嗎?
那麼,在您的業務類的單元測試期間,您可以方便地使用這些注入點來注入您自己的假DAO(即模擬對象)。這樣,您可以專注於業務類的測試,並忘記重新測試DAO。
現在比較這個想法與其他解決方案,你可能已經在你自己做:
- 您可以直接通過您的業務類中實例化DAO注入的依賴。
- 您可以在代碼中使用靜態工廠方法來訪問DAO。
- 您可以使用代碼中服務定位器的靜態方法來訪問DAO。
這些解決方案將使你的代碼易於測試,因爲沒有簡單的方式選擇正是依賴我想注入到我的商務艙,而測試它的方式獲得(例如你怎麼改用於測試目的的靜態工廠方法使用假DAO?)。
因此,在Spring中,使用XML配置或註釋,可以根據許多條件輕鬆地將不同的依賴關係注入到服務對象中。例如,您可能有一些測試配置,顯然與生產中使用的配置不同。如果您有一個臨時環境,您甚至可能會爲您的應用程序提供不同的XML配置依賴關係,具體取決於它是在生產環境還是集成環境中運行。
依賴關係的可插拔性是我認爲的關鍵贏得因素。因此,正如我剛纔所說的,我的建議是,首先擴展您對Spring核心(以及一般所有依賴注入框架)試圖解決什麼問題的理解以及爲什麼它很重要,並且這會給你更廣泛的視角和理解這些問題的方式,你可以確定什麼時候使用Spring是一個好主意,什麼時候不使用。
你是什麼意思「產生零的測試結果,而不是失敗或過去的測試」? –
我之前沒有進行過單元測試,所以我來自這樣的想法,即當我編寫一個類時,通常需要其他東西來產生任何有意義的結果。我認爲,如果我的課需要一些數據,而且我不會說任何其他課,那麼我的測試沒有給出任何結果,我想如果我寫了任何錯誤,編譯器會好心讓我知道。也許我有不好的設計實踐。 – WPW
如果你只是尋找依賴注入,然後使用普通的簡單設計模式(或類似Guice)。然而,春天是一個爲最小配置提供各種集成組件的生態系統。通過他們我們現在我們贊成通過XML的註釋。 – Rafa