Fork me on GitHub

ABP源码分析三十五:ABP中动态WebAPI原理解析

动态WebAPI应该算是ABP中最Magic的功能之一了吧。开发人员无须定义继承自ApiController的类,只须重用Application Service中的类就可以对外提供WebAPI的功能,这应该算是对DRY的最佳诠释了. 如下图所示,一行代码就为所有实现了IApplicationService的类型,自动创建对应的动态WebAPI.

这么Magic的功能是如何实现的呢?

本文为你揭开其Magic的外表。你会发现,实现如此Magic的功能,最关键的代码只有四行。

 


先思考一个问题:如果不从ASP.NET WebApi 的ApiController继承,我们能实现ASP.NET WebAPi吗?

答案:不可以. 从APIController继承来实现我们自己的HttpController是实现ASP.NET WebApi的前提。

那么问题又来了。我们在使用ABP框架的时候,没有创建任何从APIController继承的类。那么从APIController继承的类在哪里?和ApplicationService中的类又有怎样的关系?

先给出答案:ABP框架自动给ApplicationService中的类创建了“HttpController”,他们从APIController继承。

 

基于上面的分析,要实现WebApi有三个问题需要解决:如何定义HttpController?路由的规则如何设置?如何激活和调用HttpController中的Action?接下来逐一解答。


 

如何定义HttpController?

ABP中ApplicationService并不是从APIController继承,或实现IHttpController接口。为解决HttpController类型缺失的问题,ABP首先为所有的ApplicationService动态的创建一个DynamicApiController<T> ,这个类继承自AbpApiController,其中T是接口继承自IApplicationService。

但是DynamicApiController<T> 是一个空的类,其没有任何Action. 这样的HttpController类显然无用的。那么如何给这些动态生成的DynamicApiController<T>对象根据T(ApplicationService接口)中对应的方法添加相对应的Action?

看似复杂的问题,ABP以一种巧妙的办法解决了,关键就在AbpWebApiModule中的4行代码(下面59-62行)。这里简单解释一下ABP的做法:

1. 通过Castle创建DynamicApiController<T>的代理类,

2. 为代理类动态添加ApplicationService接口(这里就是指T,也就是让代理类实现了接口T,这样通过代理类就可以访问接口T中定义的方法),

3. 同时为代理类添加拦截器。

这样当ABP通过Castle获取DynamicApiController<T>实例的时候,其实得到的是DynamicApiController<T>的代理类(关键)。 通过DynamicApiController<T>的代理类调用ApplicationService的接口中的定义的方法的时候(必须通过反射的方式调用,因为接口T中的方法对DynamicApiController<T>实例是不可见的。但实际上是可见的,因为你得到的是从T接口继承的DynamicApiController<T>的代理类实例,而不是DynamicApiController<T>实例本身。),会被拦截器拦截。而拦截器则调用真正的ApplicationService对象来执行方法(这里也很关键,因为代理类中只要方法的声明,没有实现。所以这里需要拦截器将其方法调用拦截并路由到真正的ApplicationService对象上)。对这四行代码不理解的话可先阅读下文:http://www.cnblogs.com/1zhk/p/5399548.html

举个例子:

假设有一个ApplicationService的接口是IFooAppication.

第59行,DynamicApiController<IFooAppication>被register到Castle容器中。

第60行,为DynamicApiController<IFooAppication>创建proxy代理,并为该代理添加接口IFooAppication。

第61行,为proxy代理添加拦截器AbpDynamicApiControllerInterceptor<IFooAppication>


 

路由的规则如何设置?

通过AbpWebApiModule的InitializeRoutes方法硬编码在Abp.Web.Api的代码中。很明显这里路由使用了*通配符,也就是所有api/services/XXXX的请求都是有效的,都会进入WebApi的消息管道。

 

 

如何根据routedata激活和调用具体生成的DynamicApiController<T>对象?

ABP通过AbpWebApiModule的InitializeAspNetServices方法使用自定义的对象替换了默认的IhttpControllerSelector对象,IHttpActionSelector对象,IHttpControllerActivatore对象。如果了解ASP.Net WebApi底层工作原理的开发人员一定对这三个接口应该很熟悉。如果不了解的同学要先做做功课,才能明白后文的内容。

至此,大概解释了ABP的动态WebApi的工作原理。


以下是对与动态WebAPI相关的接口和对象逐一分析。这些接口和类都围绕着两个中心目标:为动态Controller创建可供ASP.NET WebApi使用的描述器和选择器(Descriptor,Selector),以及构建和保存动态Controller的类型信息。

首先看看ApiController和Configuration

AbpApiController:继承了MVC的ApiController,ABP 中的WebApi Controller直接或间接的都从AbpApiController继承。第二张图,显示了AbpApiController引用了哪些ABP核心类库中的功能模块的对象。

IDynamicApiController:空接口,用于标识其实现是一个动态生成的ApiController。

DynamicApiController<T>:用作所有动态生成的ApiController的基类。

 

IAbpWebApiModuleConfiguration/AbpWebApiModuleConfiguration : 封装了HttpConfiguration属性,初始化为GlobalConfiguration.Configuration对象。 因为ASP.NET Web API在Web Host下通过ASP.Net的静态类型GlobalConfiguration的Configuration属性获取到的用于配置请求处理管道的HttpConfiguration对象。ABP的动态WebApi本质上仍是ASP.NET Web API,所以这样配置HttpConfiguration是必然的。

 


与Controller激活和调用相关的接口和类主要有下面这些。其实都是继承自ASP.NET WebAPi中默认的使用的对象,并重载了一些方法以支持动态APiController的发现,激活和调用。

 

DynamicHttpControllerDescriptor : 继承自asp.net Webapi系统的HttpControllerDescriptor,与ASP.NET WebAPI 中默认的HttpControllerDescriptor相比,其多了一个IFilter[]数组。这样做的原因很简单,因为ABP中的ApiController是动态生成的,是没有标注Filter特性的。所以ABP通过下面这种方式给动态ApiController加上Filter。

 

DynamicHttpActionDescriptor : 继承自asp.net Webapi系统的ReflectedHttpActionDescriptor,与ASP.NET WebAPI 中默认的HttpActionDescriptor相比,其多了一个IFilter[]数组。这样做的原因和上面一致

 

AbpHttpControllerSelector : 继承自asp.net Webapi系统的DefaultHttpControllerSelector。通过重写SelectController来返回HttpControllerDescriptor, 这是ABP能动态创建APIController的关键。ASP.Net  WebAPI 中的IHttpControllerSelector对象负责根据HttpRouteData返回HttpControllerDescriptor。HttpControllerDescriptor中封装了controller的类型等信息。这里ABP通过继承DefaultHttpControllerSelector,并重写SelectController方法来根据HttpRouteData中的数据创建HttpControllerDescriptor对象并返回

 

 

AbpApiControllerActivator:实现了IHttpControllerActivator接口,根据controllerType生成具体的controller. 由于ABP系统使用了Castle框架来管理对象。所以有必要实现自己的IHttpControllerActivator以替换ASP.Net系统默认的实现。

 

AbpApiControllerActionSelector : 继承自ASP.Net WebAPI 的 ApiControllerActionSelector。 通过重写SelectAction来返回HttpActionDescriptor的派生类DynamicHttpActionDescriptor的实例, 这是ABP能执行动态创建的APIController的Action方法的关键。AbpApiControllerActionSelector 通过调用DynamicApiServiceNameHelper的静态方法(传入routedata中的serviceNameWithAction)获取action的那么

DynamicApiServiceNameHelper:静态类,提供四个静态方法。两个方法用于校验servicename是否合规,还有两个方法用于servicename中获取service和action的name。

 

AbpDynamicApiControllerInterceptor<T> : 实现了Castle的IInterceptor。作为动态生成的DynamicApiController<T>的拦截器,它拦截所有对action的调用,然后通过反射调用底层真实的IApplicationService对象的方法。

 


在传统的asp.net webapi应用中,系统会根据路由信息,通过反射到程序集中去匹配对应的controller的类型信息。而在ABP中,controller的类型信息是初始化的时候直接添加到一个Dictionary集合中的。本文第一幅图中的代码干的就是这件事。完成这个功能模块所涉及的接口和类主要有以下这些。

 

上图代码中所示,构建DynamicHttpControllerDescriptor 的数据来源于一个DynamicApiControllerInfo对象。那么DynamicApiControllerInfo对象又是在什么时候怎么构建的呢?下图是ABP关于构建applicationService的DynamicApiControllerInfo对象所涉及的类型和接口。

 

DynamicApiControllerInfo:ABP用于封装ApiController的信息,下图显示了其所有的属性。其中最关键的属性就是ApiControllerType.其实就是一个DynamicApiController<T>类型,其中的T就是具体的ApplicationService接口的类型。

 

 

DynamicApiActionInfo:用于封装动态生成的ApiController的Action的信息:actionName,Filters, methondinfo和httpVerb。DynamicApiControllerInfo封装了一个DynamicApiActionInfo的字典对象,用以表示这个Controller可支持的Action列表。

 

 

DynamicApiControllerManager:提供了一个Dictionary容器管理所有的DynamicApiControllerInfo对象。共有三个方法:Register方法用于将DynamicApiControllerInfo添加到Dictionary容器中,另外两个方法用于返回DynamicApiControllerInfo。

 

DynamicApiControllerBuilder:提供两个方法,一个For<T>方法通过ApiControllerBuilder为某一个application service类创建DynamicApiControllerInfo。另一个ForAll<T>方法通过BatchApiControllerBuilder为某一类application service类(这一类application service会有个共同的接口)创建DynamicApiControllerInfo。

 

IApiControllerBuilder<T>/ApiControllerBuilder<T>:其内部封装了一个字典对象IDictionary<string, ApiControllerActionBuilder<T>>用于存放T的每个方法对应的ApiControllerActionBuilder对象。最后通过调用Build()方法生成完整的DynamicApiControllerInfo对象。这里注意观察IApiControllerBuilder的代码,他是支持链式编程的,可以通过WithFilters的方法给这个Application Service的API controller添加filter

 

 

IBatchApiControllerBuilder<T>/BatchApiControllerBuilder<T> : 为assembly中符合命名规范的接口批量生成DynamicApiControllerInfo。其最后仍然是通过ApiControllerBuilder逐个为各个application service接口创建DynamicApiControllerInfo.

 

 

 

如下图,ApiControllerBuilder在构建DynamicApiControllerInfo过程中,需要调用ApiControllerActionBuilder对象去构建该DynamicApiControllerInfo所包含的DynamicApiActionInfo

 

 

 

DynamicApiControllerActionHelper:静态类,用于获取一个type的所有方法(property除外,object的原生方法除外,ApplicationService除外)的列表。

 

 

 

DynamicApiVerbHelper:根据方法名按照约定返回httpVerb。

 

 

IApiControllerActionBuilder/ApiControllerActionBuilder:用于构建DynamicApiActionInfo对象的生成器。这里有一个注意点:如上图,如果action的methodName是以get开头的,默认ABP会标注其httpVerb为Get, 但是有一个例外,如果方法的参数不为primitive 类型和不可为空类型时,ABP会标注其httpVerb为Post。


 

AbiApiExplorer:继承自ApiExplorer类,实现了IApiExplorer接口。其ApiDescriptions属性既包括你自己编写的webApi (39-44行)又包括ABP动态生成的WebApi(47 -)。

ABP通过遍历DynamicApiControllerManager中的DynamicControllerInfo,然后在遍历DynamicControllerInfo的DynamicApiActionInfo,为他们逐个构建ApiDescription实例。

 

 返回ABP源码分析系列文章目录

posted @ 2016-04-23 07:58 ZHK的博客 阅读(...) 评论(...) 编辑 收藏