1、概念理解
對Spring耳聞已久，但一直沒有時間和心情去看它，最近它的聲音是越來越大了，Java視線http://forum.javaeye.com/有不高手在談?wù)撍Ｓ谑浅弥锌臻e時間，我也花了兩個晚上看了看Spring，看的是夏昕的<Spring開發(fā)指南>http://www.xiaxin.net/Spring_Dev_Guide.rar，文章寫得不錯。以下談?wù)勎业膶W習感受
一、Spring的IoC(Inversion of Control)。
這是Spring中得有特點的一部份。IoC又被翻譯成“控制反轉(zhuǎn)”，也不知道是誰翻譯得這么別扭，感覺很深奧的詞。其實，原理很簡單，用一句通俗的話來說：就是用XML來定義生成的對象。IoC其實是一種設(shè)計模式，Spring只是實現(xiàn)了這種設(shè)計模式。
這種設(shè)計模式是怎么來的呢？是實踐中逐漸形成的。
第一階段：用普通的無模式來寫Java程序。一般初學者都要經(jīng)過這個階段。
第二階段：頻繁的開始使用接口，這時，接口一般都會伴隨著使用工廠模式。
第三階段：使用IoC模式。工廠模式還不夠好：（1）因為的類的生成代碼寫死在程序里，如果你要換一個子類，就要修改工廠方法。（2）一個接口常常意味著一個生成工廠，會多出很多工廠類。
可以把IoC模式看做是工廠模式的升華，可以把IoC看作是一個大工廠，只不過這個大工廠里要生成的對象都是在XML文件中給出定義的，然后利用Java的“反射”編程，根據(jù)XML中給出的類名生成相應(yīng)的對象。從實現(xiàn)來看，IoC是把以前在工廠方法里寫死的對象生成代碼，改變?yōu)橛蒟ML文件來定義，也就是把工廠和對象生成這兩者獨立分隔開來，目的就是提高靈活性和可維護性。
IoC中最基本的Java技術(shù)就是“反射”編程。反射又是一個生澀的名詞，通俗的說反射就是根據(jù)給出的類名（字符串）來生成對象。這種編程方式可以讓對象在生成時才決定要生成哪一種對象。我在最近的一個項目也用到了反射，當時是給出一個.properties文本文件，里面寫了一些全類名（包名＋類名），然后，要根據(jù)這些全類名在程序中生成它們的對象。反射的應(yīng)用是很廣泛的，象Hibernate、String中都是用“反射”做為最基本的技術(shù)手段。
在過去，反射編程方式相對于正常的對象生成方式要慢10幾倍，這也許也是當時為什么反射技術(shù)沒有普通應(yīng)用開來的原因。但經(jīng)SUN改良優(yōu)化后，反射方式生成對象和通常對象生成方式，速度已經(jīng)相差不大了（但依然有一倍以上的差距）。
所以要理解IoC，你必須先了解工廠模式和反射編程，否則對它產(chǎn)生的前因后果和實現(xiàn)原理都是無法理解透徹的。只要你理解了這一點，你自己也完全可以自己在程序中實現(xiàn)一個IoC框架，只不是這還要涉及到XML解析等其他知識，稍微麻煩一些。
IoC最大的好處是什么？因為把對象生成放在了XML里定義，所以當我們需要換一個實現(xiàn)子類將會變成很簡單（一般這樣的對象都是現(xiàn)實于某種接口的），只要修改XML就可以了，這樣我們甚至可以實現(xiàn)對象的熱插撥（有點象USB接口和SCIS硬盤了）。
IoC最大的缺點是什么？（1）生成一個對象的步驟變復雜了（其實上操作上還是挺簡單的），對于不習慣這種方式的人，會覺得有些別扭和不直觀。（2）對象生成因為是使用反射編程，在效率上有些損耗。但相對于IoC提高的維護性和靈活性來說，這點損耗是微不足道的，除非某對象的生成對效率要求特別高。（3）缺少IDE重構(gòu)操作的支持，如果在Eclipse要對類改名，那么你還需要去XML文件里手工去改了，這似乎是所有XML方式的缺憾所在。
總的來說IoC無論原理和實現(xiàn)都還算是很簡單的。一些人曾認為IoC沒什么實際作用，這種說法是可以理解的，因為如果你在編程中很少使用接口，或很少使用工廠模式，那么你根本就沒有使用IoC的強烈需要，也不會體會到IoC可貴之處。有些人也說要消除工廠模式、單例模式，但是都語焉不詳、人云亦云。但如果你看到IoC模式和用上Spring，那么工廠模式和單例模式的確基本上可以不用了。但它消失了嗎？沒有！Spring的IoC實現(xiàn)本身就是一個大工廠，其中也包含了單例對象生成方式，只要用一個設(shè)置就可以讓對象生成由普通方式變單一實例方式，非常之簡單。
總結(jié)：
（1）IoC原理很簡單，作用的針對性也很強，不要把它看得很玄乎。
（2）要理解IoC，首先要了解“工廠、接口、反射”這些概念。
二、Spring的MVC
如果你已經(jīng)熟悉Struts，那么不必把MVC做為重點學習內(nèi)容。基本上我認為Spring MVC是一個雞肋，它的技術(shù)上很先進，但易用性上沒有Struts好。而且Struts有這么多年的基礎(chǔ)了，Spring很難取代Struts的地位。這就是先入為主的優(yōu)秀，一個項目經(jīng)理選用一種框架，不能單純的從它的技術(shù)上考慮，還有開發(fā)效率，人員配置等都是考慮因素。但做為研究性的學習，Spring的MVC部份還是蠻有價值的。
三、數(shù)據(jù)庫層的模板
Spring主要是提供了一些數(shù)據(jù)庫模板（模板也是一種Java設(shè)計模式），讓數(shù)據(jù)部分的代碼更簡潔，那些try...catch都可以不見了。這個的確是個好東東。
四、AOP
AOP又稱面向方面編程，它的實現(xiàn)原理還是用了反射：通過對某一個種類的方法名做監(jiān)控來實現(xiàn)統(tǒng)一處理。比如：監(jiān)控以“insert”字符串開頭的方法名，在這種方法執(zhí)行的前后進行某種處理（數(shù)據(jù)庫事務(wù)等）。但這里我有一個疑問？不一定所有以insert開頭的方法都是數(shù)據(jù)庫操作，哪么當某個insert開頭的方法不是數(shù)據(jù)庫操作，你又對它進行了數(shù)據(jù)事務(wù)的操作，這樣的錯誤如何防止？？？我對這方面了解不深，還是只知道一個大概。
曾看過一個程序員發(fā)出這樣的感慨：“框架一個接一個，學也學不完，而且有必要嗎？這樣一層層的加上框架，還不如直接寫JSP來得直接，效率還高”。我想這種困惑很多人都有吧？但如果你經(jīng)過的項目漸多，就會發(fā)現(xiàn)，維護項目要比開發(fā)項目更艱難，代價更大。那種用JSP直接來寫，層次又不清楚的開發(fā)，往往最后得到一個不可再修改的軟件，一團亂麻，移一發(fā)而動全身。但軟件不象電視機，做好了就不會改動了，軟件是一個變化的事物，用戶的需求隨時會改變，這時你會體會到分層和使用框架的好處了，它們?yōu)槟阕隽塑浖泻芏嗪蜆I(yè)務(wù)無關(guān)的工作，你可以只關(guān)注業(yè)務(wù)，并減少代碼量。唯一缺點就是有一個學習的代價，框架配置上也較麻煩。
學習框架，我認為應(yīng)該：第一步，了解這個框架中的一些關(guān)鍵概念，它的具體含義是什么。第二步，了解這個框架的精華在哪里，它能對開發(fā)起到什么樣的作用，最好能對它的原理有一定的了解。第三步，用這個框架來寫幾個例子，實際體會一下。我現(xiàn)在還是剛剛大概完成了前兩步，這幾天會再看看Spring的文檔并用Spring寫幾個例子，到時一起發(fā)出來。
另外，很贊賞<Spring開發(fā)指南>的作者夏昕的觀點，將自已的經(jīng)驗寫成文檔公開出來，不過一個人的力量終究太弱。最好能夠形成一個組織，對一種新技術(shù)，由一兩個人出一個大綱，大家把它分了，更寫一章，然后由兩三個人總集起。我個人感覺，由于英文語言的關(guān)系，新技術(shù)引進到國內(nèi)的還是太慢了，至少要比國外慢上一年以上，成立一個開源文檔組織還是很有意義的事。