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

.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进行过滤吗？

性能？

此外，我想大家在看了这篇文章后来一起思考一些问题，而我对于这些问题

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!