Web API 依赖注入与扩展

依赖注入

与 MVC 类似， Web API 提供了System.Web.Http.Services.IDependencyResolver 接口来实现依赖注入， 我们可以很容易的用 Unity 来实现这个接口：

使用 UnityDependencyResolver 的方法也很简单， 只要在 Global.asax.cs 里添加下面一行代码即可：

将 UnityDependencyResolver 配置好之后， Web API 框架将会在运行时向其请求一系列的接口实现：

1. 应用启动时， Web API 框架会依次请求下列接口：
   1. System.Web.Http.Dispatcher.IHttpControllerFactory
   2. System.Web.Http.Common.ILogger
   3. System.Web.Http.Dispatcher.IHttpControllerActivator
   4. System.Web.Http.Controllers.IHttpActionSelector
   5. System.Web.Http.Controllers.IHttpActionInvoker
2. 在第一次访问某个 Controller 之前， 还会请求下面的接口 （如果重复访问相同的 Controller ， 则不会再次调用）：
   1. System.Web.Http.Filters.IFilterProvider
3. 每次处理 HTTP 请求时， Web API 请求下列接口：
   1. System.Web.Http.Controllers.IActionValueBinder
   2. System.Web.Http.ValueProviders.ValueProviderFactory （仅 Action 需要参数时才需要）
   3. System.Web.Http.ModelBinding.ModelBinderProvider （仅 Action 需要参数时才需要）
   4. System.Web.Http.Metadata.ModelMetadataProvider （仅 Action 需要参数时才需要）
   5. System.Web.Http.Validation.ModelValidatorProvider （仅 Action 需要参数时才需要）
   6. System.Net.Http.Formatting.IFormatterSelector

这些接口都是 Web API 公开的扩展点， 可以根据需要来对这些接口进行实现， 并通过 Unity 进行配置， 让其注入到 Web API 运行时中。 接下来将逐个讨论这些扩展点。

扩展

IHttpControllerFactory

IHttpControllerFactory 接口有两个方法， 负责创建和销毁 HttpController 实例：

• CreateController(HttpControllerContext, Type) : IHttpController
• ReleaseController(IHttpController) : void

这个接口的默认实现是 DefaultHttpControllerFactory ， 根据当前请求的上下文通过创建 HttpControllerDescriptor ， 然后通过 HttpControllerDescriptor 的 ControllerActivator 创建对应的 IHttpController 实例。

ILogger

只是一个日志接口， 有下面的几个方法：

• Log(string, TraceLevel, Func) : void
• LogException(string, TraceLevel, Exception) : void

默认的实现是 DiagnosticLogger ， 通过 ILSpy 观察， 貌似什么都没有做。

IHttpControllerActivator

负责创建具体的 Controller 实例， 只有一个方法：

• Create(HttpControllerContext, Type) : IHttpController

默认的实现是 DefaultHttpControllerActivator ， 先向 DependencyResolver 请求对应 Controller 类型的实例， 如果返回为空， 则通过动态编译包装 Controller 类型构造函数的 lambda 表达式进行创建实例， 相关的代码如下：

IHttpActionSelector

负责选择合适的动作， 默认的实现是 ApiControllerSelector ， 选择规则如下：

1. 如果路由定义了 {action} ， 则通过当前的 HttpControllerContext 中的 action 的值寻找合适的方法；
2. 否则， 根据当前的 HTTP 请求方法 (POST, GET, PUT, DELETE) 寻找合适的方法。

IHttpActionInvoker

负责调用 HttpActionSelector 选择到的方法， 该接口有一个方法：

• InvokeActionAsync(HttpActionContext, CancellationToken) : Task<HttpResponseMessage>

默认的实现是 ApiControllerActionInvoker ， 通过反射找出动作方法的参数信息， 然后再通过动态创建 lambda 表达式对方法进行调用， 取得返回结果， 部分代码如下：

取得返回结果之后， 再调用 ApiResponseConverter 的 GetResponseConverter 方法找到合适的 Converter ， 最后返回 Task<HttpResponseMessage>

IFilterProvider

负责提供过滤的标记， Web API 框架内置了下面的几个 FilterProvider ：

• EnumerableEvaluatorFilterProvider 负责提供对 IENumerable 的每个元素的转换的标记， 简单的说， 就是负责提供将 Action 方法返回的 IEnumerable 的结果进行自定义转换的标记；
• QueryCompositionFilterProvider 负责对 Action 方法返回的 IQueryable 的结果进行符合 OData 约定的 URL 参数进行再次过滤的标记 QueryCompositionFilterAttribute ， 目前只支持 $filter 、$orderby 、 $skip 以及$top ；
• ActionDescriptorFilterProvider
• ConfigurationFilterProvider

注意， 这里说的是 FilterProvider， 不是 Filter ， 也不是 FilterAttribute 。

IActionValueBinder

负责绑定 Action 方法的参数， 默认的实现是 DefaultActionValuebinder ， 通过调用 ValueProviderFactory 、 ModelBinderProvider 进行参数绑定， 支持多种形式的参数绑定， 绑定策略比较复杂， 总的来说是简单的参数从 URL 中绑定， 复杂参数从 HTTP 请求内容中获取。

ValueProviderFactory

定义了 Action 参数从哪里获取， 有以下几个实现， 分别支持从 URI 、 QueryString、 Post 内容中提取参数值：

• CompositeValueProviderFactory
• KeyValueModelProviderFactory
• RouteDataValueProviderFactory
• QueryStringValueProviderFactory

ModelBinderProvider

定义了如何将获取到的 HTTP 请求的的参数之绑定到指定的参数。 System.Web.Http.ModelBinding.Binders 命名空间内提供了多种 BinderProvider ， 应该可以处理大多数常见的类型。

ModelMetadataProvider

负责提供模型元数据描述信息。

ModelValidatorProvider

负责根据元素据信息对模型进行验证。

IFormatterSelector

负责选择合适的格式， 包括客户端请求的格式以及服务端返回的格式， 默认实现是 FormatterSelector ， 能够提下面的 MediaFormater ：

• BufferedmediaTypeFormatter 提供对二进制格式的读取与写入；
• FormUrlEncodedMediaTypeFormatter 提供对表单 URL 编码格式的读取与写入；
• JsonMediaTypeFormatter 提供对 Json 格式的读取与写入；
• XmlMediaFormatter 提供对 XML 格式的读取与写入。