在ABP框架中提供了一套動態生成ApiController的機制（依然支持原生ApiController的使用方式），雖然說是動態生成ApiController但是實際上并沒有真正在啟動程序的時候生成任何ApiController類的子類，客戶端所有對動態控制器的訪問都集中到同一個泛型類DynamicApiController<T>上。真正用來區別不同服務的是其泛型T，這是一個繼承自IApplicationService的接口，用戶自定義的應用服務類繼承T接口并實現其中的方法。系統在啟動階段會自動注冊所有應用服務類。

　　實際上動態控制器之所以能工作就是依賴IApplicationService在程序開始階段已經被注冊到容器中。ABP框架中存在一個攔截器AbpDynamicApiControllerInterceptor<T>，在DynamicApiController<T>控制器類型上添加接口代理（IApplicationService的子類）也就是說對該控制器類型的任何應用服務方法的訪問都會被攔截，利用攔截器的構造函數public AbpDynamicApiControllerInterceptor(T proxiedObject)，將應用服務的真實類型解析進去，然后通過反射執行應用服務中的方法。比較漂亮的一點就是自定義的AbpApiControllerActionSelector和DynamicHttpActionDescriptor類，在Selector的SelectAction方法中會新建一個DynamicHttpActionDescriptor實例，并將IApplicationService子接口的方法MethodInfo傳遞進去，這樣就可以利用WebApi原生的參數綁定機制完成參數的獲取了。

　　在程序的開始階段調用DynamicApiControllerBuilder的泛型方法ForAll<T>(Assembly assembly, string servicePrefix)找到assembly中所有T的自定義子接口，根據子接口及其中定義的方法包裝成DynamicApiControllerInfo和DynamicApiMethodInfo存儲到DynamicApiControllerManager靜態類中字典字段中，以后需要獲取任意一個控制器的信息也是通過該靜態類根據Servic的名字來獲得的。

　　訪問的話就沒有多少好說的了，在DynamicApiControllerBuilder收集所有應用服務信息來生成DynamicApiControllerInfo的時候可以指定Prefix，以后所有希望調用IApplicationService的Request都需要有該前綴，至于服務的名稱默認是IApplicationService的子接口名（像“ApplicationService”，”AppService“等等幾個后綴還是需要去掉的，最前面“I”也是要刪掉的），當然后可以定義一個委托Func<Type, string> _serviceNameSelector，來自定義服務名，再就是在服務名的后面添加方法名來唯一定位到應用服務的Action。別忘了定義Route，系統默認定義了一個services為前綴的動態控制器的RouteTemplate。

轉載于:https://www.cnblogs.com/Azula/p/5320547.html

總結

以上是生活随笔為你收集整理的ABP框架详解（八）动态ApiController的生成和访问机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。