目录
  1. 1. IoC Service Provider的职责
  2. 2. 运筹帷幄的秘密——IoC Service Provider 如何管理对象间的依赖关系
    1. 2.1. 直接编码方式
    2. 2.2. 配置文件方式
    3. 2.3. 元数据方式
    4. 2.4. 小结
Spring揭秘-掌管大局的IoC Service Provider

本章内容:
IoC Service Provider的职责
运筹帷幄的秘密——IoC Service Provider如何管理对象间的依赖关系

虽然业务对象可以通过IoC方式声明相应的依赖,但是最终仍然需要通过某种角色或者服务将这些相互依赖的对象绑定到一起,而IoC Service Provider就对应IoC场景中的这一角色。

IoC Service Provider在这里是一个抽象出来的概念,它可以指代任何将IoC场景中的业务对象绑定到一起的实现方式。它可以是一段代码,也可以是一组相关的类,甚至可以是比较通用的IoC框架或者IoC容器实现。

1
2
3
4
IFXNewsListener newsListener = new DowJonesNewsListener();
IFXNewsPersister newsPersister = new DowJonesNewsPersister();
FXNewsProvider newsProvider = new FXNewsProvider(newsListener,newsPersister);
newsProvider.getAndPersistNews();

这段代码就可以认为是这个场景中的IoC Service Provider,只不过比较简单,而且目的也过于单一罢了。要将系统中几十、几百甚至数以千计的业务对象绑定到一起,采用这种方式显然是不切实际的。通用性暂且不提,单单是写这些绑定代码也会是一种很糟糕的体验。

不过,好在现在许多开源产品通过各种方式为我们做了这部分工作。所以,目前来看,我们只需要使用这些产品提供的服务就可以了。 Spring的IoC容器就是一个提供依赖注入服务的IoC Service Provider。

IoC Service Provider的职责

IoC Service Provider的职责相对来说比较简单,主要有两个:业务对象的构建管理和业务对象间的依赖绑定。

  • 业务对象的构建管理。

    在IoC场景中,业务对象无需关心所依赖的对象如何构建如何取得,但这部分工作始终需要有人来做。所以,IoC Service Provider需要将对象的构建逻辑从客户端对象那里剥离出来,以免这部分逻辑污染业务对象的实现。

  • 业务对象间的依赖绑定。

    对于IoC Service Provider来说,这个职责是最艰巨也是最重要的,这是它的最终使命之所在。如果不能完成这个职责,那么,无论业务对象如何的“呼喊”,也不会得到依赖对象的任何响应(最常见的倒是会收到一个NullPointerException)。 IoC Service Provider通过结合之前构建和管理的所有业务对象,以及各个业务对象间可以识别的依赖关系,将这些对象所依赖的对象注入绑定,从而保证每个业务对象在使用的时候,可以处于就绪状态。

运筹帷幄的秘密——IoC Service Provider 如何管理对象间的依赖关系

被注入对象可以通过多种方式通知IoC Service Provider为其注入相应依赖。但问题在于,收到通知的IoC Service Provider是否就一定能够完全领会被注入对象的意图,并及时有效地为其提供想要的依赖呢?有些时候,事情可能并非像我们所想象的那样理所当然。

对于为被注入对象提供依赖注入的IoC Service Provider来说,它也同样需要知道自己所管理和掌握的被注入对象和依赖对象之间的对应关系。

它需要寻求其他方式来记录诸多对象之间的对应关系。比如:

  • 它可以通过最基本的文本文件来记录被注入对象和其依赖对象之间的对应关系;
  • 它也可以通过描述性较强的XML文件格式来记录对应信息;
  • 它还可以通过编写代码的方式来注册这些对应信息;
  • 甚至,如果愿意,它也可以通过语音方式来记录对象间的依赖注入关系(“嗨,它要一个这种类型的对象,拿这个给它”)。

那么,实际情况下,各种具体的IoC Service Provider实现又是通过哪些方式来记录“服务信息”的呢?
归纳一下,当前流行的IoC Service Provider产品使用的注册对象管理信息的方式主要有以下几种。

直接编码方式

当前大部分的IoC容器都应该支持直接编码方式,比如PicoContainer、 Spring、 Avalon等。在容器启动之前,我们就可以通过程序编码的方式将被注入对象和依赖对象注册到容器中,并明确它们相互之间的依赖注入关系。

1
2
3
4
5
6
IoContainer container = ...;
container.register(FXNewsProvider.class,new FXNewsProvider());
container.register(IFXNewsListener.class,new DowJonesNewsListener());
...
FXNewsProvider newsProvider = (FXNewsProvider)container.get(FXNewsProvider.class);
newProvider.getAndPersistNews();

通过为相应的类指定对应的具体实例,可以告知IoC容器,当我们要这种类型的对象实例时,请将容器中注册的、对应的那个具体实例返回给我们。

如果是接口注入,可能伪代码看起来要多一些。不过,道理上是一样的,只不过除了注册相应对象,还要将“注入标志接口”与相应的依赖对象绑定一下,才能让容器最终知道是一个什么样的对应关系。

1
2
3
4
5
6
7
8
IoContainer container = ...;
container.register(FXNewsProvider.class,new FXNewsProvider());
container.register(IFXNewsListener.class,new DowJonesNewsListener());
...
container.bind(IFXNewsListenerCallable.class, container.get(IFXNewsListener.class));
...
FXNewsProvider newsProvider = (FXNewsProvider)container.get(FXNewsProvider.class);
newProvider.getAndPersistNews();

通过bind方法将“被注入对象”(由IFXNewsListenerCallable接口添加标志)所依赖的对象,绑定为容器中注册过的IFXNewsListener类型的对象实例。容器在返回FXNewsProvider对象实例之前,会根据这个绑定信息,将IFXNewsListener注册到容器中的对象实例注入到“被注入对象” FXNewsProvider中,并最终返回已经组装完毕的FXNewsProvider对象。

所以,通过程序编码让最终的IoC Service Provider(也就是各个IoC框架或者容器实现)得以知晓服务的“奥义”,应该是管理依赖绑定关系的最基本方式。

配置文件方式

这是一种较为普遍的依赖注入关系管理方式。像普通文本文件、 properties文件、 XML文件等,都可以成为管理依赖注入关系的载体。不过,最为常见的,还是通过XML文件来管理对象注册和对象间依赖关系,比如Spring IoC容器和在PicoContainer基础上扩展的NanoContainer,都是采用XML文件来管理和保存依赖注入信息的。对于例子中的FXNewsProvider来说,也可以通过Spring配置文件的方式来配置和管理各个对象间的依赖关系。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<bean id="newsProvider" class="..FXNewsProvider">
<property name="newsListener">
<ref bean="djNewsListener"/>
</property>
<property name="newPersistener">
<ref bean="djNewsPersister"/>
</property>
</bean>
<bean id="djNewsListener"
class="..impl.DowJonesNewsListener">
</bean>
<bean id="djNewsPersister"
class="..impl.DowJonesNewsPersister">
</bean>

从读取配置文件完成对象组装的容器中获取FXNewsProvider并使用。

1
2
3
4
...
container.readConfigurationFiles(...);
FXNewsProvider newsProvider = (FXNewsProvider)container.getBean("newsProvider");
newsProvider.getAndPersistNews();

元数据方式

这种方式的代表实现是Google Guice,这是Bob Lee在Java 5的注解和Generic的基础上开发的一套IoC框架。我们可以直接在类中使用元数据信息来标注各个对象之间的依赖关系,然后由Guice框架根据这些注解所提供的信息将这些对象组装后,交给客户端对象使用。

Guice是区别于Spring得依赖注入框架,具体使用方法可以在网上查找。

使用Guice的注解标注依赖关系后的FXNewsProvider定义。

1
2
3
4
5
6
7
8
9
10
11
12
public class FXNewsProvider
{
private IFXNewsListener newsListener;
private IFXNewsPersister newPersistener;
@Inject
public FXNewsProvider(IFXNewsListener listener,IFXNewsPersister persister)
{
this.newsListener = listener;
this.newPersistener = persister;
}
...
}

通过@Inject,我们指明需要IoC Service Provider通过构造方法注入方式,为FXNewsProvider注入。其所依赖的对象。至于余下的依赖相关信息,在Guice中是由相应的Module来提供的。

FXNewsProvider所使用的Module实现:

1
2
3
4
5
6
7
8
9
public class NewsBindingModule extends AbstractModule {
@Override
protected void configure() {
bind(IFXNewsListener.class)
.to(DowJonesNewsListener.class).in(Scopes.SINGLETON);
bind(IFXNewsPersister.class)
.to(DowJonesNewsPersister.class).in(Scopes.SINGLETON);
}
}

通过Module指定进一步的依赖注入相关信息之后,我们就可以直接从Guice那里取得最终已经注入完毕,并直接可用的对象了。

从Guice获取并使用最终绑定完成的FXNewsProvider。

1
2
3
Injector injector = Guice.createInjector(new NewsBindingModule());
FXNewsProvider newsProvider = injector.getInstance(FXNewsProvider.class);
newsProvider.getAndPersistNews();

当然, 注解最终也要通过代码处理来确定最终的注入关系,从这点儿来说,注解方式可以算作编码方式的一种特殊情况。

小结

本文就IoC场景中的主要角色IoC Service Provider给出了言简意赅的介绍。讨论了IoC Service Provider的基本职责,以及它常用的几种依赖关系管理方式。
应该说, IoC Service Provider只是为了简化概念而提出的一个一般性的概念。后面,我们将由一般到特殊,一起深入了解一个特定的IoC Service Provider实现产品,即Spring提供的IoC容器。

文章作者: 李浩
文章链接: https://leehoward.cn/2019/10/22/Spring揭秘-掌管大局的IoC Service Provider/
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 leehoward
打赏
  • 微信
  • 支付宝

评论