閒談Spring-IOC容器

閒聊

不管是作j2ee開發仍是作j2se開發，spring都是一把大刀。當下流行的ssh三大框架中，spring是最不可替代的，若是不用hibernate和struts，我以爲都可有可無，可是不能沒有spring，可能有人說spring有啥用啊？直接new對象又有何妨，搞了個ioc這麼麻煩，又難以理解，多了這麼多配置，寫代碼時也沒有感受到它存在的價值，曾經我一直這麼認爲，就是帶着這些疑問不斷學習spring，漸漸瞭解它的價值。其實spring帶來的不是某種持久化技術、mvc框架，緩存組件等等，它是一種設計思想（IOC,AOP）,而且利用這種思想容納百川。真正的高深的武功不是他的招式！

 

Ioc容器介紹

Ioc—Inversion of Control，即「控制反轉」。這麼拗口，誰起的名字也不知道。我要是起確定直接叫「對象容器」，雖然不徹底正確，可是基本就是這麼個意思。把咱們編寫的一個個類定義好，註冊到spring容器中，須要用到某個對象的使用不是直接new一個，而是從這個對象容器中取一個就行了。對象的建立原來能夠不用new了直接取？這麼吊，對就是這麼吊。A類中引用了個B類，通常直接在B類中new B()，使用A類的時候new A()初始化的時候就會new B()，若是使用spring那就是直接get(「A」)，而B會自動注入到A對象中。這就是「控制反轉」：將建立對象的權利，反轉給IOC容器。不知道這麼說理解了沒有，畫個圖來表達一下吧。

 

利用IOC咱們在使用建立A對象的時候不用建立B對象，由於B對象由IOC建立好了，拿來就用就行了。「拿來主義多麼的好」。

Ioc的做用

那麼換成從spring容器中取對象有啥好處呢？我還不如直接new個對象來的方便直接，沒有spring程序還不是照常運行。其實這麼說沒有錯，new對象多麼方便，可是有個詞相信你們都聽過「解耦」，就是軟件中組件間要儘可能減小耦合，解耦能夠可以使軟件易於維護，高複用。上面的A類在代碼層次上跟B類的實現不關聯，哪天B類被換成C類又何妨？

有人說A類中不是還有一個B類的引用嗎？

沒錯，是有一個引用指向B對象，可是spring倡導的面相藉口編程，A類中持有的是一個B類的接口，因此C類只要和B類是同一個接口便可。

正是有了IOC容器這種「控制反轉」的設計思想，使得spring幾乎能夠兼容任何流行插件或框架。

使用spring-ioc難道就沒有什麼弊端嗎？

原來在使用spring2.0的時候採用xml配置方式的時候，spring配置文件太多，太繁瑣，可是這個問題在使用了註解方式以後就徹底不存在了。

若是你的系統過小了，不用ioc又何妨呢？可是用了也沒什麼壞處，說不定哪天你的系統又大了呢？

Spring bean的三種配置方式

一、  xml配置方式：

優勢：經典，spring提供的功能均可以經過xml方式配置實現；

缺點：每一個類都要註冊配置，繁瑣！

二、  註解配置方式：

使用<context:component-scan base-package="www.xufei.com"/> 配置，spring就能夠在初始化容器時掃描指定包下的註解，自動註冊到IOC容器中,使用如下：@Component，@Service，Controller，@repository，這幾個註解自己功能並無差別，只是習慣上或者說命名上有差別，分別對應了開發中的服務層，控制層，DAO層。

優勢：很是簡單，強烈推薦

缺點：註解其實也算是侵入了代碼，有些功能沒有xml強大

三、  java配置方式：

使用@Configuration註解在java類上，建立對象的方法上使用 @Bean 註解，便可將方法返回的對象註冊到IOC容器中。

優勢：建立對象的過程清晰可見

缺點：配置的太多的話，好囉嗦啊！

通常都是使用在構建的對象很是複雜的狀況的，咱們須要手工給對象初始化值，便於修改維護。

 

最後

         Spring的設計思想博大精深，有待繼續學習思考。對有點東西的理解須要時間，時間到了就會茅塞頓開，恍然大悟。