Composite Application Guidance for WPF（5）——依赖注入容器

Composite Application Guidance for WPF（5）——依赖注入容器2012-02-07 博客园周银辉依赖注入容器和Prism的基础服务已经在本系列随笔中提到过很多次,今天将其分离出来专门说一说

1, 为什么要使用依赖注入容器

我们知道, 在Composite Application中各个模块之间是松耦合的关系, 也就是在设计的时候尽可能地减少模块间的依赖, 但无论如何从业务角度讲, 他们之间总还是要相互通信与合作的. 所以依赖注入容器在这其中扮演了一个桥梁般的角色. 比如当创建某一个组件实例的时候, 其依赖于另外的一个组件或服务, 此时依赖注入容器会将其需要的信息"注入（Injection）"进去, 采用注入的方式就避免了直接引用之间的耦合.除此之外, 使用依赖注入容器还有以下几方面的好处:

组件（Component）不必自己去定位其依赖项和维护依赖项的生命周期

替换组件的依赖项的具体实现时不会影响到组件代码

由于依赖项比较容易Mock,所以组件变得更易测

由于系统所需要的新的服务很容易被添加到容器中,系统维护难度也降低了

2, Prism的依赖注入容器

打开Composite Application Library（CAL）的源代码, 我们似乎没有找到一个依赖注入容器的实现,而是找到了一个依赖注入容器外观接口IContainerFacade,其利用了外观模式来高层抽象了一个依赖注入容器的最最基本的功能"解析"（Resolve）.

  /// <summary>  /// 定义一个简单的,被 Composite Application Library所使用的依赖注入容器外观.  /// </summary>  public interface IContainerFacade  {    /// <summary>    /// 从容器中解析出指定类型的实例    /// </summary>    /// <param name="type">从容器中获取的对象的类型.</param>    /// <returns>一个 <paramref name="type"/>类型的实例.</returns>    object Resolve（Type type）;      /// <summary>    /// 尝试着从容器中解析出指定类型的实例    /// </summary>    /// <param name="type">从容器中获取的对象的类型.</param>    /// <returns>    /// 一个 <paramref name="type"/>类型的实例.    /// 如果类型不能被解析则返回<see langword="null" /> 值.    /// </returns>    object TryResolve（Type type）;  }