详解ASP.NET MVC的筛选器

在actioninvoker对action的执行过程中，除了通过利用actiondescriptor对action方法的执行，以及之前进行的model绑定与验证之外，还具有一个重要的工作，那就是对相关筛选器（filter）的执行。asp.net mvc的筛选器是一种基于aop（面向方面编程）的设计，我们将一些非业务的逻辑实现在相应的筛选器中，然后以一种横切（crosscutting）的方式应用到对应的action方法。当action方法执行前后，这些筛选器会自动执行。asp.net mvc提供了四种类型的筛选器（authorizationfilter、actionfilter、resultfilter和exceptionfilter），它们对应着相应的筛选器接口（iauthorizationfilter、iactionfilter、iresultfilter和iexceptionfilter）。[本文已经同步到《how asp.net mvc works?》中]

目录

一、filter

二、filterprovider

三、filterattribute与filterattributefilterprovider

四、controller与controllerinstancefilterprovider

五、globalfiltercollection

六、实例演示：验证filter的提供机制和执行顺序

一、filter

虽然asp.net mvc提供的四种类型的筛选器具有各自实现的接口，但是对于筛选器的提供体系来说所有的筛选器都通过具有如下定义的filter类型表示。filter的核心是instance属性，因为它代表真正实施筛选功能的对象，该对象实现了一个或者多个基于上述四种筛选器类型的接口。

  public class filter
  {  
    public const int defaultorder = -1;  
    public filter(object instance, filterscope scope, int? order);
    
    public object instance { get; protected set; }
    public int order { get; protected set; }
    public filterscope scope { get; protected set; }
  }
  public enum filterscope
  {
    action    = 30,
    controller  = 20,
    first     = 0,
    global    = 10,
    last     = 100
  }

注：由于system.web.mvc.filter和实现了iauthorizationfilter、iactionfilter、iresultfilter和iexceptionfilter的类型均可以被称为“筛选器”，为了不至于造成混淆，在没有做明确说明的情况下，我们使用英文“filter”和中文“筛选器”分别来表示它们。

filter的order和scope属性最终决定了筛选器的执行顺序。order属性对应数值越小，执行的优先级越高，该属性的默认值为-1（对应着filter中定义的常量defaultorder）。如果两个filter具有相同的order属性值，那么scope属性最终决定哪个被优先执行。filter的scope属性类型是一个类型为filterscope的枚举。该枚举表示应用filter的范围，action和controller代表action方法和controller类级别；first和last意味着希望被作为第一个和最后一个filter来执行；global代表一个全局的filter。

通过上面的代码片断我们可以看到filterscope的5个枚举选项均被设置了一个值，这个值决定了filter的执行顺序，具有更小的枚举值会被优先执行。从filterscope的定义可以得到这样的结论：对于具有相同order属性值的多个filter，应用在controller上的filter比应用在action方法上的filter具有更高的执行优先级，而一个全局的filter的执行优先级又高于基于action的filter。

二、filterprovider

filter的提供机制与之前我们介绍的基于modelbinder和modelvalidator的提供机制比较类似，均是通过相应的provider来提供的。提供筛选器的filterprovider实现了接口ifilterprovider，如下面的代码片断所示，该接口定义了唯一的方法getfilters根据指定的controller上下文和用于描述目标action的actiondescriptor对象获取一个filter对象集合。

  public interface ifilterprovider
  {  
    ienumerable<filter> getfilters(controllercontext controllercontext, actiondescriptor actiondescriptor);
  }

我们可以通过静态类型filterproviders注册或者获取当前应用使用的filterprovider。如下面的代码片断所示，filterproviders具有一个类型为filterprovidercollection的只读属性providers，表示基于整个web应用范围内被使用的filterprovider列表。filterprovidercollection是元素类型为ifilterprovider的集合，getfilters方法用于或者该集合中所有filterprovider对象提供的filter对象。

  public static class filterproviders
  {  
    public static filterprovidercollection providers { get; }
  } 
  public class filterprovidercollection : collection<ifilterprovider>
  {   
    //其他成员
    public ienumerable<filter> getfilters(controllercontext controllercontext, actiondescriptor actiondescriptor);  
  }

asp.net mvc提供了三种原生的filterprovider，分别是filterattributefilterprovider、controllerinstancefilterprovider和globalfiltercollection，接下来我们对它们进行单独介绍。

三、filterattribute与filterattributefilterprovider

我们通常将筛选器定义成特性以声明的方式应用到controller类型或者action方法上，而抽象类型filterattribute是所有筛选器的基类。如下面的代码片断所示，filterattribute特性实现了imvcfilter接口，该接口定义了order和allowmultiple两个只读属性，分别用于控制筛选器的执行顺序以及多个同类的筛选器能够同时应用到同一个目标元素（类或者方法）。

  [attributeusage(attributetargets.method | attributetargets.class, inherited=true, allowmultiple=false)]
  public abstract class filterattribute : attribute, imvcfilter
  {  
    protected filterattribute();
    
    public bool allowmultiple { get; }
    public int order { get; set; }
  }
  public interface imvcfilter
  {  
    bool allowmultiple { get; }
    int order { get; }
  }

从应用在filterattribute上的attributeusageattribute的定义可以看出该特性可以应用在类型和方法上，这意味着筛选器一般都可以应用在controller类型和action方法上。只读属性allowmultiple实际上返回的是attributeusageattribute的同名属性，通过上面的定义我们可以看到默认情况下该属性值为false。

用于描述controller和action的controllerdescriptor和actiondescriptor均实现了icustomattributeprovider接口，我们可以直接利用它们获取应用在对应的controller类型或者action方法上包括filterattribute在内的所有特性。实际上，这两个描述类型提供了单独的方法getfilterattributes专门用于获取filterattribute特性列表。如下面的代码片断所示，该方法具有一个布尔类型的参数usecache，表示是否需要对解析出来的filterattribute特性进行缓存以缓解频繁的反射操作对性能造成的影响。

  public abstract class controllerdescriptor : icustomattributeprovider, iuniquelyidentifiable
  {
    //其他成员
    public virtual ienumerable<filterattribute> getfilterattributes(bool usecache);
  }
  public abstract class actiondescriptor : icustomattributeprovider, iuniquelyidentifiable
  {  
    //其他成员
    public virtual ienumerable<filterattribute> getfilterattributes(bool usecache);  
  }

针对filterattribute特性的filter通过filterattributefilterprovider对象来提供。filterattributefilterprovider直接调用当前controllerdescriptor和actiondescriptor的getfilterattributes方法获取所有应用在controller类型和当前action方法的filterattribute特性，并借此创建相应的filter对象。filterattributefilterprovider构造函数的参数cacheattributeinstances表示是否启用针对filterattribute的缓存，它将作为调用getfilterattributes方法的参数。在默认的情况下（通过调用默认无参的构造函数创建的filterattributefilterprovider）会采用针对filterattribute的缓存。

  public class filterattributefilterprovider : ifilterprovider
  {
    public filterattributefilterprovider();
    public filterattributefilterprovider(bool cacheattributeinstances);
    protected virtual ienumerable<filterattribute> getactionattributes(controllercontext controllercontext, actiondescriptor actiondescriptor);
    protected virtual ienumerable<filterattribute> getcontrollerattributes(controllercontext controllercontext, actiondescriptor actiondescriptor);
    public virtual ienumerable<filter> getfilters(controllercontext controllercontext, actiondescriptor actiondescriptor);
  }

对于通过调用getfilters得到的filter，对应的filterattribute特性作为其instance属性。order属性来源于filterattribute的同名属性，而scope属性则取决于filterattribute特性是应用在controller类型上（scope属性值为controller）还是当前的action方法上（scope属性值为action）。

四、controller与controllerinstancefilterprovider

提到asp.net mvc的筛选器，大部分的都只会想到通过filterattribute特性，实际上controller本身（继承自抽象类controller）就是一个筛选器。如下面的代码片断所示，抽象类controller实现了iactionfilter、iauthorizationfilter、iexceptionfilter和iresultfilter这四个对应着不同筛选器类型的接口。

  public abstract class controller : controllerbase, 
    iactionfilter, 
    iauthorizationfilter, 
    iexceptionfilter, 
    iresultfilter, 
     ...
  {
    //省略成员
  }

针对controller对象这种独特筛选器的filterprovider类型为具有如下定义的controllerinstancefilterprovider。在实现的getfilters方法中，它会根据指定的controller上下文获取对应的controller对象，并以此创建一个filter（controller对象作为filter对象的instance属性值）。该filter的scope不是controller，而是first，而order的值为-2147483648（int32.minvalue），毫无疑问这样的filter肯定第一个被执行。

  public class controllerinstancefilterprovider : ifilterprovider
  {  
    public ienumerable<filter> getfilters(controllercontext controllercontext, actiondescriptor actiondescriptor);  
  }

五、globalfiltercollection

通过filterattribute的形式定义的筛选器需要显式地标注到目标controller类型或者action方法上，而在有些情况下需要一种全局的filter。所谓全局筛选器，就是不需要显式与某个controller或者action进行匹配，而是默认使用到所有的action执行过程中。用于提供这种全局filter的filterprovider对应的类型为具有如下定义的globalfiltercollection。

  public sealed class globalfiltercollection : ienumerable<filter>, ienumerable, ifilterprovider
  {
    public globalfiltercollection();
    public void add(object filter);
    public void add(object filter, int order);
    private void addinternal(object filter, int? order);
    public void clear();
    public bool contains(object filter);
    public ienumerator<filter> getenumerator();
    public void remove(object filter);
    ienumerator ienumerable.getenumerator();
    ienumerable<filter> ifilterprovider.getfilters(controllercontext controllercontext, actiondescriptor actiondescriptor);
    public int count { get; }
  }

通过命名以及上面给出的定义可以看出globalfiltercollection就是一个filter的列表而已，实现的getfilters方法返回的就是它自己。通过globalfiltercollection提供的方法我们可以实现对全局filter的添加、删除和清除操作。用于添加filter的add方法的参数filter不是一个filter对象，而是一个具体筛选器（实现了相应的筛选器接口），添加的filter对象根据该筛选器对象创建，其scope属性被设置成global。我们通过在add方法指定添加filter对象的order属性，如果没有显示指定order并且指定的筛选器是一个filterattribute特性，那么该特性的order将会作为filter对象的order；否则使用-1作为order属性值。

针对整个web应用的全局filter（或者说全局filterprovider）的注册和获取可以通过静态类型globalfilters来实现。如下面的代码片断所示，globalfilters具有一个静态只读属性filters返回一个globalfiltercollection对象。

  public static class globalfilters
  {  
    public static globalfiltercollection filters { get; }
  }

到目前为止，我们已经介绍了asp.net mvc默认提供的三种filterprovider，以及各自采用得filter提供机制。当用于注册filterprovider的静态类型在加载的时候，会默认创建这三种类型的对象并将其作为表示全局filterprovider集合的providers属性值，具体的逻辑体现在如下的代码片断中。也就是说，在默认的情况下asp.net mvc会采用这三种filterprovider来提供所有的filter对象。

  public static class filterproviders
  { 
    static filterproviders()
    {
      providers = new filterprovidercollection();
      providers.add(globalfilters.filters);
      providers.add(new filterattributefilterprovider());
      providers.add(new controllerinstancefilterprovider());
    } 
    public static filterprovidercollection providers{get;private set;}
  }

六、实例演示：验证filter的提供机制和执行顺序

为了让读者对上面介绍的filter提供机制具有一个更加深刻的映像，我们来做一个简单的实例演示。在一个通过visual studio的asp.net mvc项目模板创建的空web项目中，我们定义了如下一个几个filterattribute。filterbaseattribute是一个实现了iactionfilter接口的抽象类型，三个具体的filterattribute（fooattribute、barattribute和bazattribute）是它的继承者。

  public abstract class filterbaseattribute:filterattribute, iactionfilter
  {
    public void onactionexecuted(actionexecutedcontext filtercontext)
    {} 
    public void onactionexecuting(actionexecutingcontext filtercontext)
    {}
  } 
  public class fooattribute : filterbaseattribute
  {}
  public class barattribute : filterbaseattribute
  {}
  public class bazattribute : filterbaseattribute
  {} 

我们首先在global.asax中通过如下的方式将bazattribute注册为一个全局筛选器。需要注意的是定义在默认创建的global.asax中的application_start方法会调用registerglobalfilters方法注册一个类型为handleerrorattribute的exceptionfilter，我们需要将这行代码注释。

  public class mvcapplication : system.web.httpapplication
  {
    //其他成员
    protected void application_start()
    {    
      //其他操作
      //registerglobalfilters(globalfilters.filters);    
      globalfilters.filters.add(new bazattribute());
    }
  }

最后我们创建如下一个默认的homecontroller，一个空的action方法data上应用了我们定义的barattribute特性，而homecontroller类上则应用了fooattribute特性。在默认的action方法index中，我们通过filterproviders的静态属性providers表示的全局filterprovider列表得到针对于action方法data的所有filter对象，并将它们的基本信息（类型、order和scope属性）呈现出来。

  [foo]
  public class homecontroller : controller
  {
    public void index()
    {
      reflectedcontrollerdescriptor controllerdescriptor = new reflectedcontrollerdescriptor(typeof(homecontroller));
      actiondescriptor actiondescriptor = controllerdescriptor.findaction(controllercontext, "data");
      foreach (var filter in filterproviders.providers.getfilters(controllercontext, actiondescriptor))
      { 
        response.write(string.format("{0}<br/>",filter.instance));
        response.write(string.format("    {0}: {1}<br/>", "order",filter.order));
        response.write(string.format("    {0}: {1}<br/><br/>", "scope",filter.scope));
      }
    }
    [bar]
    public void data()
    { }
  }

运行我们的程序之后会在浏览器中呈现如图7-5所示的结果。我们可以清楚地看到，不仅仅应用在自身action方法的filterattribute会应用到目标action上，应用在controller类的filterattribute、全局注册的filter以及controller对象本身体现的filter都回最终应用在所有的action上面。

上图将应用于action方法data的4个filter的order和scope属性显示出来。我们在前面提到这两个属性决定了同类筛选器执行的顺序，我们现在利用这个程序要证实这一点。为此我们需要对filterbaseattribute作如下的修改，在onactionexecuting中我们将当前执行的filterattribute的类型的方法名呈现出来。

  public abstract class filterbaseattribute:filterattribute, iactionfilter
  {
    public void onactionexecuted(actionexecutedcontext filtercontext)
    {}
    public void onactionexecuting(actionexecutingcontext filtercontext)
    {
      filtercontext.httpcontext.response.write(string.format("{0}.onactionexecuting()<br/>", this.gettype()));
    }
  }

然后我们按照相同的方式重写了homecontroller的onactionexecuting方法，将homecontroller自身的类型的当前方法名称呈现出来。

  [foo]
  public class homecontroller : controller
  {
    //其他成员
    protected override void onactionexecuting(actionexecutingcontext filtercontext)
    {
      response.write("homecontroller.onactionexecuting()<br/>");
    } 
    [bar]
    public void data()
    { }
  }

我们再次运行我们的程序，并在浏览器上指定正确的地址访问定义在homecontroller的action方法data，会在浏览器中呈现如下图所示的结果。输出的结果体现了应用到action方法data上的四个actionfilter执行的顺序，而这是和filter对应的order和scope属性值是一致的。

关于filter的提供还另一个值得深究的问题：我们在定义filterattribute的时候可以将应用在该类型上的attributeusageattribute的allowmultiple属性设置为false使它只能在同一个目标元素上应用一次。但是，我们依然可以在action方法和所在的controller类型上应用它们，甚至可以将它们注册为全局filter，那么这些filterattribute都将有效吗？

我们现在就来通过实例来验证这一点。现在我们删除所有的filterattribute，定义如下一个类型为fooattribute的actionfilter，我们将应用在它上面的attributeusageattribute特性的allowmultiple属性设置为false。

  [attributeusage(attributetargets.class | attributetargets.method, allowmultiple = false)]
  public class fooattribute : filterattribute, iactionfilter
  {
    public void onactionexecuted(actionexecutedcontext filtercontext)
    { }
    public void onactionexecuting(actionexecutingcontext filtercontext)
    { }
  }

现在我们将该fooattribute特性同时应用在homecontroller类型和action方法data上，然后在global.asax中注册一个针对fooattribute特性的全局filter。

  [foo]
  public class homecontroller : controller
  {
    //其他成员
    [foo]
    public void data()
    { }
  } 
  public class mvcapplication : system.web.httpapplication
  {
    //其他成员
    protected void application_start()
    {
      //其他操作
      //registerglobalfilters(globalfilters.filters);
      globalfilters.filters.add(new fooattribute());
    }
  }

现在我们直接运行我们的程序，开启的浏览器中会呈现出如图7-7所示的结果。可以清楚地看到虽然我们 在三个地方注册了fooattribute，但是由于该特性的allowmultiple属性为false，所以只有其中一个fooattribute最终是有效的。

对于allowmultiple属性为false的filterattribute来说，如果我们以不同的scope注册了多个，最终有效的是哪个呢？从上图可以看出，应用在action方法（scope为action）上的fooattribute是有效的。其实具体的逻辑是这样的：所有被创建的filter按照order+scope进行排序（即filter执行的顺序），取排在最后一个。对于我们的例子来说，提供的三个filter具有相同的order属性值（-1），所有最终会按照scope（scope、controller和action）进行排序，排在最后一个的自然是scope为action的filter。

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，如果有疑问大家可以留言交流，同时也希望多多支持！