在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。
