spring 基础特性--转滴--比较通俗易懂

一、Spring的IoC(Inversion of Control)

这是Spring中得有特点的一部份。IoC又被翻译成“控制反转”，也不知道是谁翻译得这么别扭，感觉很深奥的词。其实，原理很简单，用一句通俗的话来说：就是用XML来定义生成的对象。IoC其实是一种设计模式，Spring只是实现了这种设计模式。
这种设计模式是怎么来的呢？是实践中逐渐形成的。

第一阶段：用普通的无模式来写Java程序。一般初学者都要经过这个阶段。

第二阶段：频繁的开始使用接口，这时，接口一般都会伴随着使用工厂模式。

第三阶段：使用IoC模式。工厂模式还不够好：

• 因为的类的生成代码写死在程序里，如果你要换一个子类，就要修改工厂方法；
• 一个接口常常意味着一个生成工厂，会多出很多工厂类；

        可以把IoC模式看做是工厂模式的升华，可以把IoC看作是一个大工厂，只不过这个大工厂里要生成的对象都是在XML文件中给出定义的，然后利用Java的“反射”编程，根据XML中给出的类名生成相应的对象。从实现来看，IoC是把以前在工厂方法里写死的对象生成代码，改变为由XML文件来定义，也就是把工厂和对象生成这两者独立分隔开来，目的就是提高灵活性和可维护性。

        在过去，反射编程方式相对于正常的对象生成方式要慢10几倍，这也许也是当时为什么反射技术没有普通应用开来的原因。但经SUN改良优化后，反射方式生成对象和通常对象生成方式，速度已经相差不大了（但依然有一倍以上的差距）

        所以要理解IoC，你必须先了解工厂模式和反射编程，否则对它产生的前因后果和实现原理都是无法理解透彻的。只要你理解了这一点，你自己也完全可以自己在程序中实现一个IoC框架，只不是这还要涉及到XML解析等其他知识，稍微麻烦一些。

IoC最大的好处是什么？因为把对象生成放在了XML里定义，所以当我们需要换一个实现子类将会变成很简单（一般这样的对象都是现实于某种接口的），只要修改XML就可以了，这样我们甚至可以实现对象的热插拨（有点象USB接口和SCIS硬盘了）。

IoC最大的缺点是什么？

1. • 生成一个对象的步骤变复杂了（其实上操作上还是挺简单的），对于不习惯这种方式的人，会觉得有些别扭和不直观。
   • 对象生成因为是使用反射编程，在效率上有些损耗。但相对于IoC提高的维护性和灵活性来说，这点损耗是微不足道的，除非某对象的生成对效率要求特别高。
   • 缺少IDE重构操作的支持，如果在Eclipse要对类改名，那么你还需要去XML文件里手工去改了，这似乎是所有XML方式的缺憾所在。

        总的来说IoC无论原理和实现都还算是很简单的。一些人曾认为IoC没什么实际作用，这种说法是可以理解的，因为如果你在编程中很少使用接口，或很少使用工厂模式，那么你根本就没有使用IoC的强烈需要，也不会体会到IoC可贵之处。有些人也说要消除工厂模式、单例模式，但是都语焉不详、人云亦云。但如果你看到IoC模式和用上Spring，那么工厂模式和单例模式的确基本上可以不用了。但它消失了吗？没有！Spring的IoC实现本身就是一个大工厂，其中也包含了单例对象生成方式，只要用一个设置就可以让对象生成由普通方式变单一实例方式，非常之简单。

总结：
   （1）IoC原理很简单，作用的针对性也很强，不要把它看得很玄乎。
   （2）要理解IoC，首先要了解“工厂、接口、反射”这些概念。

二、Spring的MVC

        如果你已经熟悉Struts，那么不必把MVC做为重点学习内容。基本上我认为Spring  MVC是一个鸡肋，它的技术上很先进，但易用性上没有Struts好。而且Struts有这么多年的基础了，Spring很难取代Struts的地位。这就是先入为主的优秀，一个项目经理选用一种框架，不能单纯的从它的技术上考虑，还有开发效率，人员配置等都是考虑因素。但做为研究性的学习，Spring的MVC部份还是蛮有价值的。

三、数据库层的模板

        Spring主要是提供了一些数据库模板（模板也是一种Java设计模式），让数据部分的代码更简洁，那些try...catch都可以不见了。这个的确是个好东东。

四、AOP

        AOP又称面向方面编程，它的实现原理还是用了反射：通过对某一个种类的方法名做监控来实现统一处理。比如：监控以“insert”字符串开头的方法名，在这种方法执行的前后进行某种处理（数据库事务等）。但这里我有一个疑问？不一定所有以insert开头的方法都是数据库操作，哪么当某个insert开头的方法不是数据库操作，你又对它进行了数据事务的操作，这样的错误如何防止？？？我对这方面了解不深，还是只知道一个大概。


曾看过一个程序员发出这样的感慨：框架一个接一个，学也学不完，而且有必要吗？这样一层层的加上框架，还不如直接写JSP来得直接，效率还高。我想这种困惑很多人都有吧？但如果你经过的项目渐多，就会发现，维护项目要比开发项目更艰难，代价更大。那种用JSP直接来写，层次又不清楚的开发，往往最后得到一个不可再修改的软件，一团乱麻，移一发而动全身。但软件不象电视机，做好了就不会改动了，软件是一个变化的事物，用户的需求随时会改变，这时你会体会到分层和使用框架的好处了，它们为你做了软件中很多和业务无关的工作，你可以只关注业务，并减少代码量。唯一缺点就是有一个学习的代价，框架配置上也较麻烦。