ControllerModel类型的Actions属性包含一组描述有效Action方法的ActionModel对象。对于定义在Controller类型中的所有方法,究竟哪些方法才能成为有效的Action方法呢?所以在正式介绍ActionModel类型之前,我们先来聊聊Action方法的选择规则。
一、Action方法的选择
二、ActionModel
三、PropertyModel与ParameterModel
四、SelectorModel
五、实例演示:选择器模型的构建
一、 Action方法的选择
当DefaultApplicationModelProvider对象根据某个具体的Controller类型创建对应ControllerModel对象的时候,它会提取出定义在该类型中的方法,并按照预定义的规则选择出有效的Action方法。有效的Action方法必须满足如下条件:
- 公共方法:私有(Private)、内部(Internal)和受保护(Protected)方法均为无效Action方法。
- 非抽象方法:抽象方法为无效的Action方法(这个限制可以忽略,因为Controller不会是抽象类型)。
- 非泛型方法:Action方法不能定义成泛型方法。
- 非静态方法:静态方法为无效Action方法。
- 不是从Object类型上继承的方法:Action方法支持继承,但是从Object类型上继承的方法不能成为Action方法。
- 不是对IDisposable接口的实现:如果Controller类型实现了IDisposable接口,实现的Dispose方法不是有效的Action方法。
二、ActionModel
如下面的代码片段所示,ActionModel类型实现了ICommonModel、IFilterModel和IApiExplorerModel三个接口。默认注册的DefaultApplicationModelProvider会对ActionModel对象做如下的设置:MemberInfo和ActionMethod属性都将设置为描述当前Action方法的MethodInfo对象。通过标注的特性注册到Action方法上的过滤器会被提取出来,对应的元数据会添加到Filters属性中。ApiExplorer属性返回的ApiExplorerModel对象由标注在Action方法上实现了IApiDescriptionGroupNameProvider和IApiDescriptionVisibilityProvider接口的特性构建而成。
public class ActionModel : ICommonModel, IFilterModel, IApiExplorerModel { public ControllerModel Controller { get; set; } public IList Filters { get; } public ApiExplorerModel ApiExplorer { get; set; } public IDictionaryobject, object> Properties { get; } public IList Parameters { get; } public IList Selectors { get; } public MethodInfo ActionMethod { get; } public string DisplayName { get; } public string ActionName { get; set; } public IReadOnlyListobject> Attributes { get; } public IOutboundParameterTransformer RouteParameterTransformer { get; set; } public IDictionarystring, string> RouteValues { get; } MemberInfo ICommonModel.MemberInfo { get; } string ICommonModel.Name { get; } }
DefaultApplicationModelProvider会为Action方法的每个参数创建一个ParameterModel对象,并添加到Parameters属性中。应用在Action方法上的用于封装路由信息(特性路由、约束和终结点元数据)的SelectorModel对象会按照上述的方式构建出来,并添加到Selectors属性中。标注在Action方法上的特性会被提取出来并添加到Attributes属性返回的列表中。表示Action名称的ActionName与Name属性具有相同的值,DefaultApplicationModelProvider会默认将它们设置为方法的名称,但是我们可以在方法上通过标注如下这个ActionNameAttribute特性对该属性进行设置。
[AttributeUsage(AttributeTargets.Method, AllowMultiple=false, Inherited=true)] public sealed class ActionNameAttribute : Attribute { public string Name { get; } public ActionNameAttribute(string name); }
我们照例通过一个简单的示例来演示一下DefaultApplicationModelProvider对象针对ActionModel的构建规则。我们依然沿用前面创建的演示实例,这次我们将FoobarController定义成如下的形式。如代码片段所示,我们为Action方法定义了三个参数,并在上面标注了四个特性,其中FoobarAttribute特性是我们应用在该Action方法上的过滤器,ApiExplorerSettingsAttribute特性针对ApiExplorer作了相应设置,HttpGetAttribute特性完成了针对路由和HTTP方法约束的定义,ActionNameAttribute特性则将Action名称设置为“Baz”。
public class FoobarController { [Foobar] [ApiExplorerSettings(GroupName ="test")] [HttpGet("/foobar/baz")] [ActionName("Baz")] public void Index(string foo, string bar, string baz) => throw new NotImplementedException(); }
我们需要修改定义在HomeController中的Action方法Index。如下面的代码片段所示,在利用通过参数注入的ApplicationModelProducer对象根据提供的FoobarController类型创建出对应ApplicationModel对象之后,我们提取出描述Action方法Index的ActionModel对象,并将其作为Model呈现在默认的View中。
public class HomeController : Controller { [HttpGet("/")] public IActionResult Index([FromServices]ApplicationModelProducer producer) { var applicationModel = producer.Create(typeof(FoobarController)); return View(applicationModel.Controllers.Single().Actions.Single()); } }
我们将按照如下的形式重新定义了Action方法Index对应的View。如下面的代码片段所示,这是一个Model类型为ActionModel的强类型View,,它将ActionModel承载的元数据呈现在一个表格中。
@model Microsoft.AspNetCore.Mvc.ApplicationModels.ActionModel
@{
var filters = Model.Filters;
var routeValues = Model.RouteValues.ToArray();
var parameters = Model.Parameters;
var attributes = Model.Attributes;
}
html>
head>
title>Actiontitle>
head>
body>
table border="1" cellpadding="0" cellspacing="0">
tr>td>Methodtd>td>@Model.ActionMethod.Nametd>tr>
tr>td>ActionNametd>td>@Model.ActionNametd>tr>
tr>td>DisplayNametd>td>@Model.DisplayNametd>tr>
tr>
td rowspan="@parameters.Count">Parameterstd>
td>@parameters[0].Nametd>
tr>
@for (int index = 1; index parameters.Count; index++)
{
tr>td>@parameters[index].Nametd>tr>
}
tr>
td rowspan="@filters.Count">Filterstd>
td>@filters[0].GetType().Nametd>
tr>
@for (int index = 1; index filters.Count; index++)
{
tr>td>@filters[index].GetType().Nametd>tr>
}
tr>
td rowspan="@attributes.Count">Attributestd>
td>@attributes[0].GetType().Nametd>
tr>
@for (int index = 1; index attributes.Count; index++)
{
tr>td>@attributes[index].GetType().Nametd>tr>
}
@if (routeValues.Length == 0)
{
tr>td>RouteValuestd>td>N/Atd>tr>
}
else
{
tr>
td rowspan="@routeValues.Length">RouteValuestd>
td>@routeValues[0].Key = @routeValues[0].Valuetd>
tr>
}
@for (int index = 1; index routeValues.Length; index++)
{
tr>td>@routeValues[index].Key = @routeValues[index].Valuetd>tr>
}
tr>
td rowspan="2">ApiExplorertd>
td>IsVisible = @Model.ApiExplorer.IsVisible td>
tr>
tr>
td>GroupName = @Model.ApiExplorer.GroupName td>
tr>
table>
body>
html>
改动后的演示程序启动后,我们利用浏览器访问应用的主页,可以得到如图1所示的输出结果。我们从图中可以看出,Action名称来源于标注在方法上的ActionNameAttribute特性。DefaultApplicationModelProvider会为方法的每个参数创建一个ParameterModel对象并添加到ActionModel对象的Properties属性中。通过特性标注注册到Action方法上的FoobarAttribute过滤器被添加到ActionModel对象的Filters属性中。Action方法标注的四个特性全部被添加到ActionModel对象的Attributes属性中。ActionModel对象的ApiExplorer属性返回的ApiExplorerModel对象是由标注在方法上的ApiExplorerSettingsAttribute特性构建的。值得一提的是,Controller和Action的名称此时并没有作为路由参数添加到RouteValues属性中。
图1 Action模型默认的构建规则
三、PropertyModel与ParameterModel
默认注册的DefaultApplicationModelProvider会将定义在Controller类型的公共属性(包括从基类继承的属性)提取创建,然后创建相应的PropertyModel对象并添加到ControllerModel对象的ControllerProperties属性中。描述属性的PropertyModel对象和描述参数的ParameterModel对象都是为了提供模型绑定的元数据,所以它们具有相同的基类ParameterModelBase。
public abstract class ParameterModelBase : IBindingModel { public string Name { get; protected set; } public Type ParameterType { get; } public IReadOnlyListobject> Attributes { get; } public BindingInfo BindingInfo { get; set; } public IDictionaryobject, object> Properties { get; } }
如上面的代码片段所示,抽象类ParameterModelBase实现了IBindingModel,所以它需要利用实现的BindingInfo书信提供模型绑定信息。ParameterModelBase并没有实现IPropertyModel接口,但是其自身提供了一个Properties属性。ParameterModelBase的Name和ParameterType属性分别表示对应参数/属性的名称和类型。标注到属性上的特性会添加到Attributes属性中。如下所示的是描述Controller属性的PropertyModel类型,和描述Action方法参数的ParameterModel类型的定义。
public class PropertyModel : ParameterModelBase, ICommonModel, IBindingModel { public ControllerModel Controller { get; set; } public PropertyInfo PropertyInfo { get; } public string PropertyName { get; set; } public IReadOnlyListobject> Attributes { get; } public IDictionaryobject, object> Properties { get; } MemberInfo ICommonModel.MemberInfo { get; } } public class ParameterModel : ParameterModelBase, ICommonModel { public ActionModel Action { get; set; } public ParameterInfo ParameterInfo { get; } public string ParameterName { get; set; } public string DisplayName { get; } public IReadOnlyListobject> Attributes { get; } public IDictionaryobject, object> Properties { get; } MemberInfo ICommonModel.MemberInfo { get; } }
四、SelectorModel
SelectorModel类型是对Action选择器(Selector)的描述,这里的选择器旨在解决如何为请求选择匹配Action的问题,所以它承载的其实针对路由的原始定义。如下面的代码片段所示,SelectorModel类型通过AttributeRouteModel、ActionConstraints和EndpointMetadata分别存储了特性路由信息、约束和终结点元数据。
public class SelectorModel { public AttributeRouteModel Attr服务器托管网ibuteRouteModel { get; set; } public IList ActionConstraints { get; } public IListobject> EndpointMetadata { get; } } public class AttributeRouteModel { public IRouteTemplateProvider Attribute { get; } public string Template { get; set; } public int? Order { get; set; } public string Name { get; set; } public bool SuppressLinkGeneration { get; set; } public bool SuppressPathMatching { get; set; } public bool IsAbsoluteTemplate { get; } }
由于路由可以通过标注到Controller类型或者Action方法上相应的特性来定义,所以描述Controller类型和Action方法的ControllerModel和ActionModel类型都具有一个Selectors属性来保存各自的选择器,DefaultApplicationModelProvider针对它们的解析方式也是一致的。这里用来定义路由的特性实现了如下所示的IRouteTemplateProvider特性。
public interface IRouteTemplateProvider { string Template { get; } int? Order { get; } string Name { get; } }
顾名思义,实现IRouteTemplateProvider接口的特性旨在定义一个针对指定模板的路由。除此之外,针对SelectorModel的构建还涉及另一个名为IActionHttpMethodProvider的接口,实现该接口的特性为目标Action定义针对HTTP方法的约束。
public interface IActionHttpMethodProvider { IEnumerablestring> HttpMethods { get; } }
对于目前提供的实现了IActionHttpMethodProvider接口的特性来说,它们无一例外都同时实现了IRouteTemplateProvider接口。比如下面这个AcceptVerbsAttribute特性可以标注到Action方法上指定一组支持的HTTP方法,同时也可以利用三个属性(Route、Name和Order)对路由作相应的定义(显式实现的Template和Order属性与服务器托管网自身Route和Order属性具有相同的值)。顺便提一下,我们在AcceptVerbsAttribute特性构造函数以字符串指定的HTTP方法名称会一律转换成大写形式。
[AttributeUsage( AttributeTargets.Method, AllowMultiple=true, Inherited=true)] public sealed class AcceptVerbsAttribute : Attribute, IActionHttpMethodProvider, IRouteTemplateProvider { public IEnumerablestring> HttpMethods { get; } public string Route { get; set; } public int Order { get; set; } public string Name { get; set; } string IRouteTemplateProvider.Template { get; } int? IRouteTemplateProvider.Order { get; } public AcceptVerbsAttribute(string method); public AcceptVerbsAttribute(params string[] methods); }
虽然AcceptVerbsAttribute特性可以为我们指定多个支持的HTTP方法,但是我们似乎更倾向于使用针对具有某种HTTP方法的特性,比如HttpGetAttribute、HttpPostAttribute、HttpPutAttribute、HttpDeleteAttribute、HttpHeadAttribute、HttpPatchAttribute和HttpOptionsAttribute特性,它们都派生于如下这个抽象的HttpMethodAttribute特性类型。
[AttributeUsage( AttributeTargets.Method, AllowMultiple=true, Inherited=true)] public abstract class HttpMethodAttribute : Attribute, IActionHttpMethodProvider, IRouteTemplateProvider { public IEnumerablestring> HttpMethods { get; } public string Template { get; } public int Order { get; set; } public string Name { get; set; } int? IRouteTemplateProvider.Order { get; } public HttpMethodAttribute(IEnumerablestring> httpMethods); public HttpMethodAttribute(IEnumerablestring> httpMethods, string template); }
IRouteTemplateProvider接口除了上述这些实现类型之外,如下这个专门用来定义路由的RouteAttribute特性单独实现了该接口。从提供的代码片段可以看出,RouteAttribute特性可以标注在Controller类型或者具体的Action方法上。
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, AllowMultiple=true, Inherited=true)] public class RouteAttribute : Attribute, IRouteTemplateProvider { public string Template { get; } public int Order { get; set; } public string Name { get; set; } public RouteAttribute(string template); int? IRouteTemplateProvider.Order { get; } }
DefaultApplicationModelProvider针对SelectorModel对象的构建逻辑分为两种情况。如果标注在当前Controller类型或者Action方法上的特性没有提供任何路由信息,这种情况由分为两种场景:其一,根本没有标注任何实现了IRouteTemplateProvider接口的特性;其二,所有的特性并没有对定义在该接口的三个属性(Template、Name和Order)做任何设置,比如我们经常在Action方法上标注一个没有提供任何参数的HttpGetAttribute特性,其目的只是限制支持的HTTP方法,而不是定义路由。
在这种情况下,DefaultApplicationModelProvider会创建一个唯一的SelectorModel对象。由于没有任何路由被定义,所以该对象的AttributeRouteModel属性会返回Null。标注在Controller类型或者Action方法上实现了IActionConstraintMetadata接口的特性会作为约束添加到ActionConstraints属性中。如果标注了实现IActionHttpMethodProvider接口的特性对HTTP方法做了限制,一个对应的HttpMethodActionConstraint对象会额外创建出来并添加到ActionConstraints属性中。与此同时,一个针对HTTP方法列表的HttpMethodMetada对象会被创建出来并作为终结点元数据被添加到EndpointMetadata属性中。除此之外,所有特性都会作为终结点元数据添加到EndpointMetadata属性中。
如果当前Controller类型或者Action方法上标注了实现IRouteTemplateProvider接口的特性,并且作了具体的路由设置,DefaultApplicationModelProvider会为每个IRouteTemplateProvider对象创建一个SelectorModel对象。对于每一个针对IRouteTemplateProvider对象创建的SelectorModel对象来说,设置的路由信息会被提取出来用于创建对应的AttributeRouteModel对象。如果当前特性是一个IActionHttpMethodProvider对象,一个对应的HttpMethodActionConstraint对象会额外创建出来并添加到ActionConstraints属性中。与此同时一个针对HTTP方法列表的HttpMethodMetada对象会被创建出来,当前特性和这个对象都将作为终结点元数据被添加到EndpointMetadata属性中。
如果当前IRouteTemplateProvider对象类型为RouteAttribute,那些没有提供路由信息的实现了IActionHttpMethodProvider接口的特性(即只定义了HTTP方法约束的特性)会被提取出来,一个根据它们提供的HTTP方法列表创建的HttpMethodActionConstraint对象并添加到ActionConstraints属性中。与此同时,一个针对HTTP方法列表的HttpMethodMetada对象会被创建出来并作为终结点元数据被添加到EndpointMetadata属性中。EndpointMetadata属性最终包含的终结点元数据还包括当前RouteAttribute特性和这些单纯定义约束的特性。
五、实例演示:选择器模型的构建
对于DefaultApplicationModelProvider为Controller类型或者Action方法构建SelectorModel的逻辑,我想针对具体的场景会更好理解一点,为此我们来演示几个简单的实例。我们依然沿用前面的演示程序,并将FoobarController类型改写成如下的形式。FoobarController类型中定义了三个Action方法,接下来我们看看DefaultApplicationModelProvider对象会为它们创建出怎样的选择器。
public class FoobarController { [HttpGet] [HttpPost] public void Foo()=>throw new NotImplementedException(); [HttpGet("bar")] [HttpPost("bar")] public void Bar() => throw new NotImplementedException(); [HttpGet()] [HttpPost("bar")] [Route("bar")] public void Baz() => throw new NotImplementedException(); }
我们对定义在HomeController中的Action方法Index作如下的修改。如代码片段所示,在该方法中,我们利用通过参数注入的ApplicationModelProducer对象根据FoobarController类型创建出对应的ApplicationModel对象,然后利用查询字符串绑定的actionName参数提取出描述对应Action的ActionModel对象。我们将ActionModel对象的Selectors属性提取的选择器列表作为Model呈现在View中。
public class HomeController : Controller { [HttpGet("/")] public IActionResult Index([FromServices]ApplicationModelProducer producer, [FromQuery]string actionName) { var applicationModel = producer.Create(typeof(FoobarController)); var actionModel = applicationModel.Controllers.Single().Actions.Single(it=>string.Compare(it.ActionName, actionName, true) == 0); return View(actionModel.Selectors); } }
如下所示的是修改后的View。如代码片段所示,这个是一个Model类型为IList的强类型View,我们将提供的用于描述选择器的每个SelectorModel对象的元数据信息呈现在表格中。
@using Microsoft.AspNetCore.Mvc.ApplicationModels;
@model IListSelectorModel>
html>
head>
title>Selectorstitle>
head>
body>
table border="1" cellpadding="0" cellspacing="0">
@for (int i = 0; i Model.Count; i++)
{
var selector = Model[i];
var constraints = selector.ActionConstraints;
var metadata = selector.EndpointMetadata;
tr>td colspan="2">Selector @(i+1)td>tr>
tr>
td>AttributeRouteModeltd>
td>@selector.AttributeRouteModel?.Templatetd>
tr>
tr>
td rowspan="@constraints.Count">ActionConstraintstd>
td>@constraints[0].GetType().Nametd>
tr>
@for (int j = 1; j constraints.Count; j++)
{
tr>td>@constraints[j].GetType().Nametd>tr>
}
tr>
td rowspan="@metadata.Count">EndpointMetadatatd>
td>@metadata[0].GetType().Nametd>
tr>
@for (int j = 1; j metadata.Count; j++)
{
tr>td>@metadata[j].GetType().Nametd>tr>
}
}
table>
body>
html>
由于第一个Action方法Foo上的两个IActionHttpMethodProvider特性并没有提供任何的路由信息,所以它只具有一个AttributeRouteModel属性为Null的SelectorModel对象。这两个特性提供的针对HTTP方法(GET和POST)的约束会转换成一个HttpMethodActionConstraint对象并添加到SelectorModel对象的ActionConstraints属性中。除此之外,这两个特性会直接作为终结点元数据被添加到SelectorModel对象的EndpointMetadata属性中,该属性还会包含一个针对HTTP方法约束的HttpMethodMetada对象。图2所示的就是演示应用返回的针对Action方法Foo的选择器信息。
图2 Action方法Foo的选择器
第二个Action方法Bar上的两个特性均指定了路由模板,所以DefaultApplicationModelProvider会为它创建两个针对性的SelectorModel对象。DefaultApplicationModelProvider会根据特性(HttpGetAttribute和HttpPostAttribute)提供的路由信息来创建对应的AttributeRouteModel对象。SelectorModel对象ActionConstraints属性会包含根据各自提供的HTTP方法约束创建的HttpMethodActionConstraint对象。EndpointMetadata属性将会包含两个终结点元数据对象,分别是当前的特性和根据HTTP方法约束创建的HttpMethodMetada对象。图3所示的就是演示应用返回的针对Action方法Bar的选择器列表。
图3 Action方法Bar的选择器
第三个Action方法方法上标注了三个特性,但是其中只有两个特性提供了路由信息,所以DefaultApplicationModelProvider最终会根据标注的HttpPostAttribute和RouteAttribute特性创建出两个对应的SelectorModel对象。根据标注的HttpPostAttribute特性针对SelectorModel对象的创建与上面一致,所以我们现在只关注针对RouteAttribute特性创建的SelectorModel对象。该对象提供的AttributeRouteModel对象自然由RouteAttribute特性提供的路由信息来创建。
该方法上没有提供路由信息的HttpGetAttribute特性将被用来提供当前路由的约束,所以这个SelectorModel对象的ActionConstraints属性中会包含一个根据这个特性创建的HttpMethodActionConstraint对象。这个SelectorModel对象的EndpointMetadata属性中最终会包含三个终结点元数据,分别是标注的RouteAttribute和HttpGetAttribute特性,以及根据HTTP方法约束创建的HttpMethodMetada对象。图4所示的就是演示应用返回的针对Action方法Baz的选择器列表。
图4 Action方法Bar的选择器
ASP.NET Core MVC应用模型的构建[1]: 应用的蓝图
ASP.NET Core MVC应用模型的构建[2]: 应用模型
ASP.NET Core MVC应用模型的构建[3]: Controller模型
ASP.NET Core MVC应用模型的构建[4]: Action模型
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net
机房租用,北京机房租用,IDC机房托管, http://www.fwqtg.net