WebApi 插件式构建方案：IOC 容器初始化

一般来说，一个现代化的网站加载流程是这样的：程序集加载后，我们会初始化 IOC 容器，以便于接下来解析对象用。

我们插件式的开发，这一步更为重要。这是因为在开发阶段，这些程序集以及 IOC 配置都是分属于多个解决方案的，在部署前很可能还没有连调。如何在集成在一起后，保证起码的可用性，是很关键的一个步骤。研究稍微深一点的同学，应该很清楚 WebApi 框架本身就集成了一个 IOC 框架用于对象的生成。我们要做的工作就是在此基础上扩展，把我们要额外注入的东西添加进去。

IOC 容器选型：Unity

选用 Unity 无可厚非，公司一直在用并且也没什么想换的意思。在第一篇文章里，@elder 说 MEF 不错，但是大环境下，确实没见过有人在用。包括微软自家的 MVC 和 WebApi，基本思想都是实现 CommonServiceLocation。如果有企业级的应用在使用 MEF，不妨通过私信告诉我。我也想看看这个集成在 .Net 4 中的微软亲儿子，到底是骡子还是马。

不管怎么说，多一种选择总是没错的。至于其它的 IOC 框架，从对 CommonServiceLocation 做适配上来看，基本上都是大同小异，只是获取类型注册的方式有所不同而已。

这里我选用现成的 Unity.WebApi 组件将 WebApi 自身的 IOC 容器扩展到 Unity 中（反编译后可以发现就两个类，直接把代码拷贝出来，贴到项目里也是可以的）。

容器注册项加载约定

对于一个 IOC 容器来说，通过配置文件加载注册项都是不可或缺的。连 Ninject 这种奇葩，都有第三方对其扩展了配置文件支持。在编程中，我个人特别讨厌不想干的代码侵入，所以一般我会把 IOC 的注入写在配置文件中：一方面代码干净了，另一方面，一个简单的配置修改，就可以不用重新编译代码了，这不就是 IOC 的本质吗？

配置文件可以多次附加配置到一个 IOC 容器实例上很必要，这样我就可以连续把多个配置文件的注册项添加到一个实例上。事实上，IOC 容器的实例，全局有且只有一个的时候才有用。回到咱们的 Unity 上面，很不幸的是，Unity 支持这个要求，呵呵。

额外的，为了项目整体上一致，我为 Unity 的配置文件约定：

• Unity 配置文件名称为 unity.config。
• 存放路径为：相对当前程序集所在目录的 Configuration\unity.config，这样只需要调整生成时总是复制就可以了。

注：这里如果你想灵活一些，可以在上一节的配置文件中添加你的 Unity 配置文件路径设置信息。

部分源代码：自然语义

额外的，在 Global 中需要用 Unity.WebApi 把扩展点挂接上。下面是 IOC 加载各个模块配置的事情代码：

public interface IContainerConfiguration
{
  object Config(object container);
}

public class DefaultContainerConfiguration : IContainerConfiguration
{
    public object Config(object container)
    {
        var data = new List<string>();

        data.Add(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Configuration\\unity.config"));

        foreach(var item in DynamicModule.Instance.Modules)
        {
            data.Add(Path.Combine(item.BaseDirectory, "Configuration\\unity.config"));
        }
    }
}

补充：程序集加载

上一节写完以后，有人私信问我加载顺序的问题。在这里补充一下，程序集的加载和顺序是无关的：我可以先加载接口的实现程序集，再加载接口程序集。但是还有一些需要注意的地方：

• 程序集加载时，首先加载的程序集 B 如果引用了后续加载的程序集 A，加载不会产生错误。
• 后续被引用的程序集 A 被加载后，先前加载的程序集 B 中的类型就可以正常访问了。
• 在后续程序集 A 加载之前，如果有使用 B 中的程序集，就会提示出错；后续程序集 A 加载后，这个错误仍将继续存在，且一直存在。

所有正确的做法是：程序集加载可以无序进行，但是一定要加载全部程序集后，再进行后续操作。