Spring 中的控制反转
Pro Spring 中文版
◆
46
内部使用或者由其它的依赖关系来完成实际操作。对比在第二章中的MessageRenderer那个例子中,
MessageProvider的依赖不是被动的——它通过必须通过一个需要MessageRenderer的功能来完成这
个工作。
2. 配置参数一般是消息,而不是其它组件。我们这里是说配置参数一般是一些消息片断,组件
需要它们来完成工作。显然SMTP服务器就是一个NewsletterSender所需要的消息片断,但是,
MessageProvider则确实是MessageRenderer正确完成功能所必须的另外一个组件。
3. 配置参数一般是简单的值或者是一组简单值的集合。这实际上是1和2所述问题的一个副产
品,但是配置参数的确一般是简单的值。在Java中意味着它们是原生的(或者对应的封装类)或者
是String再或是这些值的集合。简单值通常是被动的。这意味着你除了操作它本身的数据外,无法对
String做其它的事情;而且你基本上知识拿这些值作为消息使用——例如,某一个int值代表监听的网
络接口的端口号,或者某个String代表一个e-mail程序发送信息要访问的SMTP服务器。当决定是否
要在商务逻辑接口中定义配置选项的时候,同时需要考虑一下这个配置参是对接口的所有实现都适
用还是只对一个有用。例如,在实现NewsletterSender接口的时候,显然所有的实现都需要知道发送
e-mails所用的SMTP服务器。然而,我们会选择将是否发送受保护e-mail的标志从商业逻辑接口中剥
离,因为并不是所有的e-mail应用程序接口(APIs)都能够识别它,设想有大量的实现都不会考虑安
全问题才是正确的。
注意:回忆一下在第 2 章中,我们选择在商用需求中定义依赖关系。这些都是为了描述的目的,
它们都不是最好的实践。
Setter依赖注入还允许你在运行中将依赖关系替换为一个不同的实现,而不需要重新建立一个父
组件的实例。Spring目前还不支持这项功能,但是一旦Spring支持JMX,这个功能就会自我实现了。
也许setter依赖注入的最大优点就是它对注入机制的侵入最小。
如果你为一个恰巧只有默认构造器的类定义了构造器依赖注入,那么你将会在非IoC环境下使用
依赖于它的所有类的时候遇到麻烦。以IoC为目的在类中定义额外的setters并不会影响到其它类与之
交互的能力。
总的来说,基于setter的依赖注入是最佳选择,因为它会使你在非IoC的设置下将其对你代码的
影响降到最低。构造器注入,当你需要在依赖关系传递给组件时要确认的情况下,是一个不错的选
择,但是要记住,很多容器为这种情况提供了它们自己的基于setter依赖注入的机制。示例程序中的
大部分代码都使用了setter依赖注入,虽然那里也有一些例子是基于构造器依赖注入的。
Spring 中的控制反转
我们先前提到过,控制反转是Spring提供的非常重要的一个功能,并且Spring的实现中的核心部
分就是基于依赖注入的,同时还提供了依赖查找的功能。Spring提供自动使独立的对象合作的功能,
当然这使用了依赖注入实现。在基于Spring的应用程序中,总是偏向于通过依赖注入将合作关系传