Spring 概念詳解

1、Spring的IoC(Inversion of Control)。 這是Spring中得有特色的一部份。IoC又被翻譯成「控制反轉」，也不知道是誰翻譯得這麼彆扭，感受很深奧的詞。其實，原理很簡單，用一句通俗的話來講：就是用XML來定義生成的對象。IoC實際上是一種設計模式，Spring只是實現了這種設計模式。

這種設計模式是怎麼來的呢？是實踐中逐漸造成的。

第一階段：用普通的無模式來寫Java程序。通常初學者都要通過這個階段。 第二階段：頻繁的開始使用接口，這時，接口通常都會伴隨着使用工廠模式。 第三階段：使用IoC模式。工廠模式還不夠好：（1）由於的類的生成代碼寫死在程序裏，若是你要換一個子類，就要修改工廠方法。（2）一個接口經常意味着一個生成工廠，會多出不少工廠類。     能夠把IoC模式看作是工廠模式的昇華，能夠把IoC看做是一個大工廠，只不過這個大工廠裏要生成的對象都是在XML文件中給出定義的，而後利用Java的「反射」編程，根據XML中給出的類名生成相應的對象。從實現來看，IoC是把之前在工廠方法裏寫死的對象生成代碼，改變爲由XML文件來定義，也就是把工廠和對象生成這二者獨立分隔開來，目的就是提升靈活性和可維護性。

    IoC中最基本的Java技術就是「反射」編程。反射又是一個生澀的名詞，通俗的說反射就是根據給出的類名（字符串）來生成對象。這種編程方式可讓對象在生成時才決定要生成哪種對象。我在最近的一個項目也用到了反射，當時是給出一個.properties文本文件，裏面寫了一些全類名（包名＋類名），而後，要根據這些全類名在程序中生成它們的對象。反射的應用是很普遍的，象Hibernate、String中都是用「反射」作爲最基本的技術手段。

    在過去，反射編程方式相對於正常的對象生成方式要慢10幾倍，這也許也是當時爲何反射技術沒有普通應用開來的緣由。但經SUN改良優化後，反射方式生成對象和一般對象生成方式，速度已經相差不大了（但依然有一倍以上的差距）。

    因此要理解IoC，你必須先了解工廠模式和反射編程，不然對它產生的來龍去脈和實現原理都是沒法理解透徹的。只要你理解了這一點，你本身也徹底能夠本身在程序中實現一個IoC框架，只不是這還要涉及到XML解析等其餘知識，稍微麻煩一些。

    IoC最大的好處是什麼？由於把對象生成放在了XML裏定義，因此當咱們須要換一個實現子類將會變成很簡單（通常這樣的對象都是現實於某種接口的），只要修改XML就能夠了，這樣咱們甚至能夠實現對象的熱插撥（有點象USB接口和SCIS硬盤了）。

    IoC最大的缺點是什麼？（1）生成一個對象的步驟變複雜了（其實上操做上仍是挺簡單的），對於不習慣這種方式的人，會以爲有些彆扭和不直觀。（2）對象生成由於是使用反射編程，在效率上有些損耗。但相對於IoC提升的維護性和靈活性來講，這點損耗是微不足道的，除非某對象的生成對效率要求特別高。（3）缺乏IDE重構操做的支持，若是在Eclipse要對類更名，那麼你還須要去XML文件裏手工去改了，這彷佛是全部XML方式的缺憾所在。

    總的來講IoC不管原理和實現都還算是很簡單的。一些人曾認爲IoC沒什麼實際做用，這種說法是能夠理解的，由於若是你在編程中不多使用接口，或不多使用工廠模式，那麼你根本就沒有使用IoC的強烈須要，也不會體會到IoC難得之處。有些人也說要消除工廠模式、單例模式，可是都語焉不詳、人云亦云。但若是你看到IoC模式和用上Spring，那麼工廠模式和單例模式的確基本上能夠不用了。但它消失了嗎？沒有！Spring的IoC實現自己就是一個大工廠，其中也包含了單例對象生成方式，只要用一個設置就可讓對象生成由普通方式變單一實例方式，很是之簡單。

   總結：    （1）IoC原理很簡單，做用的針對性也很強，不要把它看得很玄乎。    （2）要理解IoC，首先要了解「工廠、接口、反射」這些概念。

2、Spring的MVC

若是你已經熟悉Struts，那麼沒必要把MVC作爲重點學習內容。基本上我認爲Spring  MVC是一個雞肋，它的技術上很先進，但易用性上沒有Struts好。並且Struts有這麼多年的基礎了，Spring很難取代Struts的地位。這就是先入爲主的優秀，一個項目經理選用一種框架，不能單純的從它的技術上考慮，還有開發效率，人員配置等都是考慮因素。但作爲研究性的學習，Spring的MVC部份仍是蠻有價值的。

3、數據庫層的模板 Spring主要是提供了一些數據庫模板（模板也是一種Java設計模式），讓數據部分的代碼更簡潔，那些try...catch均可以不見了。這個的確是個好東東。

4、AOP

AOP又稱面向方面編程，它的實現原理仍是用了反射：經過對某一個種類的方法名作監控來實現統一處理。好比：監控以「insert」字符串開頭的方法名，在這種方法執行的先後進行某種處理（數據庫事務等）。但這裏我有一個疑問？不必定全部以insert開頭的方法都是數據庫操做，哪麼當某個insert開頭的方法不是數據庫操做，你又對它進行了數據事務的操做，這樣的錯誤如何防止？？？我對這方面瞭解不深，仍是隻知道一個大概。

曾看過一個程序員發出這樣的感慨：框架一個接一個，學也學不完，並且有必要嗎？這樣一層層的加上框架，還不如直接寫JSP來得直接，效率還高。我想這種困惑不少人都有吧？但若是你通過的項目漸多，就會發現，維護項目要比開發項目更艱難，代價更大。那種用JSP直接來寫，層次又不清楚的開發，每每最後獲得一個不可再修改的軟件，一團亂麻，移一發而動全身。但軟件不象電視機，作好了就不會改動了，軟件是一個變化的事物，用戶的需求隨時會改變，這時你會體會到分層和使用框架的好處了，它們爲你作了軟件中不少和業務無關的工做，你能夠只關注業務，並減小代碼量。惟一缺點就是有一個學習的代價，框架配置上也較麻煩。

學習框架，我認爲應該：第一步，瞭解這個框架中的一些關鍵概念，它的具體含義是什麼。第二步，瞭解這個框架的精華在哪裏，它能對開發起到什麼樣的做用，最好能對它的原理有必定的瞭解。第三步，用這個框架來寫幾個例子，實際體會一下。我如今仍是剛剛大概完成了前兩步，這幾天會再看看Spring的文檔並用Spring寫幾個例子，到時一塊兒發出來。

另外，很讚揚<Spring開發指南>的做者夏昕的觀點，將自已的經驗寫成文檔公開出來，不過一我的的力量終究太弱。最好可以造成一個組織，對一種新技術，由一兩我的出一個大綱，你們把它分了，更寫一章，而後由兩三我的總集起。我我的感受，因爲英文語言的關係，新技術引進到國內的仍是太慢了，至少要比國外慢上一年以上，成立一個開源文檔組織仍是頗有意義的事。