你的位置:首页 > ASP.net教程

[ASP.net教程]利用多态,实现一般处理程序(ashx)中的AOP(切面编程)


本文是对工作中的项目进行代码优化(完善登陆验证的AOP切面编程)时,所遇到的各种解决方案思考过程。

项目背景:由ashx+nvelocity构建的简单B/S问卷系统,现需要优化登录验证环节(时隔若干个月在回顾代码果然是一个痛苦的过程~)

nvelocity是velocity框架针对.net的版本,核心是拼html字符串后返回客户端,与MVC的前后端代码隔离有异曲同工之妙。加之一般处理程序ashx不需要像asp.net那样走生成控件树的过程,执行上更是省时省力。故简单系统用ashx+nvelocity的形式构建笔者个人还是比较推荐的。如果那么在意访问地址(如www.abc.com/news/index.ashx?id=234)中的ashx后缀不好看,完全可以通过模块(HttpModule)来实现url重写。

本文讨论的是:如何在ashx中体现AOP切面编程思想?

(1)回顾asp.net,所有页面继承自Page类,可通过Page的子类来实现AOP。原来是:Default : Page,切面插入后是:Default : LoginCheckPage,LoginCheckPage : Page。如此便能在LoginCheckPage类中编写登录验证的代码,且能实现所有需要验证页面的有效解耦——解耦是相对于专门写一个LoginCheck类,并在各个Default页面做验证(如LoginCheck.Check(context))而言,更利于修改与拓展。

(2)回顾MVC,可以依样画葫芦像上述asp.net那样,原来是:HomeController:Controller,切面插入后是:HomeController:LoginCheckController,LoginCheckController:Controller。除此之外,还能利用类/方法头上的特性标签来做AOP。

在asp.net与MVC中的AOP体现还有许多做法,此处抛砖引玉、仅为比对ashx的AOP做思考:上述方法在ashx中能行得通吗? 能!但要做些微调:

(独写一个LoginCheck类,然后在每个需要验证的ashx.pr()中加上LoginCheck.Check(context)实在不是长久之计,故本文就不另说了)

第一种尝试:(没错,本文最后一次才尝试成功,不过写出尝试过程也是为了将自己所走的弯路做下记录,且希望能给读者更多思考的提示,感谢坚持读完三种尝试的朋友。)

利用HttpModule。类似url重写那样,url重写不都是每次请求一来就做处理吗,那Module应该也能做登陆吧——两者差异:普通的url重写不涉及客户端隔离、不考虑请求的资源,登录验证要做客户端隔离(cookie)、要考虑请求的资源(并不是所有资源都不给访问,有的是游客级别就行的)。

对于要考虑请求资源的差异,如果恶心一点,可以在代码中写死(可优化成在webcofig、其他配置文件、数据库存储)来做差异化处理——以正则表达式匹配请求地址,用来隔离需要验证登陆的请求与不需要验证的请求。

对于客户端隔离,能否直接在Module中用session?首先要使HttpModule继承自IReadonlySessionState/IRequiresSessionState接口(HttpHandler也是如此),以便在走管道的时候能被.net认出来你这个Module想用session。注册到BeginRequest事件。别忘了还要注册到webconfig。一切就绪,调试,报错——HttpApplication中的Session属性报错,未将对象引用设置到对象实例。是不是注册的事件错了?我查了一遍HttpApplication管道中的19个事件,最佳的切入点在第10-11个事件之间,也就是+=PostAcquireRequest,才能在获取Session之后、在执行ashx之前做登陆验证。

然而并没有什么X用……依旧未将对象引用设置到对象实例。怎么还是没有呢,奇了怪了。

又是一边各种查,查到一句话说得好:Module是应用程序级的事儿,是过滤作用,而Session是页面级的事儿,是要根据发来的请求做不同的处理,故在Module中用Session本就不是最佳方案。故放弃Module这条弯路。

第二种尝试:

自定义继承自IHttpHandler的ashx。原来:Index:IHttpHandler,优化后:Index:LoginCheckHandler,LoginCheckHandler:IHttpHandler。学的上述asp.net与mvc中的插入到继承树的方法。但调试结果是根本不走Index的ProcessRequest(),直接走完LoginCheckHandler.ProcessRequest()就返回了,客户端就是空白一片。究其原因:实现IHttpHandler的一般处理程序(无论是Index,还是LoginCheckHandler),都只会执行一次ProcessRequest()。

第三种尝试:

在第二种的基础上修改为:LoginCheckHandler中的ProcessRequest()改为virtual,并在Index子类中override重写,并在Index.ProcessRequest()中调用base.ProcessRequest(context)。执行的时候,程序会因为看到override而忽略父类的PR方法,而Index子类中的base.PR()又要求程序先走父类的PR方法,且结合Response.Redirect()的立即输出特性(先Flush,在End),可以使得不满足登录验证条件的请求被挡在门外。小功告成!

麻烦的是,要修改子类为override,且在子类中存在base.PR()代码(也只比简单粗暴的调用LoginCheck.Check(context)来验证减少了一些些耦合度),那么还有更好的AOP方法吗?望各位大牛看官提点。