通过极简模拟框架让你了解ASP.NET Core MVC框架的设计与实现[上篇]

2021-04-03 05:25

阅读：452

标签：复杂 exception developer isp tpc 代码问题 over data

《200行代码，7个对象——让你了解ASP.NET Core框架的本质》让很多读者对ASP.NET Core管道有了真实的了解。在过去很长一段时间中，有很多人私信给我：能否按照相同的方式分析一下MVC框架的设计与实现原理，希望这篇文章能够满足你们的需求。在对本章内容展开介绍之前，顺便作一下广告：《ASP.NET Core 3框架揭秘》已经开始销售，现时5折优惠还有最后4天，有兴趣的从这里入群购买。

目录
一、Action元数据的解析
     ActionDescriptor
     IActionDescriptorProvider
     IActionDescriptorCollectionProvider
二、路由
     IActionInvoker
     ActionEndpointDataSourceBase
     ControllerActionEndpointDataSource
三、Action的执行
     执行Action方法
     服务注册
四、在模拟框架构建一个MVC应用

整个MVC框架建立在路由中间件（《ASP.NET Core 3框架揭秘》下册具有对路由中间件的专门介绍）上。不论是面向Controller的Model-View-Controller编程模型，还是面向页面的Razor Pages编程模型，每个请求指向的都一个某个Action，所以MVC框架只需要将每个Action封装成一个路由终结点（RouteEndpoint），并通过自定义的EndpointDataSource注册到路由中间件上即可。被封装的路由终结点它的请求处理器会帮助我们执行对应的Action，这是一个相对复杂的流程，所以我们创建了一个模拟框架。模拟框架采用真实MVC框架的设计和实现原理，但是会在各个环节进行最大限度地简化。我们希望读者朋友们通过这个模拟框架对MVC框架的设计与实现具有一个总体的认识。源代码从这里下载。

一、Action元数据的解析

由于我们需要在应用启动的时候将所有Action提取出来并封装成路由终结点，所以我们需要一种“Action发现机制”得到定义在所有Controller类型的Action方法，以及所有Razor Page对应的Action方法，并将它们的元数据提取出来。两种编程模型的Action元数据都封装到一个ActionDescriptor对象中。

ActionDescriptor

模拟框架针对Action的描述体现在如下这个ActionDescriptor类型上，它的两个属性成员都与路由有关。我们知道面向Controller的MVC模型支持两种形式的路由，即“约定路由（Conventional Routing）”和“特性路由（Attribute Routing）”。对于前者，我们可以将路由规则定义在Action方法上标注的特性（比如HttpGetAttribute特性）上，后者则体现为针对路由的全局注册。

public abstract class ActionDescriptor
{
    public AttributeRouteInfo AttributeRouteInfo { get; set; }
    public IDictionarystring, string> RouteValues { get; set; }
}

public class AttributeRouteInfo
{
    public int Order { get; set; }
    public string Template { get; set; }
}

我们将通过特性路由提供的原始信息封装成一个AttributeRouteInfo对象，它的Template代表路由模板。对于一组给定的路由终结点来说，有可能存在多个终结点的路由模式都与某个请求匹配，所以代表路由终结点的RouteEndpoint类型定义了一个Order属性，该属性值越小，代表选择优先级越高。对于通过特性路由创建的RouteEndpoint对象来说，它的Order属性来源于对应AttributeRouteInfo对象的同名属性。

ActionDescriptor的RouteValues属性与“约定路由”有关。比如我们全局定义了一个模板为“{controller}/{action}/{id?}”的路由（{controller}和{action}分别表示Controller和Action的名称），如果定义在某个Controller类型（比如FooController）的Action方法（比如Bar）上没有标注任何路由特性，它对应的路由终结点将采用这个约定路由来创建，具体的路由模板将使用真正的Controller和Action名称（“Foo/Bar/{id?}”）。ActionDescriptor的RouteValues属性表示某个Action为约定路由参数提供的参数值，这些值会用来替换约定路由模板中相应的路由参数来生成属于当前Action的路由模板。

我们的模拟框架只提供针对面向Controller的MVC编程模型的支持，针对该模型的Action描述通过如下这个ControllerActionDescriptor类型表示。ControllerActionDescriptor类型继承自抽象类ActionDescriptor，它的MethodInfo和ControllerType属性分别表示Action方法和所在的Controller类型。

public class ControllerActionDescriptor : ActionDescriptor
{
    public Type ControllerType { get; set; }
    public MethodInfo Method { get; set; }
}

IActionDescriptorProvider

当前应用范围内针对有效Action元数据的解析通过相应的IActionDescriptorProvider对象来完成。如下面的代码片段所示，IActionDescriptorProvider接口通过唯一的属性ActionDescriptors来提供用来描述所有有效Action的ActionDescriptor对象。

public interface IActionDescriptorProvider
{
    IEnumerable ActionDescriptors { get; }
}

如下这个ControllerActionDescriptorProvider类型是IActionDescriptorProvider接口针对面向Controller的MVC编程模型的实现。简单起见，我们在这里作了这么一个假设：所有的Controller类型都定义在当前ASP.NET Core应用所在的项目（程序集）中。基于这个假设，我们在构造函数中注入了代表当前承载环境的IHostEnvironment对象，并利用它得到当前的应用名称。由于应用名称同时也是程序集名称，所以我们得以获取应用所在的程序集，并从中解析出有效的Controller类型。

public class ControllerActionDescriptorProvider : IActionDescriptorProvider
{
    private readonly Lazy _accessor;

    public IEnumerable ActionDescriptors => _accessor.Value;

    public ControllerActionDescriptorProvider(IHostEnvironment environment)
    {
        _accessor = new Lazy(() => GetActionDescriptors(environment.ApplicationName));
    }

    private IEnumerable GetActionDescriptors(string applicationName)
    {
        var assemblyName = new AssemblyName(applicationName);
        var assembly = Assembly.Load(assemblyName);
        foreach (var type in assembly.GetExportedTypes())
        {
            if (type.Name.EndsWith("Controller"))
            {
                var controllerName = type.Name.Substring(0, type.Name.Length - "Controller".Length);
                foreach (var method in type.GetMethods())
                {
                    yield return CreateActionDescriptor(method, type, controllerName);
                }
            }
        }
    }

    private ControllerActionDescriptor CreateActionDescriptor(MethodInfo method, Type controllerType, string controllerName)
    {
        var actionName = method.Name;
        if (actionName.EndsWith("Async"))
        {
            actionName = actionName.Substring(0, actionName.Length - "Async".Length);
        }
        var templateProvider = method.GetCustomAttributes().OfType().FirstOrDefault();

        if (templateProvider != null)
        {
            var routeInfo = new AttributeRouteInfo
            {
                Order = templateProvider.Order ?? 0,
                Template = templateProvider.Template
            };
            return new ControllerActionDescriptor
            {
                AttributeRouteInfo = routeInfo,
                ControllerType = controllerType,
                Method = method
            };
        }

        return new ControllerActionDescriptor
        {
            ControllerType = controllerType,
            Method = method,
            RouteValues = new Dictionarystring, string>
            {
                ["controller"] = controllerName,
                ["action"] = actionName
            }
        };
    }
}

简单起见，我们只是将定义在当前应用所在程序集中采用“Controller”后缀命名的类型解析出来，并将定义在它们之中的公共方法作为Action方法（针对Controller和Action方法应该做更为严谨的有效性验证，为了使模拟框架显得更简单一点，我们刻意将这些验证简化了）。我们根据类型和方法解析出Controller名称（类型名称去除“Controller”后缀）和Action名称（方法名去除“Async”后缀），并进一步为每个Action方法创建出对应的ControllerActionDescriptor对象。

如果Action方法上标注了如下这个IRouteTemplateProvider接口类型的特性（比如HttpGetAttribute类型最终实现了该接口），意味着当前Action方法采用“特性路由”，那么最终创建的ControllerActionDescriptor对象的AttributeRouteInfo属性将通过这个特性构建出来。如果没有标注这样的特性，意味着可能会采用约定路由，所以我们需要将当前Controller和Action名称填充到RouteValues属性表示的”必需路由参数值字典”中。

public interface IRouteTemplateProvider
{
    string Name { get; }
    string Template { get; }
    int? Order { get; }
}

IActionDescriptorCollectionProvider

ControllerActionDescriptorProvider类型仅仅是IActionDescriptorProvider接口针对面向Controller的MVC编程模型的实现，Razor Pages编程模型中对应的实现类型为PageActionDescriptorProvider。由于同一个应用是可以同时支持这两种编程模型的，所以这两个实现类型可能会同时注册到应用的依赖注入框架中。MVC框架需要获取两种编程模型的Action，这一个功能体现在如下这个IActionDescriptorCollectionProvider接口上，描述所有类型Action的ActionDescriptor对象通过它的ActionDescriptors属性返回。

public interface IActionDescriptorCollectionProvider
{
    IReadOnlyList ActionDescriptors { get; }
}

如下所示的DefaultActionDescriptorCollectionProvider是对IActionDescriptorCollectionProvider接口的默认实现，它直接利用在构造函数中注入的IActionDescriptorProvider对象列表来提供描述Action的ActionDescriptor对象。

public class DefaultActionDescriptorCollectionProvider : IActionDescriptorCollectionProvider
{
    private readonly Lazy _accessor;
    public IReadOnlyList ActionDescriptors => _accessor.Value;
    public DefaultActionDescriptorCollectionProvider(IEnumerable providers)
        => _accessor = new Lazy(() => providers.SelectMany(it => it.ActionDescriptors).ToList());
}

二、路由

当描述Action的所有ActionDescriptor对象被解析出来之后，MVC框架需要将它们转换成表示路由终结点的RoutEndpoint对象。一个RoutEndpoint对象由代表路由模式的RoutePattern对象和代表请求处理器的RequestDelegate对象组成。RoutePattern对象可以直接通过ActionDescriptor对象提供的路由信息构建出来，所以最难解决的是如果创建出用来执行目标Action的RequestDelegate对象。MVC框架中针对Action的执行是通过一个IActionInvoker对象来完成的。

IActionInvoker

MVC框架需要解决的核心问题就是根据请求选择并执行目标Action，所以用来执行Action的IActionInvoker对象无疑是整个MVC框架最为核心的对象。虽然重要性不容置疑，但是IActionInvoker接口的定义却极其简单。如下面的代码片段所示，IActionInvoker接口只定义了一个唯一的InvokeAsync，这是一个返回类型为Task的无参数方法。

public interface IActionInvoker
{
    Task InvokeAsync();
}

用来执行Action的IActionInvoker对象是根据每个请求上下文动态创建的。具体来说，当路由解析成功并执行匹配终结点的请求处理器时，针对目标Action的上下文对象会被创建出来，一个IActionInvokerFactory对象会被用来创建执行目标Action的IActionInvoker对象。顾名思义，IActionInvokerFactory接口代表创建IActionInvoker对象的工厂，针对IActionInvoker对象的创建体现在如下这个CreateInvoker方法上。

public interface IActionInvokerFactory
{
    IActionInvoker CreateInvoker(ActionContext actionContext);
}

具体的IActionInvokerFactory对象应该创建怎样的IActionInvoker对象取决于提供的ActionContext上下文。如下面的代码片段所示，ActionContext对象是对当前HttpContext上下文的封装，它的ActionDescriptor属性返回的ActionDescriptor对象是对待执行Action的描述。

public class ActionContext
{
    public ActionDescriptor ActionDescriptor { get; set; }
    public HttpContext HttpContext { get; set; }
}

ActionEndpointDataSourceBase

终结点的路由模式可以通过描述Action的ActionDescriptor对象提供的路由信息来创建，它的处理器则可以利用IActionInvokerFactory工厂创建的IActionInvoker对象来完成针对请求的处理，所以我们接下来只需要提供一个自定义的EndpointDataSource类型按照这样的方式为每个Action创建对应的路由终结点就可以了。考虑到两种不同编程模型的差异，我们会定义不同的EndpointDataSource派生类，它们都继承自如下这个抽象的基类ActionEndpointDataSourceBase。

public abstract class ActionEndpointDataSourceBase : EndpointDataSource
{
    private readonly Lazy> _endpointsAccessor;
    protected readonly List> Conventions;

    public override IReadOnlyList Endpoints => _endpointsAccessor.Value;
    protected ActionEndpointDataSourceBase(IActionDescriptorCollectionProvider provider)
    {
        Conventions = new List>();
        _endpointsAccessor = new Lazy>(() => CreateEndpoints(provider.ActionDescriptors, Conventions));
    }
    public override IChangeToken GetChangeToken() => NullChangeToken.Instance;
    protected abstract List CreateEndpoints(IReadOnlyList actions, IReadOnlyList> conventions);
}

MVC框架支持采用全局注册方式的 “约定理由（Conventional Routing ）” ，这里的约定路由规则通过Action对象的列表来体现，对应着ActionEndpointDataSourceBase类型的Conventions属性。ActionEndpointDataSourceBase类型的构造函数中注入了一个IActionDescriptorCollectionProvider对象，我们利用它来获取描述当前应用范围内所有Action的ActionDescriptor对象。Endpoints属性返回的路由终结点列表最终是通过抽象方法CreateEndpoints根据提供的ActionDescriptor对象列表和约定路由列表创建的。对于重写的GetChangeToken方法，我们直接返回如下这个不具有变化监测功能的NullChangeToken对象。

internal class NullChangeToken : IChangeToken
{
    public bool ActiveChangeCallbacks => false;
    public bool HasChanged => false;
    public IDisposable RegisterChangeCallback(Actionobject> callback, object state) => new NullDisposable();
    public static readonly NullChangeToken Instance = new NullChangeToken();
    private class NullDisposable : IDisposable
    {
        public void Dispose() { }
    }
}

ControllerActionEndpointDataSource

ControllerActionEndpointDataSource是ActionEndpointDataSourceBase的派生类型，它帮助我们完成基于Controller的MVC编程模式下的路由终结点的创建。不过在正式介绍这个类型之前，我们先来介绍两个与 “约定路由” 相关的类型。如下这个ConventionalRouteEntry结构表示单个约定路由的注册项，其中包括路由名称、路由模式、Data Token和排列位置。我们在上面说过，注册的约定路由规则最终体现为一个Action对象的列表，ConventionalRouteEntry的Conventions属性返回的就是这个列表。

internal struct ConventionalRouteEntry
{
    public string RouteName;
    public RoutePattern Pattern { get; }
    public RouteValueDictionary DataTokens { get; }
    public int Order { get; }
    public IReadOnlyList> Conventions { get; }

    public ConventionalRouteEntry(string routeName, string pattern,
        RouteValueDictionary defaults, IDictionarystring, object> constraints,
        RouteValueDictionary dataTokens, int order,
        List> conventions)
    {
        RouteName = routeName;
        DataTokens = dataTokens;
        Order = order;
        Conventions = conventions;
        Pattern = RoutePatternFactory.Parse(pattern, defaults, constraints);
    }
}

另一个与约定路由相关的是如下这个ControllerActionEndpointConventionBuilder类型，我们从其明明不难看出该类型用来帮助我们构建约定路由。ControllerActionEndpointConventionBuilder是对一个Action列表的封装，它定义的唯一的Add方法仅仅是向该列表中添加一个表示路由约定的Action对象罢了。

public class ControllerActionEndpointConventionBuilder : IEndpointConventionBuilder
{
    private readonly List> _conventions;
    public ControllerActionEndpointConventionBuilder(List> conventions)
    {
        _conventions = conventions;
    }
    public void Add(Action convention) => _conventions.Add(convention);
}

我们最后来看看ControllerActionEndpointDataSource类型的定义。对于ControllerActionEndpointDataSource对象构建的路由终结点来说，作为请求处理器的RequestDelegate委托对象指向的都是ProcessRequestAsync方法。我们先来看看ProcessRequestAsync方法是如何处理请求的：该方法首先从HttpContext上下文中获取当前终结点的Endpoint对象，并从其元数据列表中得到预先放置的用来表示目标Action的ActionDescriptor对象。接下来，该方法根据HttpContext上下文和这个ActionDescriptor对象创建出ActionContext上下文。该方法最后从基于请求的依赖注入容器中提取出IActionInvokerFactory工厂，并利用它根据当前ActionContext上下文创建出对应的IActionInvoker对象。请求的处理最终通过执行该IActionInvoker得以完成。

public class ControllerActionEndpointDataSource : ActionEndpointDataSourceBase
{
    private readonly List _conventionalRoutes;
    private int _order;
    private readonly RoutePatternTransformer _routePatternTransformer;
    private readonly RequestDelegate _requestDelegate;

    public ControllerActionEndpointConventionBuilder DefaultBuilder { get; }

    public ControllerActionEndpointDataSource(IActionDescriptorCollectionProvider provider, RoutePatternTransformer transformer) : base(provider)
    {
        _conventionalRoutes = new List();
        _order = 0;
        _routePatternTransformer = transformer;
        _requestDelegate = ProcessRequestAsync;
        DefaultBuilder = new ControllerActionEndpointConventionBuilder(base.Conventions);
    }

    public ControllerActionEndpointConventionBuilder AddRoute(string routeName, string pattern, RouteValueDictionary defaults, IDictionarystring, object> constraints, RouteValueDictionary dataTokens)
    {
        List> conventions = new List>();
        order++;
        conventionalRoutes.Add(new ConventionalRouteEntry(routeName, pattern, defaults,constraints, dataTokens, _order, conventions));
        return new ControllerActionEndpointConventionBuilder(conventions);
    }

    protected override List CreateEndpoints(IReadOnlyList actions, IReadOnlyList> conventions)
    {
        var endpoints = new List();
        foreach (var action in actions)
        {
            var attributeInfo = action.AttributeRouteInfo;
            if (attributeInfo == null) //约定路由
            {
                foreach (var route in _conventionalRoutes)
                {
                    var pattern = _routePatternTransformer.SubstituteRequiredValues(route.Pattern, action.RouteValues);
                    if (pattern != null)
                    {
                        var builder = new RouteEndpointBuilder(_requestDelegate, pattern, route.Order);
                        builder.Metadata.Add(action);
                        endpoints.Add(builder.Build());
                    }
                }
            }
            else //特性路由
            {
                var original = RoutePatternFactory.Parse(attributeInfo.Template);
                var pattern = _routePatternTransformer.SubstituteRequiredValues(original, action.RouteValues);
                if (pattern != null)
                {
                    var builder = new RouteEndpointBuilder(_requestDelegate, pattern, attributeInfo.Order);
                    builder.Metadata.Add(action);
                    endpoints.Add(builder.Build());
                }
            }
        }
        return endpoints;
    }

    private Task ProcessRequestAsync(HttpContext httContext)
    {
        var endpoint = httContext.GetEndpoint();
        var actionDescriptor = endpoint.Metadata.GetMetadata();
        var actionContext = new ActionContext
        {
            ActionDescriptor = actionDescriptor,
            HttpContext = httContext
        };

        var invokerFactory = httContext.RequestServices.GetRequiredService();
        var invoker = invokerFactory.CreateInvoker(actionContext);
        return invoker.InvokeAsync();
    }
}

ControllerActionEndpointDataSource定义了一个List

在实现的CreateEndpoints方法中，ControllerActionEndpointDataSource会便利提供的每个ActionDescriptor对象，如果该对象的AttributeRouteInfo属性为空，意味着应该采用约定路由，该方法会为每个表示约定路由注册项的ConventionalRouteEntry对象创建一个路由终结点。具体来说，ControllerActionEndpointDataSource会将当前ActionDescriptor对象RouteValues属性携带的路由参数值（包含Controller和Action名称等必要信息），并将其作为参数调用RoutePatternTransformer对象的SubstituteRequiredValues方法将全局注册的原始路由模式（比如“{controller}/{action}/{id?}”）中相应的路由参数替换掉（最终可能变成“Foo/Bar/{id?}”）。SubstituteRequiredValues返回RoutePattern对象将作为最终路由终结点的路由模式。

如果ActionDescriptor对象的AttributeRouteInfo属性返回一个具体的AttributeRouteInfo对象，意味着应该采用特性路由，支持它会利用这个AttributeRouteInfo对象创建一个新的RoutePattern对象将作为最终路由终结点的路由模式。不论是采用何种路由方式，用来描述当前Action的ActionDescriptor对象都会以元数据的形式添加到路由终结点的元数据集合中（对应于Endpoint类型的Metadata属性），ProcessRequestAsync方法中从当前终结点提取的ActionDescriptor对象就来源于此。

ControllerActionEndpointDataSource还提供了一个DefaultBuilder属性，它会返回一个默认的ControllerActionEndpointConventionBuilder对象用来进一步注册约定路由。约定路由可以直接通过调用AddRoute方法进行注册，由于该方法使用自增的_order字段作为注册路由的Order属性，所以先注册的路由具有更高的选择优先级。AddRoute方法同样返回一个ControllerActionEndpointConventionBuilder对象。

如下定义的针对IEndpointRouteBuilder接口的MapMvcControllers扩展方法帮助我们方便地注册ControllerActionEndpointDataSource对象。另一个MapMvcControllerRoute扩展方法则在此基础上提供了约定路由的注册。这两个扩展分别模拟的是MapControllers和MapControllerRoute扩展方法的实现，为了避免命名冲突，我们不得不起一个不同的方法名。

public static class EndpointRouteBuilderExtensions
{
    public static ControllerActionEndpointConventionBuilder MapMvcControllers(this IEndpointRouteBuilder endpointBuilder)
    {
        var endpointDatasource = endpointBuilder.ServiceProvider.GetRequiredService();
        endpointBuilder.DataSources.Add(endpointDatasource);
        return endpointDatasource.DefaultBuilder;
    }

    public static ControllerActionEndpointConventionBuilder MapMvcControllerRoute(
        this IEndpointRouteBuilder endpointBuilder, string name, string pattern,
        RouteValueDictionary defaults = null, RouteValueDictionary constraints = null,
        RouteValueDictionary dataTokens = null)
    {
        var endpointDatasource = endpointBuilder.ServiceProvider.GetRequiredService();
        endpointBuilder.DataSources.Add(endpointDatasource);
        return endpointDatasource.AddRoute(name, pattern, defaults, constraints, dataTokens);
    }
}

三、Action的执行

针对MVC的请求被路由到针对某个Action的路由终结点后，路由终结点将利用IActionInvokerFactory工厂创建的IActionInvoker对象来执行目标Action，进而完成对请求的处理。用于注册Action的 IActionInvoker对象是MVC框架最为核心的对象，在针对Controller的MVC编程模型下，这个对象的类型为ControllerActionInvoker，接下来我们将采用 “由简入繁、循序渐进” 的方式讲述ControllerActionInvoker对象是如何执行Action的。

执行Action方法

上面我们多次提到的“针对Action的执行”并不只限于针对“Action方法”的执行，实际上体现了针对目标Action的路由终结点完整的请求处理流程。定义在Controller类型中的所有公共的实例方法（没有标注NonActionAttribute特性）都是有效的Action方法，为了让问题变得简单，我们先对Action方法的定义方式进行如下的简化：

Action方法都是无参方法，这样我们就不需要考虑参数绑定的问题。
Action方法的返回值都是Task或者Void，所有的请求处理任务都实现在方法中。

为了让Action方法自身就能够完成包括对请求予以响应的所有请求处理任务，我们为具体的Controller类型定义了如下这个同名的抽象基类。如代码片段所示，我们可以通过Controller对象的ActionContext属性得到当前的ActionContext上下文。有了这个上下文，我们自然也就能获得针对当前请求的HttpContext上下文。由于HttpContext上下文，我们不仅能够得到所有请求信息，也能完成任意的响应任务。

public abstract class Controller
{
    public ActionContext  ActionContext { get; internal set; }
}

如下所示的ControllerActionInvoker类型的完整定义。如代码片段所示，一个ControllerActionInvoker对象是根据ActionContext上下文创建的。在实现的InvokeAsync方法中，ControllerActionInvoker根据这个ActionContext得到用于描述目标Action的ControllerActionDescriptor对象，进而得到目标Controller的类型。由于依赖服务可以直接注入到Controller类型的构造函数中，所以我们会利用ActionContext上下文得到针对当前请求的IServiceProvider对象，并利用它来创建Controller对象。

public class ControllerActionInvoker : IActionInvoker
{
    public ActionContext ActionContext { get; }
    public ControllerActionInvoker(ActionContext actionContext) => ActionContext = actionContext;
    public Task InvokeAsync()
    {
        var actionDescriptor = (ControllerActionDescriptor)ActionContext.ActionDescriptor;
        var controllerType = actionDescriptor.ControllerType;
        var requestServies = ActionContext.HttpContext.RequestServices;
        var controllerInstance = ActivatorUtilities.CreateInstance(requestServies, controllerType);
        if (controllerInstance is Controller controller)
        {
            controller.ActionContext = ActionContext;
        }
        var actionMethod = actionDescriptor.Method;
        var result = actionMethod.Invoke(controllerInstance, new object[0]);
        return result is Task task ? task : Task.CompletedTask;
    }
}

如果Controller实例对应的类型派生于抽象基类Controller，我们会对它的ActionContext属性进行设置。我们接下来利用ControllerActionDescriptor对象得到表示目标Action方法的MethodInfo对象，并以反射的方式执行该方法。如果方法返回一个Task对象，我们直接将该对象作为InvokeAsync方法的返回值。如果方法的返回类型为void，那么InvokeAsync返回的是Task.CompletedTask。

IActionInvoker对象IActionInvokerFactory工厂针对ActionContext上下文动态创建的，如下这个ActionInvokerFactory类型是模拟框架提供的针对IActionInvokerFactory接口的默认实现。由于模拟框架只考虑基于Controller的MVC编程模型，所以ActionInvokerFactory类型实现的CreateInvoker方法直接返回一个创建的ControllerActionInvoker对象。

public class ActionInvokerFactory : IActionInvokerFactory
{
    public IActionInvoker CreateInvoker(ActionContext actionContext) => new ControllerActionInvoker(actionContext);
}

服务注册

当目前位置，我们已经通过一系列接口构建出了一个Mini版本MVC框架的模型，并为这些接口做了极简的实现。由于依赖注入（构造函数注入）的编程方式应用到了这些实现类型中，所以我们需要在应用启动的时候将它们作为服务注册到依赖注入框架中，为此我们定义了如下这个AddMvcControllers扩展方法（该方法模拟的是IServiceCollection接口的AddControllers扩展方法）。

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddMvcControllers(this IServiceCollection services)
    {
        return services
            .AddSingleton()
            .AddSingleton()
            .AddSingleton()
            .AddSingleton();
    }
}

如上面的代码片段所示，AddMvcControllers扩展方法完成了针对IActionDescriptorCollectionProvider、IActionInvokerFactory、IActionDescriptorProvider和ControllerActionEndpointDataSource的注册，所有注册均采用Singleton生命周期。

四、在模拟框架构建一个MVC应用

到目前为止，模拟MVC框架的雏形已经构建完毕，我们解析来着在它上面创建一个简单的MVC应用。在如下所示的应用承载程序中，在完成了针对路由终结点以及所需服务注册之后，我们调用了前面定义的AddMvcControllers扩展方法注册了模拟MVC框架必要的服务。在针对IApplicationBuilder接口的UseEndpoints扩展方法的调用中，我们利用提供的Action对象调用了前面定义的MapMvcControllerRoute扩展方法完成了针对ControllerActionEndpointDataSource的注册，并在此基础上注册了一个模板为 “{controller}/{action}” 的约定路由。

public class Program
{
    public static void Main()
    {
        Host.CreateDefaultBuilder()
            .ConfigureWebHostDefaults(builder => builder
            .ConfigureServices(services => services
                    .AddRouting()
                    .AddMvcControllers())
            .Configure(app => app
            .UseDeveloperExceptionPage()
                .UseRouting()
                .UseEndpoints(endpoints => endpoints.MapMvcControllerRoute("default", "{controller}/{action}"))))
            .Build()
            .Run();
    }
}

我们随后定义了如下这个Controller类型FoobarController，它直接继承抽象基类Controller。由于模拟框架假定Action方法都是无参，并且返回类型为Task或者Void，所以我们在FoobarController类型中定义了两个满足此约定的Action方法（FooAsync和BarAsync）。这两个Action方法会直接将方法名称作为响应主体的内容。我们在Action方法FooAsync上标注了HttpGetAttribute特性，并将路由模板设置为 “/{foo}” 。

public class FoobarController : Controller
{
    [HttpGet("/{foo}")]
    public Task FooAsync() => ActionContext.HttpContext.Response.WriteAsync(nameof(FooAsync));
    public Task BarAsync() => ActionContext.HttpContext.Response.WriteAsync(nameof(BarAsync));
}

在启动这个演示程序之后，我们利用浏览器访问定义在FoobarController中的这两个Action方法。由于Action方法FoobarAsync采用特性路由，我们直接将URL路由设置为 “/foo” 。Action方法BarAsync则采用约定路由，按照约定路由的模板定义（ “{controller}/{action}” ），我们应该将URL的路径设置为 “/foobar/bar” 。如图5-1所示，这两个请求都得到了期望的响应。（S501）

技术图片

通过极简模拟框架让你了解ASP.NET Core MVC框架的设计与实现[上篇]
通过极简模拟框架让你了解ASP.NET Core MVC框架的设计与实现[中篇]
通过极简模拟框架让你了解ASP.NET Core MVC框架的设计与实现[下篇]

通过极简模拟框架让你了解ASP.NET Core MVC框架的设计与实现[上篇]

标签：复杂 exception developer isp tpc 代码问题 over data

原文地址：https://www.cnblogs.com/artech/p/inside-asp-net-core-mvc-01.html

上一篇：JS函数封装

下一篇：ctfhub技能树—文件上传—双写后缀

文章来自：搜素材网的编程语言模块，转载请注明文章出处。
文章标题：通过极简模拟框架让你了解ASP.NET Core MVC框架的设计与实现[上篇]
文章链接：http://soscw.com/essay/71686.html

亲，登录后才可以留言！

通过极简模拟框架让你了解ASP.NET Core MVC框架的设计与实现[上篇]

一、Action元数据的解析

ActionDescriptor

IActionDescriptorProvider

IActionDescriptorCollectionProvider

二、路由

IActionInvoker

ActionEndpointDataSourceBase

ControllerActionEndpointDataSource

三、Action的执行

执行Action方法

服务注册

四、在模拟框架构建一个MVC应用

评论

热门文章

推荐文章

最新文章

置顶文章