Request如何过完它的一生

它的一生都是在一个管道（pipeline）里度过的：

我们可以使用Filter机制，在适当的时间点“插入”自己的逻辑：

接口

所以我们需要创建一些类，让他们实现ASP.NET内置的一些接口：

实现接口

RazorPages预定义了一些接口，按执行的先后顺序依次是：

1. IAuthorizationFilter，最早执行，用于访问权限验证（常用），只有一个方法
2. IResourceFilter：处理静态资源（如图片/js/css文件等）时执行
3. IPageFilter：Model绑定和HandlerMethod前后执行，共三个方法，按执行先后顺序类似于PageModel中override的Filter方法
4. IResultFilter：.cshtml页面生成前后执行

最后还有一个IExceptionFilter：当抛出异常时执行

开发人员可以实现这些接口，在其接口方法中添加自定义的业务逻辑。比如：  

    public class NeedLogOnAttribute : IAuthorizationFilter
    {
        public void OnAuthorization(AuthorizationFilterContext context)
        {
            //自定义的验证逻辑代码
        }
    }

FilterContext

和在PageModel中override不同，我们自定义的Filter实现类只能依靠

    public void OnAuthorization(AuthorizationFilterContext context)
    {
        string userId = context.HttpContext.Request.Cookies[Keys.UserId];
        if (string.IsNullOrEmpty(userId))
        {
            context.Result = new RedirectResult("/Log/On");
        }
    }

不同的FilterContext，比如，在PageHandlerExecutedContext

            (context.HandlerInstance as PageModel).TempData

@想一想@：context里面的值又是哪里来的呢？

这样，所有的PageModel在运行时都会在相应时间点依次调用：

Attribute化

有时候我们不想Filter应用于全局。比如登录/注册页面就不需要已登录用户访问。

自定义的类继承自Attribute，然后标记于PageModel。同时

让NeedLogOn再继承Attribute，就可以把

    public class NeedLogOnAttribute : Attribute, IAuthorizationFilter

就可以把NeedLogOn当做Attribute放到PageModel上，比如：

    [NeedLogOn]
    public class NewModel : PageModel

注意：只能是PageModel上，不能是PageHandler Method上

继承基类

RazorPages还定义了一些FilterAttribute基类，包括：

• ExceptionFilterAttribute
  
• ResultFilterAttribute
  

可以看到，他们都是实现了相应的Filter接口，并继承了Attribute的。

通过override可以

作业：

• 参考一起帮，使用[NeedLogOn]保证未登录用户无法访问只有登录用户才能访问的页面：
  1. 未登录用户强行访问上述页面，自动跳转到登录页面
  2. 此时的登录页面显示提示
  3. 登录之后，自动跳转到之前欲访问页面

暂时不做

• 使用[AutoValidation]和[ImportModelError]，自动完成Model Validation功能
  
• 使用[ContextPerRequest]，实现一个Request（注意：不是Action，ChildAction不使用新的DbContext）一个DbContext的功能

源栈学历

在当前系列 垃圾桶 中继续学习：

多快好省！前端后端，线上线下，名师精讲

• 先学习，后付费；
• 不满意，不要钱。
• 编程培训班，我就选源栈

更多了解 加：