您的位置:知识库 » .NET技术

一个较完整的关键字过滤解决方案(中)

作者: Jeffrey Zhao  来源: 博客园  发布时间: 2008-12-24 11:10  阅读: 2725 次  推荐: 0   原文链接   [收藏]  
[1] 一个较完整的关键字过滤解决方案(中)
[2] 一个较完整的关键字过滤解决方案(中)

继续改进

  上面的做法(相对使用命名约定的方式)改进了什么地方?很简单,之前提到的命名约定的缺点就是上述做法的优点:

  1. 不同Page(Http Handler)可以自行指定字段所需要的过滤逻辑。
  2. 无需前端改名,只需后端标记。
  3. 避免复杂的命名约定,使多种横切型的过滤功能可以轻易共存。

  真是美妙地嗷嗷的,但是有没有朋友看出问题来?我提示一下:GetFilterType方法中使用了一个常量字符串txtPassword。

  估计有朋友会问:“咦,这有什么问题?”粗看似乎没有,不过老赵看到代码中出现常量总是要警惕一番(自觉是个好喜欢):为啥要是txtPassword而不是txtPassWord(一个常见的拼写错误)?为啥代码中用0而不用-1?这里的问题倒不是说一个常量在代码中到处使用时最好使用一个const——不不,是readonly字段来代替(为啥用const不太好?)。而是……再提示一下,如果某人将页面上的txtName文本框改为txtUserName那会出现何种情况?

  嗯嗯,那么Attribute中的GetFilterType方法当然还是在判断一个key是否由txtName结尾,而我们修改后的页面中Post内容中已经变成了txtUserName,咋整?但是可悲的是,我们尊敬的Attribute,就算你拿刀威胁它它也没法知道该替换什么啊。唉,那又有谁才能知道呢?不用多想,当然是页面本身了。

  .NET中Custom Attribute的特性深入人心,大大增强了.NET中反射机制的可用性,也因此Kent Beck认为NUnit的设计和使用较JUnit更为优雅。老赵的项目中也到处可见Custom Attribute的存在,写出的代码也简单优美强大地很。不过用多了Custom Attribute也造成了一种思维定势,一些“附加功能”往往都喜欢往上靠,很多问题往往一个功能出来三秒不到脑子里就浮出一个利用Custom Attribute的解决方案。古语有云,“世界如此美好,我却如此浮躁,这样不好,不好……”。事实上ASP.NET框架中已经有了不使用Custom Attribute进行“标记”的现成示例。例如,您知道IRequiresSessionState接口和INamingContainer接口的作用吗?

  如果您翻过IRequriedSessionState和INamingContainer接口的文档,就会发现它们有个共同的特点——没有任何成员。这意味着什么呢?这意味着实现了这样的接口的类,唯一的作用就是“别人知道你实现了这个接口”。有点拗口,对吧?其实就是指,这两个接口只起到了标记的作用。使用Custom Attribute或使用接口对一个类进行标记和扩展的优劣取舍,我打算用额外的一篇文章来讨论这个问题(要不现在大家来Brain Storm一下如何?)。目前,朋友们只需关心一点,如果不用Custom Attirubte而使用接口,我们该如何改写上面的程序。并且,这种改变带来了什么好处?

  如果在某些情况中,我们也可以把对象本身作为参数传入Custom Attribute的方法中,Attribute方法内部根据参数的属性来实现逻辑,可惜的是,Page类内部的控件成员是protected变量,无法从外部访问。对于我们来说,使Http Handler(即页面)直接实现某个接口的最大(唯一?)好处,就是让该接口的成员可以访问页面内部的非公开成员了。这点就是问题关键,我们现在不必直接使用txtPassword这个常量,而是能够访问页面中的txtPassword控件来获取它相关的属性(ID)。不再赘述,修改如下:

public interface IForbiddenWordFilter
{
    FilterForbiddenWordType GetFilterType(string key);
}

public partial class Default : System.Web.UI.Page, IForbiddenWordFilter
{
    ...

    FilterForbiddenWordType IForbiddenWordFilter.GetFilterType(string key)
    {
        if (key.EndsWith(this.txtPassword.ID)) return FilterForbiddenWordType.Ignored;
        return FilterForbiddenWordType.Normal;
    }
}

  至于HttpModule上的修改,相信不会难道您,老赵就不在这里说帖太多代码浪费带宽了。可以看出,现在的代码中已经没有了txtPassword这个常量,取而代之的是对txtPassword对象ID的访问。现在如果在aspx中修改了这个控件的ID,那么在aspx.cs中的变量也会被重构至对应名字,这大大提高了开发效率,降低了出错可能。

  差点忘说了一句,大家千万不要忘了对于WebForms模型,有几个特定的key是不能替换的例如“__VIEWSTATE”和“__VIEWSTATEENCRYPTED”。关于这点,老赵的作法是忽略所有以两条下划线作为开头的Key以保护WebForms模型内部需求。

  结合上一篇文章《一个较完整的关键字过滤解决方案(上)》,这似乎就是个较为完整的解决方案,不过这个话题结束了吗?当然没有。在下一篇文章《一个较完整的关键字过滤解决方案(下)》里,我们将讨论几个额外的话题,例如:

  • 这个解决方案的适用场合?不适用场合?
  • 输入过滤?输出过滤?
  • 我们一定要使用HttpModule进行过滤吗?
  • 性能?

  此外,我想大家在看了这篇文章后来一起思考一些问题,而我对于这些问题的看法也会在下一篇文章中谈到:

  • 在WebForms模型中,Page即是一个Handler,于是可以实现IForbiddenWordFilter。那么Page里Control所需要过滤的内容呢?动态加载的Control呢?
  • 这篇文章的示例里有个陷阱,您看的出是在哪里吗?

 

[第1页][第2页]
0
0

.NET技术热门文章

    .NET技术最新文章

      最新新闻

        热门新闻