Spring 笔记：整合与 Annotation 的思考

今天去听了一堂组件技术课。讲的是 Spring 。这堂课的 80% 时间都是在重复在达内听过的课程，但是有几点却引起了我重新思考，或许就是所谓的 80/20 法则吧。不废话了：第一点是 XML 配置文件而非 Annotation；另一点是使用 Spring 管理 bean 而把创建、初始化工作交给工厂来做。

XML 配置文件较 Annotation 的优势

首先要回想其为什么用 Spring 而不用其他方法，为什么 IoC 比较重要、要用 Spring 来管理对象。

不要把配置文件单纯地看做配置文件，它们不仅仅是代码的粘合剂，而是一种逻辑控制。实际上，从 Spring 的角度出发，Java 语言是可重用的组件，自 Java 诞生后已经有很多可重用的代码了，只是缺少把他们粘合在一起的方法。而粘合在一起后，这些部分是很容易变化的，应该用一种比较容易编辑控制的语言编写，这就是 XML 配置文件。

从这个原则出发，则我们在为 Spring 编码的时候，应该本着组件的原则来编写，分离出可复用的组件，而不是因为传统的应用都是三层，所以我们也写三层，继而把变化封装到类中，仅仅使用 XML 作为耦合。

如果 Spring 只是耦合，Annotation 足矣。但是，Annotation 的话，就缺少了很多配置的逻辑了。从这个角度看，可以说 Annotation is EVIL。要注意的是，不是说 Evil 就不用了。

工厂方法初始化

这是达内没交给我们的方法，也是贯穿这个学习流程的一个方法。

Spring 框架不是因为要做一个框架而生的，因此，几乎没有教程会把 Spring 首先拿出来讲。那么我们怎么在学习 struts 或者 hibernate 的时候写的代码不都浪费了吗？

这个印象最深的就是写的一个系统。写完发现有新的技术以后又要再写一遍，而且原来的代码就没用了。这个模块很明显是可以嵌入到其他系统中的，因为边界等都很清晰，但是却因为原来紧耦合的时候缺少一种整合到 Spring 松耦合的框架中，否则又和我的系统耦合了，显然不是其他整合系统所希望的；后来学习 Spring 松耦合后，又用 Spring bean 写了一遍，但发布给别人使用却要求别人写一大堆配置文件配置其依赖关系等，如果我提供配置文件，那么配置文件上的名字必须由我定，相当于又把系统耦合到其他人的系统里面了。（这么做不好的前提是模块的开闭原则，如果你不打算这么设计，那么，无所谓了。）

正确的方法，现在看来是，Spring 工厂配置。通过定义 bean 的时候，指定工厂实例或者静态工厂类、指定工厂方法，由工厂来定义 bean 的创建过程。（注意，这里的工厂模式可能配合建造者模式）

这样做的好处是，主系统只需要配置模块提供的服务类接口，以及工厂方法。至于模块内部怎么定义的，就看工厂方法了。