我討厭註解式的Spring IOC

spring的ioc，本來是在「實例」層面上的。一樣的一個類，我能夠經過多個<bean>標籤，獲得多個實例。而且，每一個bean中的屬性配置均可以不同，從而使我獲得多個不同的實例。

舉個例子。我寫過這樣一個類：

class A implements AI{

    private B b;

    private C c;

    private D d;

    @Override

    public void aService(){

        b.bService();

        c.cService();

        d.dService();

    }

    // accessers

}

配置是這樣的

<bean id="a1" class="A">

    <property name="b" ref="b1"/>

    <property name="c" ref="c1"/>

    <property name="d" ref="d1"/>

</bean>

<bean id="a2" class="A">

    <property name="b" ref="b2"/>

    <property name="c" ref="c2"/>

    <property name="d" ref="d2"/>

</bean>

題外話，當時寫完這個服務，本身很開心。由於我無心間找到了用組合而不是繼承的方式，來實現模板模式的方法。

在這裏，spring ioc經過xml中的bean，爲同一個類配置出了不一樣的實例。這就是我所說的，在「實例」層面上的ioc。

可是註解呢？註解把ioc挪到了類的層面上。一個類只能有一套配置、獲得一個實例。我找了好久，才找到一個@Bean和@Configuration。也仍是麻煩得要死，遠不如xml來得方便、明瞭。

另外，使用註解方式時，對父類屬性的配置也是個麻煩。我須要給子類重寫set方法，而後將@Resource標籤放在重寫的標籤上。可是xml呢？用parent屬性就很輕鬆了。

還有一些問題，讓spring ioc的註解來背鍋是有點冤枉。不過，也有這方面的因素。

註解用多了，會影響程序員對spring ioc的使用和理解。使用方面，xml配置中有一些「高級」的用法，註解用不了，或者很麻煩。前面說的parent，另外還有abstract都算用不了的；甚至有人不知道scope的用法和含義的。理解上，我也見過有人一直不明白spring容器和bean、實例之間的關係的。這些人的開發經驗都很多，至少是能夠獨立負責一個服務的開發和維護的。

此外，因爲一直都是「一個類只能有一個實例；一個實例中實現全部流程」的思路，造成了「全部流程都在一個類中」的定勢。結果，沒有接口和實現，沒有繼承和子類，沒有重載和重寫。每當有流程變化，有功能變化，都加if-else，加switch。好好的一個系統，迅速的腐爛成泥。

不過xml也確實有問題：隨着系統變大，xml文件也會愈來愈多、愈來愈大。不過，相比這種複雜性，我更討厭膠柱鼓瑟的ioc註解。