我讨厌注解式的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注解。