關於Ioc的思考

　　這幾天都在研究Ioc的實現專案：google的guice。現在被網上炒作的很嚴重，有取代spring的趨勢。看了很多網站寫的這兩個Ioc的專案比較，都誇guice的速度如何好。

　　細細想來，其實這兩個產品都是Ioc的實現，只是實現的思想不同罷了，有和優劣可言呢!

　　spring其實是個非常好的Ioc實現，好在當Java的開發停留在工廠模式下的時候，突然有這個一個Ioc的實現，讓所有的軟體開發人員都為之驚歎。記得在很早以前，我們開發小組的頭，就使用過這種通過Xml配置注射方式來載入不同的實現類。但沒有提出一整套的解決方案。現在想想，不是中國人的智慧少，而是中國人沒有意識將一些好的創業產品化。

　　話說遠了，但重聽。其實Ioc就是個分離各層的解決方案，說複雜其實一點都不復雜。它的實現，使得軟體的層與層之間的耦合更加的鬆散，更加的符合大型專案的開發和管理。也使得AOP的設計思路能夠實現。

　　spring在初期也是得到大家的追捧，guice剛開始起步，不知道能到什麼時候。spring使用xml配置的方式缺點越來越多的暴露出來，因為一個專案開發出來後不可能去現場修改其實現的子類。也就是說xml的靈活性在專案開發出來後成為了專案維護的累贅。由於層與層之間的關係已經不是很明顯，在加上國人非常不喜歡寫文件和注視，為後續的維護增加了困難。

　　guice採用的是java 5的標註方式，其注入可以說更加隱蔽，軟體程式碼的層分離的更加鬆散。雖然通過binder能夠找到它們之間的關係，但也是被guice實現後隱藏。要迅速把握系統的脈搏，就要有比較紮實的功底。另一方面，guice有個先天不足，就是它不可能在jdk1.3等低版本下工作。不要說今天那還有這樣的專案啊，實際的情況會出現的。

　　所以說如果從專案角度來說，如果你的專案只有幾個人就能搞定，都可以不使用這些花哨的架構。當然，從維護性來說，還是使用spring的為好，因為現在懂spring的人多，即使專案組有人離開，也能很快有人接手。

　　說了這麼多，還是強調一點，思想才是重要的，技術只是輔助!

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13270562/viewspace-217887/，如需轉載，請註明出處，否則將追究法律責任。