通常来讲，一个现代化的网站加载流程是这样的：程序集加载后，咱们会初始化 IOC 容器，以便于接下来解析对象用。html
咱们插件式的开发，这一步更为重要。这是由于在开发阶段，这些程序集以及 IOC 配置都是分属于多个解决方案的，在部署前极可能尚未连调。如何在集成在一块儿后，保证起码的可用性，是很关键的一个步骤。研究稍微深一点的同窗，应该很清楚 WebApi 框架自己就集成了一个 IOC 框架用于对象的生成。咱们要作的工做就是在此基础上扩展，把咱们要额外注入的东西添加进去。web
IOC 容器选型：Unity
选用 Unity 无可厚非，公司一直在用而且也没什么想换的意思。在第一篇文章里，@elder 说 MEF 不错，可是大环境下，确实没见过有人在用。包括微软自家的 MVC 和 WebApi，基本思想都是实现 CommonServiceLocation。若是有企业级的应用在使用 MEF，不妨经过私信告诉我。我也想看看这个集成在 .Net 4 中的微软亲儿子，究竟是骡子仍是马。编程
无论怎么说，多一种选择老是没错的。至于其它的 IOC 框架，从对 CommonServiceLocation 作适配上来看，基本上都是大同小异，只是获取类型注册的方式有所不一样而已。markdown
这里我选用现成的 Unity.WebApi 组件将 WebApi 自身的 IOC 容器扩展到 Unity 中（反编译后能够发现就两个类，直接把代码拷贝出来，贴到项目里也是能够的）。框架
容器注册项加载约定
对于一个 IOC 容器来讲，经过配置文件加载注册项都是不可或缺的。连 Ninject 这种奇葩，都有第三方对其扩展了配置文件支持。在编程中，我我的特别讨厌不想干的代码侵入，因此通常我会把 IOC 的注入写在配置文件中：一方面代码干净了，另外一方面，一个简单的配置修改，就能够不用从新编译代码了，这不就是 IOC 的本质吗？网站
配置文件能够屡次附加配置到一个 IOC 容器实例上很必要，这样我就能够连续把多个配置文件的注册项添加到一个实例上。事实上，IOC 容器的实例，全局有且只有一个的时候才有用。回到我们的 Unity 上面，很不幸的是，Unity 支持这个要求，呵呵。url
额外的，为了项目总体上一致，我为 Unity 的配置文件约定：spa
- Unity 配置文件名称为
unity.config。 - 存放路径为：相对当前程序集所在目录的
Configuration\unity.config，这样只须要调整生成时老是复制就能够了。
注：这里若是你想灵活一些，能够在上一节的配置文件中添加你的 Unity 配置文件路径设置信息。插件
部分源代码：天然语义
额外的，在 Global 中须要用 Unity.WebApi 把扩展点挂接上。下面是 IOC 加载各个模块配置的事情代码：3d
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 加载后，这个错误仍将继续存在，且一直存在。
全部正确的作法是：程序集加载能够无序进行，可是必定要加载所有程序集后，再进行后续操做。