1.背景
当我们在写webapi的时候我们发现，框架自动帮我们写好了 app.MapControllers(),看注释写的是帮我们将controllerl里面的action映射为我们的终结点，那具体是怎么弄得呢，我觉得可以仔细研究一下，看一下背后的逻辑.
2.开始研究，用dnspy看一下源码
public static ControllerActionEndpointConventionBuilder MapControllers(this IEndpointRouteBuilder endpoints)
{
//确保依赖的服务已经注册 可以进去看看帮我们注入了哪些东西，后面的代码可以看到它们身影
ControllerEndpointRouteBuilderExtensions.EnsureControllerServices(endpoints);
return ControllerEndpointRouteBuilderExtensions.GetOrCreateDataSource(endpoints).DefaultBuilder;
}
//接上面,创建endpoint数据源
private static ControllerActionEndpointDataSource GetOrCreateDataSource(IEndpointRouteBuilder endpoints)
{
ControllerActionEndpointDataSource controllerActionEndpointDataSource = endpoints.DataSources.OfType<ControllerActionEndpointDataSource>().FirstOrDefault<ControllerActionEndpointDataSource>();
if (controllerActionEndpointDataSource == null)
{
//相关服务
OrderedEndpointsSequenceProviderCache requiredService = endpoints.ServiceProvider.GetRequiredService<OrderedEndpointsSequenceProviderCache>();
//获取数据源
controllerActionEndpointDataSource = endpoints.ServiceProvider.GetRequiredService<ControllerActionEndpointDataSourceFactory>().Create(requiredService.GetOrCreateOrderedEndpointsSequenceProvider(endpoints));
endpoints.DataSources.Add(controllerActionEndpointDataSource);
}
return controllerActionEndpointDataSource;
}
重点就是 ControllerActionEndpointDataSourceFactory.Create() 函数帮我们构建数据源。
controllerActionEndpointDataSourceFactory
internal class ControllerActionEndpointDataSourceFactory
{
private readonly ControllerActionEndpointDataSourceIdProvider _dataSourceIdProvider;
private readonly IActionDescriptorCollectionProvider _actions;
private readonly ActionEndpointFactory _factory;
public ControllerActionEndpointDataSourceFactory(
ControllerActionEndpointDataSourceIdProvider dataSourceIdProvider,
//这个很重要，为我们提供controller action的信息,具体实现类应该是
//ActionDescriptorCollectionProvider
IActionDescriptorCollectionProvider actions,
ActionEndpointFactory factory)
{
_dataSourceIdProvider = dataSourceIdProvider;
_actions = actions;
_factory = factory;
}
public ControllerActionEndpointDataSource Create(OrderedEndpointsSequenceProvider orderProvider)
{
//直接new一个 datasource
return new ControllerActionEndpointDataSource(_dataSourceIdProvider, _actions, _factory, orderProvider);
}
}
终于看到我们的datascource了，所以进去自己看看，如果构建的endpoint.以及最终实现的类是哪个。直接点进去类，可以看到类的构造函数（没贴出来）,实际上当我们第一次启动应用的时候，endpoint是没有构建出来的，直到第一次访问，才会进行初始化. 可以看到调用链 Initialize() =>UpdateEndpoints()=>CreateEndpoints()
internal abstract class ActionEndpointDataSourceBase : EndpointDataSource, IDisposable
{
//获取endpoints
public override IReadOnlyList<Endpoint> Endpoints
{
get
{
Initialize();
return _endpoints;
}
}
private void Initialize()
{
if (_endpoints == null)
{
lock (Lock)
{
if (_endpoints == null)
{
UpdateEndpoints();
}
}
}
}
private void UpdateEndpoints()
{
lock (Lock)
{
var endpoints = CreateEndpoints(_actions.ActionDescriptors.Items, Conventions);
// See comments in DefaultActionDescriptorCollectionProvider. These steps are done
// in a specific order to ensure callers always see a consistent state.
// Step 1 - capture old token
var oldCancellationTokenSource = _cancellationTokenSource;
// Step 2 - update endpoints
_endpoints = endpoints;
// Step 3 - create new change token
_cancellationTokenSource = new CancellationTokenSource();
_changeToken = new CancellationChangeToken(_cancellationTokenSource.Token);
// Step 4 - trigger old token
oldCancellationTokenSource?.Cancel();
}
}
}
internal class ControllerActionEndpointDataSource:ActionEndpointDataSourceBase
{
protected override List<Endpoint> CreateEndpoints(IReadOnlyList<ActionDescriptor> actions, IReadOnlyList<Action<EndpointBuilder>> conventions)
{
var endpoints = new List<Endpoint>();
var keys = new HashSet<string>(StringComparer.OrdinalIgnoreCase);
// MVC guarantees that when two of it's endpoints have the same route name they are //equivalent.
// However, Endpoint Routing requires Endpoint Names to be unique.
var routeNames = new HashSet<string>(StringComparer.OrdinalIgnoreCase);
// For each controller action - add the relevant endpoints.
// 1. If the action is attribute routed, we use that information verbatim
// 2. If the action is conventional routed
// a. Create a *matching only* endpoint for each action X route (if possible)
// b. Ignore link generation for now
for (var i = 0; i < actions.Count; i++)
{
if (actions[i] is ControllerActionDescriptor action)
{
//逻辑重点，为每个action构建一个endpoint.
_endpointFactory.AddEndpoints(endpoints, routeNames, action, _routes, conventions, CreateInertEndpoints);
if (_routes.Count > 0)
{
// If we have conventional routes, keep track of the keys so we can create
// the link generation routes later.
foreach (var kvp in action.RouteValues)
{
keys.Add(kvp.Key);
}
}
}
}
// Now create a *link generation only* endpoint for each route. This gives us a very
// compatible experience to previous versions.
for (var i = 0; i < _routes.Count; i++)
{
var route = _routes[i];
_endpointFactory.AddConventionalLinkGenerationRoute(endpoints, routeNames, keys, route, conventions);
}
return endpoints;
}
}
可以看到我们针对于每个action构建一个endpoint，AddEndpoints()所以继续进去看看逻辑。
public void AddEndpoints( List<Endpoint> endpoints, HashSet<string> routeNames,ActionDescriptor action,IReadOnlyList<ConventionalRouteEntry> routes,IReadOnlyList<Action<EndpointBuilder>> conventions, bool createInertEndpoints)
{
//不走的逻辑 代码被我省略删除 路由模板不为空。
if (action.AttributeRouteInfo?.Template != null){
//构建出来处理去请求的委托.很重要
var requestDelegate = CreateRequestDelegate(action) ?? _requestDelegate;
//属性路由模板
var attributeRoutePattern = RoutePatternFactory.Parse(action.AttributeRouteInfo.Template);
// Modify the route and required values to ensure required values can be successfully subsituted.
// Subsitituting required values into an attribute route pattern should always succeed.
var (resolvedRoutePattern, resolvedRouteValues) = ResolveDefaultsAndRequiredValues(action, attributeRoutePattern);
var updatedRoutePattern = _routePatternTransformer.SubstituteRequiredValues(resolvedRoutePattern, resolvedRouteValues);
//省略不重要代码
var builder = new RouteEndpointBuilder(requestDelegate, updatedRoutePattern, action.AttributeRouteInfo.Order)
{
DisplayName = action.DisplayName,
};//添加action data到builder
AddActionDataToBuilder(
builder,
routeNames,
action,
action.AttributeRouteInfo.Name,
dataTokens: null,
action.AttributeRouteInfo.SuppressLinkGeneration,
action.AttributeRouteInfo.SuppressPathMatching,
conventions,
perRouteConventions: Array.Empty<Action<EndpointBuilder>>());
endpoints.Add(builder.Build());
}
}
CreateRequestDelegate可以看到构建处理器的逻辑，我们进去看看，由于是ioc注入的容器所以我们需要找到实现类。实现类是 ControllerRequestDelegateFactory类
ControllerRequestDelegateFactory
private RequestDelegate? CreateRequestDelegate(ActionDescriptor action, RouteValueDictionary? dataTokens = null)
{
foreach (var factory in _requestDelegateFactories)
{ //看来我们可以注入我们的处理器逻辑，需要注明一下顺序(或者是我记得后来注入的在最前面？)
var requestDelegate = factory.CreateRequestDelegate(action, dataTokens);
if (requestDelegate != null)
{
return requestDelegate;
}
}
return null;
}
// ControllerRequestDelegateFactory方法
public RequestDelegate? CreateRequestDelegate(ActionDescriptor actionDescriptor, RouteValueDictionary? dataTokens)
{ //省略不重要代码
//针对于 context的委托.非常完美
return context =>
{
RouteData routeData;
if (dataTokens is null or { Count: 0 })
{
routeData = new RouteData(context.Request.RouteValues);
}
else
{
routeData = new RouteData();
routeData.PushState(router: null, context.Request.RouteValues, dataTokens);
}
var actionContext = new ActionContext(context, routeData, actionDescriptor);
var controllerContext = new ControllerContext(actionContext)
{
// PERF: These are rarely going to be changed, so let's go copy-on-write.
ValueProviderFactories = new CopyOnWriteList<IValueProviderFactory> (_valueProviderFactories)
};
controllerContext.ModelState.MaxAllowedErrors = _maxModelValidationErrors;
//实际上这点很重要，这里是帮助我们构建controller类的，因为控制器类没有注入ioc容器
var (cacheEntry, filters) = _controllerActionInvokerCache.GetCachedResult(controllerContext);
//很重要的一个东西，直接把我们引入到mvc的世界中,各种filter逻辑都在这
var invoker = new ControllerActionInvoker(
_logger,
_diagnosticListener,
_actionContextAccessor,
_mapper,
controllerContext,
cacheEntry,
filters);
return invoker.InvokeAsync();
};
}
看了半天找到了构建controller类的逻辑，那我们进去看看，既然没有注入到ioc，那么是如何构建的呢.进去getcacheResult中看看。
Controller类的生成逻辑
public (ControllerActionInvokerCacheEntry cacheEntry, IFilterMetadata[] filters) GetCachedResult(ControllerContext controllerContext)
{
var actionDescriptor = controllerContext.ActionDescriptor;
// We don't care about thread safety here
if (cacheEntry is null)
{
//省略 部分代码
//这个是重点，实际上是一个委托，为我们生成controller,下面有代码
var controllerFactory =_controllerFactoryProvider.CreateControllerFactory(actionDescriptor);
var controllerReleaser = _controllerFactoryProvider.CreateAsyncControllerReleaser(actionDescriptor);
// 省略 部分代码
cacheEntry = new ControllerActionInvokerCacheEntry(
filterFactoryResult.CacheableFilters,
controllerFactory,
controllerReleaser,
propertyBinderFactory,
objectMethodExecutor,
actionMethodExecutor);
actionDescriptor.CacheEntry = cacheEntry;
}
// 省略 ......
return (cacheEntry, filters);
}
逻辑是一个provider构建委托生成的,注入的实现类是 ControllerFactoryProvider 看看逻辑
ControllerFactoryProvider
public Func<ControllerContext, object> CreateControllerFactory(ControllerActionDescriptor descriptor)
{
//省略 代码
var controllerType = descriptor.ControllerTypeInfo?.AsType();
if (_factoryCreateController != null)
{ //第一种逻辑
return _factoryCreateController;
}
var controllerActivator = _activatorProvider.CreateActivator(descriptor);
var propertyActivators = GetPropertiesToActivate(descriptor);
//第二种逻辑
object CreateController(ControllerContext controllerContext)
{
var controller = controllerActivator(controllerContext);
for (var i = 0; i < propertyActivators.Length; i++)
{
var propertyActivator = propertyActivators[i];
propertyActivator(controllerContext, controller);
}
return controller;
}
return CreateController;
}
返回生成controller类的委托有两种逻辑 ，实际上我们走的是第一种 即 _factoryCreateController ，它在构造的时候被初始化为 _factoryCreateController = controllerFactory.CreateController;controllerFactory类又是哪个类呢，实际上是我们注入的DefaultControllerFactory 类，很熟悉把，因为以前的版本也是这么做的
DefaultControllerFactory
public object CreateController(ControllerContext context)
{
//重点代码
var controller = _controllerActivator.Create(context);
foreach (var propertyActivator in _propertyActivators)
{
propertyActivator.Activate(context, controller);
}
return controller;
}
根据你的一个controllercontext生成我们的控制类，_controllerActivator的实现类实际上我们注入的是 DefaultControllerActivator，进去具体看看
DefaultControllerActivator
public object Create(ControllerContext controllerContext)
{
//核心代码 删除了一些代码
var controllerTypeInfo = controllerContext.ActionDescriptor.ControllerTypeInfo;
var serviceProvider = controllerContext.HttpContext.RequestServices;
return _typeActivatorCache.CreateInstance<object>(serviceProvider, controllerTypeInfo.AsType());
}
引出了新的类 _typeActivatorCache ，这个类的注入实际上是 TypeActivatorCache
TypeActivatorCache
internal class TypeActivatorCache : ITypeActivatorCache
{
private readonly Func<Type, ObjectFactory> _createFactory =
(type) => ActivatorUtilities.CreateFactory(type, Type.EmptyTypes);
private readonly ConcurrentDictionary<Type, ObjectFactory> _typeActivatorCache =
new ConcurrentDictionary<Type, ObjectFactory>();
/// <inheritdoc/>
public TInstance CreateInstance<TInstance>(
IServiceProvider serviceProvider,
Type implementationType)
{
//核心代码 其他代码删除
var createFactory = _typeActivatorCache.GetOrAdd(implementationType, _createFactory);
return (TInstance)createFactory(serviceProvider, arguments: null);
}
}
那么生成controller的大佬终于出来了 ActivatorUtilities 是这个类 ，名字听着就霸气，进一步进去 结果看不到了，因为asp.net core的源码没有这部分。所以就在这停下吧 .如果你想更深入的了解不妨看看这篇文章，深入且详细 ASP.NET Core Controller与IOC的羁绊
controller类的生成总结
它不是托管到ioc的，而是通过其他的方式获取 ，获取逻辑：ControllerActionInvokerCache.GetCachedResult()=>ControllerFactoryProvider.CreateControllerFactory()=>DefaultControllerFactory.CreateController()=>DefaultControllerActivator.Create()=>TypeActivatorCache.CreateInstance()=>ActivatorUtilities.CreateFactory(type, Type.EmptyTypes);这个就是一步步的调用逻辑，不像我写逻辑，直接new一个完事
controller类的调用逻辑
上面知道了 controller源头从哪来，那现在就要寻找他的出生地。继续找逻辑.我们知道CreateRequestDelegate生成处理委托，这就是处理整个处理逻辑，返回了一个ControllerActionInvoker 。
var invoker = new ControllerActionInvoker(
_logger,
_diagnosticListener,
_actionContextAccessor,
_mapper,
controllerContext,
cacheEntry,
filters);
return invoker.InvokeAsync();
实际上是调用 InvokeAsync（）.这个就吊了，逻辑就涉及到我们的各种过滤器了.
ResourceInvoker
public virtual Task InvokeAsync()
{
_actionContextAccessor.ActionContext = _actionContext;
var scope = _logger.ActionScope(_actionContext.ActionDescriptor);
Task task;
try
{ // 调用filter管道
task = InvokeFilterPipelineAsync();
}
catch (Exception exception)
{
return Awaited(this, Task.FromException(exception), scope);
}
if (!task.IsCompletedSuccessfully)
{
return Awaited(this, task, scope);
}
static async Task Awaited(ResourceInvoker invoker, Task task, IDisposable? scope)
{
try
{
await task;
}
finally
{
await invoker.ReleaseResourcesCore(scope);
}
}
}
InvokeFilterPipelineAsync
private Task InvokeFilterPipelineAsync()
{
var next = State.InvokeBegin;
// The `scope` tells the `Next` method who the caller is, and what kind of state to initialize to
// communicate a result. The outermost scope is `Scope.Invoker` and doesn't require any type
// of context or result other than throwing.
var scope = Scope.Invoker;
// The `state` is used for internal state handling during transitions between states. In practice this
// means storing a filter instance in `state` and then retrieving it in the next state.
var state = (object?)null;
// `isCompleted` will be set to true when we've reached a terminal state.
var isCompleted = false;
try
{
while (!isCompleted)
{
var lastTask = Next(ref next, ref scope, ref state, ref isCompleted);
if (!lastTask.IsCompletedSuccessfully)
{
return Awaited(this, lastTask, next, scope, state, isCompleted);
}
}
return Task.CompletedTask;
}
catch (Exception ex)
{
// Wrap non task-wrapped exceptions in a Task,
// as this isn't done automatically since the method is not async.
return Task.FromException(ex);
}
static async Task Awaited(ResourceInvoker invoker, Task lastTask, State next, Scope scope, object? state, bool isCompleted)
{
await lastTask;
while (!isCompleted)
{
await invoker.Next(ref next, ref scope, ref state, ref isCompleted);
}
}
}
结合 next函数实用 （贴部分代码）
next函数
private Task Next(ref State next, ref Scope scope, ref object? state, ref bool isCompleted)
{
switch (next)
{
case State.InvokeBegin:
{
goto case State.AuthorizationBegin;
}
case State.AuthorizationBegin:
{
_cursor.Reset();
goto case State.AuthorizationNext;
}
//删除了一堆代码
case State.ActionBegin:
{
//实际上调用此代码
var task = InvokeInnerFilterAsync();
if (!task.IsCompletedSuccessfully)
{
next = State.ActionEnd;
return task;
}
goto case State.ActionEnd;
}
case State.ActionEnd:
{
if (scope == Scope.Exception)
{
// If we're inside an exception filter, let's allow those filters to 'unwind' before
// the result.
isCompleted = true;
return Task.CompletedTask;
}
var task = InvokeResultFilters();
if (!task.IsCompletedSuccessfully)
{
next = State.ResourceInsideEnd;
return task;
}
goto case State.ResourceInsideEnd;
}
case State.InvokeEnd:
{
isCompleted = true;
return Task.CompletedTask;
}
default:
throw new InvalidOperationException();
}
}
可以看到上面的调用逻辑，实际上是状态机，指明下一步调用的函数和逻辑，然后直到完全完成任务，我们可以看到 当actionbegin开始的时候调用的任务是 InvokeInnerFilterAsync,可以点进去具体看看,具体类是ControllerActionInvoker
ControllerActionInvoker
protected override Task InvokeInnerFilterAsync()
{
try
{
var next = State.ActionBegin;
var scope = Scope.Invoker;
var state = (object?)null;
var isCompleted = false;
while (!isCompleted)
{
//重点代码
var lastTask = Next(ref next, ref scope, ref state, ref isCompleted);
if (!lastTask.IsCompletedSuccessfully)
{
//返回task ，实际保证了内部逻辑执行的有序性。
return Awaited(this, lastTask, next, scope, state, isCompleted);
}
}
return Task.CompletedTask;
}
static async Task Awaited(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, object? state, bool isCompleted)
{ //参数都是枚举，值类型 或者结构 这点很重要.
await lastTask;
while (!isCompleted)
{
await invoker.Next(ref next, ref scope, ref state, ref isCompleted);
}
}
}
private Task Next(ref State next, ref Scope scope, ref object? state, ref bool isCompleted)
{
switch (next)
{
case State.ActionBegin:
{
var controllerContext = _controllerContext;
//游标指针归0,指向当前的filter位置.
_cursor.Reset();
//调用了 委托生成 controller实例. 生成controller
_instance = _cacheEntry.ControllerFactory(controllerContext);
var task = BindArgumentsAsync();
if (task.Status != TaskStatus.RanToCompletion)
{
next = State.ActionNext;
return task;
}
goto case State.ActionNext;
}
// 如果filter调用完了，那么就进去到这个方法.
case State.ActionInside:
{
//调用controller的action方法.
var task = InvokeActionMethodAsync();
if (task.Status != TaskStatus.RanToCompletion)
{
next = State.ActionEnd;
return task;
}
goto case State.ActionEnd;
}
}
// 调用的具体方法
private Task InvokeActionMethodAsync()
{
// 保留了一些重要代码.
var objectMethodExecutor = _cacheEntry.ObjectMethodExecutor;
var actionMethodExecutor = _cacheEntry.ActionMethodExecutor;
var orderedArguments = PrepareArguments(_arguments, objectMethodExecutor);
//调用 controller action方法.
var actionResultValueTask = actionMethodExecutor.Execute(_mapper, objectMethodExecutor, _instance!, orderedArguments);
if (actionResultValueTask.IsCompletedSuccessfully)
{
_result = actionResultValueTask.Result;
}
else
{
return Awaited(this, actionResultValueTask);
}
return Task.CompletedTask;
}
此时我们终于找到了 controller的调用逻辑链，同时我们也找到了 我们注册的过滤器在哪个位置被调用，它为我们揭开了神秘的面纱。invoker.InvokeAsync()=>InvokeFilterPipelineAsync()=>next() (状态机调用了我们注入的filter)=>InvokeActionMethodAsync()。
总结
做个总结，首先来说目标是想看看mapcontroller背后做了哪些事情，可以看到，它实际上给我们注册了endpoint数据源，通过endpointdatasourcefactory创建一个datasource（new 一个）,实际上是我们为每一个action创建一个RouteEndpoint, 通过CreateRequestDelegate方法创建处理请求的委托,然后通过调用DefaultControllerFactory类为我们创建controller实例，并没有从ioc中获取，然后我们在我们在处理请求的时候，通过引入状态机的调用模式，将我们注入的filters来对请求进行先一步的处理，同时调用InvokeActionMethodAsync方法完成请求的处理。大概的逻辑就是这样。还有我们注入了endpointdatasource，所以才有userouting，useendpoint等进而注入一些重要的中间件，有兴趣的可以看看上一篇文章。
总结的总结，对着源码找了一下调用的逻辑，以后写bug的时候更加得心应手了.
有兴趣可以看看以下文章
ASP.NET Core Controller与IOC的羁绊
.NET Core开发日志——Controller