Spring框架

    Spring，Java的春天，带来了简单、送耦合、可测试这些新生事物，春风吹过，Java大地一片欣欣向荣。Spring的描述是这样的：一个轻量轻级的IOC和AOP容器框架。轻量级体现在它可以打成一个1MB多一点的压缩包，够轻了吧，而且它对内存占用不大。这里主要谈谈它的IOC和AOP。


    IOC即反向控制，Spring就是利用IOC来实现松耦合的。通过与JNDI的对比可以很清楚的了解IOC──我们给JNDI指一个地方告诉它那里有我的东西，JNDI就会听话的去把它给我们找出来；我们什么都没说，什么都没做，IOC却跑过来告诉我们，它在某个地方找到了一个属于我们的东西。也就是说 IOC是JNDI的反转，对象不是从容器中查找它的一来类，而是容器在实例化对象的时候主动将它的依赖类注入。


    比如我们在Controller那里返回给JPS视图一个列表（具体代码在这里http://wuxun1997.iteye.com/blog/453085的第三部分：Controller类），那么我们必然要对数据进行一个查询操作，那么必然要跟数据库扯上关系，但你在Controller并没有看到它实现了Dao接口或实例化了dataSource，仅仅是set进一个Dao属性完事，因为我们在配置文件中已经让他们交朋友了：
首先是Controller和Dao：
<bean id="guideMenuController" class="com.abestek.web.guidemenu.GuideMenuController">
<property name="guideMenuDao" ref="guideMenuDao"/>
</bean>
然后是Dao和dataSource：
<bean id="guideMenuDao" class="com.abestek.dao.GuideMenuDaoImpl">
<property name="dataSource" ref="dataSource"/>
</bean>


    AOP即面向切面，它强大而简单，把业务逻辑从系统服务中分离了出来，避免了业务逻辑与系统服务之间的交叉耦合，同时减少重复了代码。AOP就像一把大刀，可以对你想下手的业务模块一刀切下去，而业务模块自己却还不知道自己已经被砍了，轻易的实现无痛手术。AOP的具体实现是在方法调用时织入，而且我们可以选择是在方法调用的前、后、环绕还是异常抛出后，所以可以根据需要来进行过滤。


    假如我们要对web系统声明式事务进行支持，我们不会去麻烦每一个业务模块，让他们把手头的事停下来处理一下事务，我们悄悄的在他们身上找到切入点，然后不知不觉的把事务织入到他们身上，再悄悄的离开，他们继续着他们的工作，而我们的工作也已经完成。声明式事务也是在配置文件里面，简单的告诉AOP切入点和通知就完事了。在这里
<aop:config proxy-target-class="true">
<aop:advisor pointcut="execution(* *..ProductManager.*(..))" advice-ref="txAdvice"/>
</aop:config>

<tx:advice id="txAdvice">
  <tx:attributes>
  <tx:method name="save*"/>
  </tx:attributes>
</tx:advice>
是对类使用AOP（Spring默认是接口），它声明了一个save事务。


    Spring既是一个AOP框架，又是一个IOC容器。在Spring，你的Bean是通过接口来与Bean的关联类通讯的，其它事情由容器负责解决依赖关系，所以你所要做的就是放手去干，用接口来实现类之间的通信，有IOC在后面撑腰，它可以让你随意替换对象，仅仅动一动JavaBean的属性和配置文件就可以了。而业务逻辑也只要一心做好自己的工作就可以了，不用为别的事操心，因为AOP会帮忙搞定那些麻烦事。