seaairland

 

学习spring的一些感悟

1  在spring开发指南中有这么一段话
这里暂且抛开Spring Framework在设计上相当出彩的表现不谈。站在应用开发的实际角度来说,
其最大的优势在于:Spring是一个从实际项目开发经验中抽取的,可高度重用的应用框架。认识到这
一点非常重要。
Spring Framework中目前最引人注目的,也就是名为控制反转(IOC =Inverse Of Control)
或者依赖注入(DI =Dependence Injection)的设计思想,这的确是相当优秀的设计理念,但是,
光一个单纯的设计模式并不能使得Spring如此成功,而Spring最成功的地方也并不仅仅在于采用了
IOC/DI的设计。我们前面示例中的ActionFactory,勉强也可算做是一个IOC/DI设计的实现,但又如
何?
可能相关技术媒体和不明就里的技术追随者对于DI/IOC容器的过分炒作,在某种程度上误导了初学
者的视线。“控制反转”,这显然不是一个能望文知意的好名称;“依赖注入”,也好不到哪里去,也正因
为这样,不少初学者都将Spring和生涩的所谓“控制反转”和“依赖注入”看作一个懵懂的高级概念而
供上了神龛。
而实际上,Spring是笔者所见过的,最具实际意义的Java开发框架。它绝非一个高级概念玩具,而
是一个切实的,能实实在在帮助我们改善系统设计的好帮手。
首先,Spring涵盖了应用系统开发所涉及的大多数技术范畴,包括MVC、ORM以及Remote
Interface等,这些技术往往贯穿了大多数应用系统的开发过程。Spring从开发者的角度对这些技术内
容进行了进一步的封装和抽象,使得应用开发更为简便。在笔者的开发工作中,借助Spring提供的丰富
类库,相对传统开发模式,大大节省了编码量(平均1/3强,对于ORM和Remote层也许更多)。
其次,Spring并非一个强制性框架,它提供了很多独立的组件可供选择。如笔者在一些项目中,就
仅引用了Spring的ORM模板机制对数据存取层进行处理,并取得了相当理想的效果。
评定一个框架是否优良的条件固然有很多种,但是笔者始终认为,对于应用系统开发而言,我们面
临着来自诸多方面的压力,此时,最能提高生产力的技术,也就是最有价值的技术。很高兴,Spring让
笔者找到了这样的感觉。
笔者对Rod Johnson最为钦佩的,并不是他用了IOC或者DI,而是他对J2EE应用开发的透彻的理
解。
他真的明白开发人员需要什么。

Type2和Type3型的依赖注入实现则是目前主流的IOC实现模式。这两种实现方式各有特点,也各具
优势(一句经典废话J)。
Type2 设值注入的优势
1. 对于习惯了传统JavaBean开发的程序员而言,通过setter方法设定依赖关系显得更加直
观,更加自然。
2. 如果依赖关系(或继承关系)较为复杂,那么Type3模式的构造函数也会相当庞大(我们需
要在构造函数中设定所有依赖关系),此时Type2模式往往更为简洁。
3. 对于某些第三方类库而言,可能要求我们的组件必须提供一个默认的构造函数(如Struts
中的Action),此时Type3类型的依赖注入机制就体现出其局限性,难以完成我们期望的功
能。
Type3 构造子注入的优势:
1. “在构造期即创建一个完整、合法的对象”,对于这条Java设计原则,Type3无疑是最好的
响应者。
2. 避免了繁琐的setter方法的编写,所有依赖关系均在构造函数中设定,依赖关系集中呈现,
更加易读。
3. 由于没有setter方法,依赖关系在构造时由容器一次性设定,因此组件在被创建之后即处于
相对“不变”的稳定状态,无需担心上层代码在调用过程中执行setter方法对组件依赖关系
产生破坏,特别是对于Singleton模式的组件而言,这可能对整个系统产生重大的影响。
4. 同样,由于关联关系仅在构造函数中表达,只有组件创建者需要关心组件内部的依赖关系。
对调用者而言,组件中的依赖关系处于黑盒之中。对上层屏蔽不必要的信息,也为系统的
层次清晰性提供了保证。
5. 通过构造子注入,意味着我们可以在构造函数中决定依赖关系的注入顺序,对于一个大量
依赖外部服务的组件而言,依赖关系的获得顺序可能非常重要,比如某个依赖关系注入的
先决条件是组件的DataSource及相关资源已经被设定。

posted on 2006-04-04 10:54 chenhui 阅读(165) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 

导航

统计

常用链接

留言簿(1)

随笔分类

随笔档案

文章分类

文章档案

介绍 IOC

友情链接

最新随笔

搜索

积分与排名

最新评论

阅读排行榜

评论排行榜