Spring的一点心得

接触Spring觉得它是个神话，在这之前也看了有关Spring的不少书，可是怎么理解，也许就是古人说的书读百遍其义自现把。^_^。

   在Spring中没有Java类的概念，只有你对Bean的理解到一定程度了，你才会知道Spring团队为什么这样做。这种使用JavaBeans的动机在《Expert One-on-One J2EE Design and Development》的第四章中有描述，在TheServerSide网站上的有免费的PDF版本(http://www.theserverside.com/resources/article.jsp?l=RodJohnsonInterview)。通过BeanFactory概念，Spring成为一个Inversion of Control的容器。(我不怎么喜欢container这个词，因为它使人联想到重量级容器，如EJB容器。Spring的BeanFactory是一个可通过一行代码创建的容器，并且不需要特殊的部署步骤。)

当你对Sping的Bean有所理解以后你必须看看BeanFactory，在这之后可以看看IOC和AOP，它才是Spring的核心。当然Spring也有control 并且它的control 层不一定就比不上Struts。在这里我就不去细讲。

大家一直都说spring的IOC如何如何的强大，其实我倒觉得不是IOC如何的强大，说白了IOC其实也非常的简单。我们先从IOC说起，这个概念其实是从我们平常new一个对象的对立面来说的，我们平常使用对象的时候，一般都是直接使用关键字类new一个对象，那这样有什么坏处呢？其实很显然的，使用new那么就表示当前模块已经不知不觉的和new的对象耦合了，而我们通常都是更高层次的抽象模块调用底层的实现模块，这样也就产生了模块依赖于具体的实现，这样与我们JAVA中提倡的面向接口面向抽象编程是相冲突的，而且这样做也带来系统的模块架构问题。很简单的例子，我们在进行数据库操作的时候，总是业务层调用DAO层，当然我们的DAO一般都是会采用接口开发，这在一定程度上满足了松耦合，使业务逻辑层不依赖于具体的数据库DAO层。但是我们在使用的时候还是会new一个特定数据库的DAO层，这无形中也与特定的数据库绑定了，虽然我们可以使用抽象工厂模式来获取DAO实现类，但除非我们一次性把所有数据库的DAO写出来，否则在进行数据库迁移的时候我们还是得修改DAO工厂类。

　　那我们使用IOC能达到什么呢？IOC，就是DAO接口的实现不再是业务逻辑层调用工厂类去获取，而是通过容器（比如spring）来自动的为我们的业务层设置DAO的实现类。这样整个过程就反过来，以前是我们业务层主动去获取DAO，而现在是DAO主动被设置到业务逻辑层中来了，这也就是反转控制的由来。通过IOC，我们就可以在不修改任何代码的情况下，无缝的实现数据库的换库迁移，当然前提还是必须得写一个实现特定数据库的DAO。我们把DAO普遍到更多的情况下，那么IOC就为我们带来更大的方便性，比如一个接口的多个实现，我们只需要配置一下就ok了，而不需要再一个个的写工厂来来获取了。这就是IOC为我们带来的模块的松耦合和应用的便利性。

其实Spring的IOC提倡的是我们一直所说的低耦合与高类聚；

我们再来看看AOP。AOP的编程思想只是OOP的一种延续，它并不能代替OOP（在一次面试中我是这样回答我的面试官）。

Spring AOP透明地与Spring BeanFactory概念集成。包含一个来自Spring BeanFactory对象地代码不需要知道它是还是不是advised。和任何对象一样，契约实在接口和对象实现中定义的。

AOP经常被定义为一种编程技术，用来在系统中提升业务的分离，系统有很多组件组成，每一组件负责一部分功能。然而，这些组件也经常带有一些除了核心功能之外的附带功能。系统服务如日志、事务管理和安全经常融入到一些其他功能模块中。这些系统服务通常叫做交叉业务，这是因为，它们总是分布在系统的很多组件中，通过将这些业务分布在多个组件中，你给你的代码引入了双重复杂性。