1? 在spring開發指南中有這么一段話
這里暫且拋開Spring Framework在設計上相當出彩的表現不談。站在應用開發的實際角度來說，
其最大的優勢在于：Spring是一個從實際項目開發經驗中抽取的，可高度重用的應用框架。認識到這
一點非常重要。
Spring Framework中目前最引人注目的，也就是名為控制反轉（IOC ＝Inverse Of Control）
或者依賴注入（DI ＝Dependence Injection）的設計思想，這的確是相當優秀的設計理念，但是，
光一個單純的設計模式并不能使得Spring如此成功，而Spring最成功的地方也并不僅僅在于采用了
IOC/DI的設計。我們前面示例中的ActionFactory，勉強也可算做是一個IOC/DI設計的實現，但又如
何？
可能相關技術媒體和不明就里的技術追隨者對于DI/IOC容器的過分炒作，在某種程度上誤導了初學
者的視線。“控制反轉”，這顯然不是一個能望文知意的好名稱；“依賴注入”，也好不到哪里去，也正因
為這樣，不少初學者都將Spring和生澀的所謂“控制反轉”和“依賴注入”看作一個懵懂的高級概念而
供上了神龕。
而實際上，Spring是筆者所見過的，最具實際意義的Java開發框架。它絕非一個高級概念玩具，而
是一個切實的，能實實在在幫助我們改善系統設計的好幫手。
首先，Spring涵蓋了應用系統開發所涉及的大多數技術范疇，包括MVC、ORM以及Remote
Interface等，這些技術往往貫穿了大多數應用系統的開發過程。Spring從開發者的角度對這些技術內
容進行了進一步的封裝和抽象，使得應用開發更為簡便。在筆者的開發工作中，借助Spring提供的豐富
類庫，相對傳統開發模式，大大節省了編碼量（平均1/3強，對于ORM和Remote層也許更多）。
其次，Spring并非一個強制性框架，它提供了很多獨立的組件可供選擇。如筆者在一些項目中，就
僅引用了Spring的ORM模板機制對數據存取層進行處理，并取得了相當理想的效果。
評定一個框架是否優良的條件固然有很多種，但是筆者始終認為，對于應用系統開發而言，我們面
臨著來自諸多方面的壓力，此時，最能提高生產力的技術，也就是最有價值的技術。很高興，Spring讓
筆者找到了這樣的感覺。
筆者對Rod Johnson最為欽佩的，并不是他用了IOC或者DI，而是他對J2EE應用開發的透徹的理
解。
他真的明白開發人員需要什么。
Type2和Type3型的依賴注入實現則是目前主流的IOC實現模式。這兩種實現方式各有特點，也各具
優勢（一句經典廢話J）。
Type2 設值注入的優勢
1． 對于習慣了傳統JavaBean開發的程序員而言，通過setter方法設定依賴關系顯得更加直
觀，更加自然。
2． 如果依賴關系（或繼承關系）較為復雜，那么Type3模式的構造函數也會相當龐大（我們需
要在構造函數中設定所有依賴關系），此時Type2模式往往更為簡潔。
3． 對于某些第三方類庫而言，可能要求我們的組件必須提供一個默認的構造函數（如Struts
中的Action），此時Type3類型的依賴注入機制就體現出其局限性，難以完成我們期望的功
能。
Type3 構造子注入的優勢：
1． “在構造期即創建一個完整、合法的對象”，對于這條Java設計原則，Type3無疑是最好的
響應者。
2． 避免了繁瑣的setter方法的編寫，所有依賴關系均在構造函數中設定，依賴關系集中呈現，
更加易讀。
3． 由于沒有setter方法，依賴關系在構造時由容器一次性設定，因此組件在被創建之后即處于
相對“不變”的穩定狀態，無需擔心上層代碼在調用過程中執行setter方法對組件依賴關系
產生破壞，特別是對于Singleton模式的組件而言，這可能對整個系統產生重大的影響。
4． 同樣，由于關聯關系僅在構造函數中表達，只有組件創建者需要關心組件內部的依賴關系。
對調用者而言，組件中的依賴關系處于黑盒之中。對上層屏蔽不必要的信息，也為系統的
層次清晰性提供了保證。
5． 通過構造子注入，意味著我們可以在構造函數中決定依賴關系的注入順序，對于一個大量
依賴外部服務的組件而言，依賴關系的獲得順序可能非常重要，比如某個依賴關系注入的
先決條件是組件的DataSource及相關資源已經被設定。