本文是对工作中的项目进行代码优化（完善登陆验证的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方法吗？望各位大牛看官提点。