Spring 概念详解

1、Spring的IoC(Inversion of Control)。 这是Spring中得有特色的一部份。IoC又被翻译成“控制反转”，也不知道是谁翻译得这么别扭，感受很深奥的词。其实，原理很简单，用一句通俗的话来讲：就是用XML来定义生成的对象。IoC实际上是一种设计模式，Spring只是实现了这种设计模式。

这种设计模式是怎么来的呢？是实践中逐渐造成的。

第一阶段：用普通的无模式来写Java程序。通常初学者都要通过这个阶段。 第二阶段：频繁的开始使用接口，这时，接口通常都会伴随着使用工厂模式。 第三阶段：使用IoC模式。工厂模式还不够好：（1）由于的类的生成代码写死在程序里，若是你要换一个子类，就要修改工厂方法。（2）一个接口经常意味着一个生成工厂，会多出不少工厂类。     能够把IoC模式看作是工厂模式的升华，能够把IoC看做是一个大工厂，只不过这个大工厂里要生成的对象都是在XML文件中给出定义的，而后利用Java的“反射”编程，根据XML中给出的类名生成相应的对象。从实现来看，IoC是把之前在工厂方法里写死的对象生成代码，改变为由XML文件来定义，也就是把工厂和对象生成这二者独立分隔开来，目的就是提升灵活性和可维护性。

    IoC中最基本的Java技术就是“反射”编程。反射又是一个生涩的名词，通俗的说反射就是根据给出的类名（字符串）来生成对象。这种编程方式可让对象在生成时才决定要生成哪种对象。我在最近的一个项目也用到了反射，当时是给出一个.properties文本文件，里面写了一些全类名（包名＋类名），而后，要根据这些全类名在程序中生成它们的对象。反射的应用是很普遍的，象Hibernate、String中都是用“反射”作为最基本的技术手段。

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

    因此要理解IoC，你必须先了解工厂模式和反射编程，不然对它产生的来龙去脉和实现原理都是没法理解透彻的。只要你理解了这一点，你本身也彻底能够本身在程序中实现一个IoC框架，只不是这还要涉及到XML解析等其余知识，稍微麻烦一些。

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

    IoC最大的缺点是什么？（1）生成一个对象的步骤变复杂了（其实上操做上仍是挺简单的），对于不习惯这种方式的人，会以为有些别扭和不直观。（2）对象生成由于是使用反射编程，在效率上有些损耗。但相对于IoC提升的维护性和灵活性来讲，这点损耗是微不足道的，除非某对象的生成对效率要求特别高。（3）缺乏IDE重构操做的支持，若是在Eclipse要对类更名，那么你还须要去XML文件里手工去改了，这彷佛是全部XML方式的缺憾所在。

    总的来讲IoC不管原理和实现都还算是很简单的。一些人曾认为IoC没什么实际做用，这种说法是能够理解的，由于若是你在编程中不多使用接口，或不多使用工厂模式，那么你根本就没有使用IoC的强烈须要，也不会体会到IoC难得之处。有些人也说要消除工厂模式、单例模式，可是都语焉不详、人云亦云。但若是你看到IoC模式和用上Spring，那么工厂模式和单例模式的确基本上能够不用了。但它消失了吗？没有！Spring的IoC实现自己就是一个大工厂，其中也包含了单例对象生成方式，只要用一个设置就可让对象生成由普通方式变单一实例方式，很是之简单。

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

2、Spring的MVC

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

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

4、AOP

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

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

学习框架，我认为应该：第一步，了解这个框架中的一些关键概念，它的具体含义是什么。第二步，了解这个框架的精华在哪里，它能对开发起到什么样的做用，最好能对它的原理有必定的了解。第三步，用这个框架来写几个例子，实际体会一下。我如今仍是刚刚大概完成了前两步，这几天会再看看Spring的文档并用Spring写几个例子，到时一块儿发出来。

另外，很赞扬<Spring开发指南>的做者夏昕的观点，将自已的经验写成文档公开出来，不过一我的的力量终究太弱。最好可以造成一个组织，对一种新技术，由一两我的出一个大纲，你们把它分了，更写一章，而后由两三我的总集起。我我的感受，因为英文语言的关系，新技术引进到国内的仍是太慢了，至少要比国外慢上一年以上，成立一个开源文档组织仍是颇有意义的事。