spring 基礎特性--轉滴--比較通俗易懂
一、Spring的IoC(Inversion of Control)
這是Spring中得有特點的一部份。IoC又被翻譯成“控制反轉”，也不知道是誰翻譯得這麼彆扭，感覺很深奧的詞。其實，原理很簡單，用一句通俗的話來說：就是用XML來定義生成的物件。IoC其實是一種設計模式，Spring只是實現了這種設計模式。
這種設計模式是怎麼來的呢？是實踐中逐漸形成的。
第一階段：用普通的無模式來寫Java程式。一般初學者都要經過這個階段。
第二階段：頻繁的開始使用介面，這時，介面一般都會伴隨著使用工廠模式。
第三階段：使用IoC模式。工廠模式還不夠好：
- 因為的類的生成程式碼寫死在程式裡，如果你要換一個子類，就要修改工廠方法；
- 一個介面常常意味著一個生成工廠，會多出很多工廠類；
可以把IoC模式看做是工廠模式的昇華，可以把IoC看作是一個大工廠，只不過這個大工廠裡要生成的物件都是在XML檔案中給出定義的，然後利用Java的“反射”程式設計，根據XML中給出的類名生成相應的物件。從實現來看，IoC是把以前在工廠方法裡寫死的物件生成程式碼，改變為由XML檔案來定義，也就是把工廠和物件生成這兩者獨立分隔開來，目的就是提高靈活性和可維護性。
在過去，反射程式設計方式相對於正常的物件生成方式要慢10幾倍，這也許也是當時為什麼反射技術沒有普通應用開來的原因。但經SUN改良優化後，反射方式生成物件和通常物件生成方式，速度已經相差不大了（但依然有一倍以上的差距）
所以要理解IoC，你必須先了解工廠模式和反射程式設計，否則對它產生的前因後果和實現原理都是無法理解透徹的。只要你理解了這一點，你自己也完全可以自己在程式中實現一個IoC框架，只不是這還要涉及到XML解析等其他知識，稍微麻煩一些。
IoC最大的好處是什麼？因為把物件生成放在了XML裡定義，所以當我們需要換一個實現子類將會變成很簡單（一般這樣的物件都是現實於某種介面的），只要修改XML就可以了，這樣我們甚至可以實現物件的熱插撥（有點象USB介面和SCIS硬碟了）。
IoC最大的缺點是什麼？
- 生成一個物件的步驟變複雜了（其實上操作上還是挺簡單的），對於不習慣這種方式的人，會覺得有些彆扭和不直觀。
- 物件生成因為是使用反射程式設計，在效率上有些損耗。但相對於IoC提高的維護性和靈活性來說，這點損耗是微不足道的，除非某物件的生成對效率要求特別高。
- 缺少IDE重構操作的支援，如果在Eclipse要對類改名，那麼你還需要去XML檔案裡手工去改了，這似乎是所有XML方式的缺憾所在。
總的來說IoC無論原理和實現都還算是很簡單的。一些人曾認為IoC沒什麼實際作用，這種說法是可以理解的，因為如果你在程式設計中很少使用介面，或很少使用工廠模式，那麼你根本就沒有使用IoC的強烈需要，也不會體會到IoC可貴之處。有些人也說要消除工廠模式、單例模式，但是都語焉不詳、人云亦云。但如果你看到IoC模式和用上Spring，那麼工廠模式和單例模式的確基本上可以不用了。但它消失了嗎？沒有！Spring的IoC實現本身就是一個大工廠，其中也包含了單例物件生成方式，只要用一個設定就可以讓物件生成由普通方式變單一例項方式，非常之簡單。
總結：
（1）IoC原理很簡單，作用的針對性也很強，不要把它看得很玄乎。
（2）要理解IoC，首先要了解“工廠、介面、反射”這些概念。
二、Spring的MVC
如果你已經熟悉Struts，那麼不必把MVC做為重點學習內容。基本上我認為Spring MVC是一個雞肋，它的技術上很先進，但易用性上沒有Struts好。而且Struts有這麼多年的基礎了，Spring很難取代Struts的地位。這就是先入為主的優秀，一個專案經理選用一種框架，不能單純的從它的技術上考慮，還有開發效率，人員配置等都是考慮因素。但做為研究性的學習，Spring的MVC部份還是蠻有價值的。三、資料庫層的模板
Spring主要是提供了一些資料庫模板（模板也是一種Java設計模式），讓資料部分的程式碼更簡潔，那些try...catch都可以不見了。這個的確是個好東東。四、AOP
AOP又稱面向方面程式設計，它的實現原理還是用了反射：通過對某一個種類的方法名做監控來實現統一處理。比如：監控以“insert”字串開頭的方法名，在這種方法執行的前後進行某種處理（資料庫事務等）。但這裡我有一個疑問？不一定所有以insert開頭的方法都是資料庫操作，哪麼當某個insert開頭的方法不是資料庫操作，你又對它進行了資料事務的操作，這樣的錯誤如何防止？？？我對這方面瞭解不深，還是隻知道一個大概。曾看過一個程式設計師發出這樣的感慨：框架一個接一個，學也學不完，而且有必要嗎？這樣一層層的加上框架，還不如直接寫JSP來得直接，效率還高。我想這種困惑很多人都有吧？但如果你經過的專案漸多，就會發現，維護專案要比開發專案更艱難，代價更大。那種用JSP直接來寫，層次又不清楚的開發，往往最後得到一個不可再修改的軟體，一團亂麻，移一發而動全身。但軟體不象電視機，做好了就不會改動了，軟體是一個變化的事物，使用者的需求隨時會改變，這時你會體會到分層和使用框架的好處了，它們為你做了軟體中很多和業務無關的工作，你可以只關注業務，並減少程式碼量。唯一缺點就是有一個學習的代價，框架配置上也較麻煩。