转自:http://blog.csdn.net/competerh_programing/article/details/7262442
一、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,首先要了解“工厂、接口、反射”这些概念。
二、Spring的MVC
如果你已经熟悉Struts,那么不必把MVC做为重点学习内容。基本上我认为Spring MVC是一个鸡肋,它的技术上很先进,但易用性上没有Struts好。而且Struts有这么多年的基础了,Spring很难取代Struts的地位。这就是先入为主的优秀,一个项目经理选用一种框架,不能单纯的从它的技术上考虑,还有开发效率,人员配置等都是考虑因素。但做为研究性的学习,Spring的MVC部份还是蛮有价值的。
三、数据库层的模板
Spring主要是提供了一些数据库模板(模板也是一种Java设计模式),让数据部分的代码更简洁,那些try...catch都可以不见了。这个的确是个好东东。
四、AOP
AOP又称面向方面编程,它的实现原理还是用了反射:通过对某一个种类的方法名做监控来实现统一处理。比如:监控以“insert”字符串开头的方法名,在这种方法执行的前后进行某种处理(数据库事务等)。但这里我有一个疑问?不一定所有以insert开头的方法都是数据库操作,哪么当某个insert开头的方法不是数据库操作,你又对它进行了数据事务的操作,这样的错误如何防止???我对这方面了解不深,还是只知道一个大概。
曾看过一个程序员发出这样的感慨:框架一个接一个,学也学不完,而且有必要吗?这样一层层的加上框架,还不如直接写JSP来得直接,效率还高。我想这种困惑很多人都有吧?但如果你经过的项目渐多,就会发现,维护项目要比开发项目更艰难,代价更大。那种用JSP直接来写,层次又不清楚的开发,往往最后得到一个不可再修改的软件,一团乱麻,移一发而动全身。但软件不象电视机,做好了就不会改动了,软件是一个变化的事物,用户的需求随时会改变,这时你会体会到分层和使用框架的好处了,它们为你做了软件中很多和业务无关的工作,你可以只关注业务,并减少代码量。唯一缺点就是有一个学习的代价,框架配置上也较麻烦。
转自:http://blog.csdn.net/competerh_programing/article/details/7262442