【轉】Spring中IoC的優點與缺點


1. 優點

我們知道,在Java基本教程中有一個定律告訴我們:所有的對象都必須創建;或者說:使用對象之前必須創建,但是現在我們可以不必一定遵循這個定律了,我們可以從Ioc容器中直接獲得一個對象然后直接使用,無需事先創建它們。

  這種變革,就如同我們無需考慮對象銷毀一樣;因為Java的垃圾回收機制幫助我們實現了對象銷毀;現在又無需考慮對象創建,對象的創建和銷毀都無需考慮了,這給編程帶來的影響是巨大的。

  我們從一個簡單例子開始,有一個普通類B代碼如下:

public class B implements BI{
    AInfterface a;

    public B(AInfterface a){
      this.a = a
    }

    public void invoke(){
      /** ...*/
    }
}

  有兩種使用B的方式:

  普通無Ioc容器的調用方式: 
  BI b = new B(new A());//需要在生成B實例之前 生成A等實例
  b. invoke();

  使用Ioc容器的革命調用方式:
  BI b = (BI) WebAppUtil.getService(“b”);
  b. invoke();

  上面兩種方式重要區別:
  前者需要照顧B類中A類的實例化,如果B類中調用不只A類一個,還有更多其他類如C/D/E等類,這樣,你在使用B類時,還需要研究其他類的創建,如果C/D/E這些類不是你自己編寫,你還需要翻閱它們的API說明,研究它們應該如何創建?是使用New 還是工廠模式 還是單態調用?

  這時,你會感嘆:哇,有沒有搞錯?我只不過是為了使用B類中一個小小的方法,就花去我這么多時間和精力?

  當我們使用第二種方式時,就無需花很多精力和時間考慮A/C/D/E等類的創建。

  使用Ioc容器,你再也不必做這些僵化愚蠢的工作了,我們只需從ioc容器中抓取一個類然后直接使用它們。

  當然,在使用之前,我們需要做一個簡單的配置,把你將來需要使用的類全部告訴ioc容器,例如Jdon框架的ioc容器配置jdonframework.xml如下:

<app>
  <services>
    <pojoService name="b" class="test.B"/>
    <pojoService name="a" class="test.A"/>
    <pojoService name="c" class="test.C"/>

  </services>
</app>

  注意:雖然B類代碼調用了A類(甚至可能調用C等其他類),但是在配置中我們無需考慮這種調用關系。因此,整個環節我們都無需考慮B類中涉及其他類的調用關系;這樣是非常省時省力的;特別是如果項目較大,JavaBeans特別多,又是多人協調開發,這種方式對提高開發效率;降低出錯率是非常大的幫助

  如果你的項目中有非常多的類;調用關系很復雜,而且調用關系隨時都可能變化,那么,使用無需照顧調用關系的Ioc容器無疑是減輕開發負擔的首選。

  ioc容器另外一個著名實現是Spring框架,但是在Spring的配置文件applicationContext.xml中,我們必須考慮上述調用關系:

<bean id="b" class="test.B">
  <property name="a"><ref bean="a"/></property><!-- 必須指定調用關系 --> 
  ....
</bean>
<bean id="a" class="test.A">
<bean id="c" class="test.C">

2. 缺點

IoC最大的缺點是什么?

  1. 生成一個對象的步驟變復雜了(其實上操作上還是挺簡單的),對於不習慣這種方式的人,會覺得有些別扭和不直觀。
  2. 對象 生成因為是使用反射編程,在效率上有些損耗。但相對於IoC提高的維護性和靈活性來說,這點損耗是微不足道的,除非某對象的生成對效率要求特別高。

轉自:http://www.jdon.com/AOPdesign/iocimpls.htm


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM