博客园_Jack & Voila Studio

用Asp.net写自己的服务框架

2011-09-05T15:28:00Z

我的上篇博客【我心目中的Asp.net核心对象】讲述了一些我认为在Asp.net中比较重要的核心对象，以及演示了直接使用它们也能实现一个简单的服务响应。今天，我将继续把我认为Asp.net的另一些重要的内容拿出来与大家一起分享， 同时将使用本次所讲述的内容改进上篇博客所演示的那个简单的服务，让它成为一个真正能用的服务框架。

在这篇博客中，不仅会继续演示上次提到的三个核心对象，我还会再引入另二个关键对象，我将用更多实战代码来演示它们如何在一起协同工作，来完成许多常见任务，展现它们的精彩故事，也最终会让它们来实现我的服务框架。因此，这篇博客不仅仅是针对Asp.net的基础技术的讲触，而是更多地以实战形式展示这些核心对象所能发挥的强大功能，以一个不到700行的轻量级服务框架来显示它们的核心价值，才是这篇博客的目标。

首先我要谈的话题是Asp.net的请求处理【管线】，我认为这是Asp.net中最重要的内容了，所有到达Asp.net的请求都要经过管线来处理，不管是WebForms, MVC, WebService, WCF(Asp.net的承载方式)，还是其它微软的采用HTTP协议的框架。为什么这些框架都选择要Asp.net做为它们的运行平台呢？
我们可以考虑一下：如果让您从无到有设计一个服务框架，有哪些事件是必须要处理的？
我想有三个最根本的事件要做：1. 监听请求端口，2. 为每个传入的连接请求分配线程来执行具体的响应操作， 3. 要把请求的数据读出来，并负责将处理后的响应数据发送给调用者。
这其实是个比较复杂也很枯燥的过程，但每个服务器端程序都需要这些基本功能。幸好IIS和Asp.net可以为我们做好这些事情，所以那些框架选择Asp.net平台就可以省去这些复杂的任务。使用Asp.net平台不仅可以简化设计，它还有着良好的扩展性以满足更多的框架在这个平台上面继续开发，而这个良好扩展性是离不开它的请求处理管线的。

Asp.net是一个功能完善的平台框架，它既提供一些高层次的框架供我们使用，比如:WebForms, MVC, WebService，也提供一些低层次的机制让我们使用，以便于让我们开发有特殊要求的新框架，新解决方案。这个低层次的机制就是请求处理管线，使用这个管线的有二类对象：HttpHandler, HttpModule，控制这条管线工作的对象是：HttpApplication 。通常情况下，我们并不需要直接使用HttpApplication对象，因此本文的主题将主要介绍HttpHandler, HttpModule这二类对象的功能以及如何使用它们。

理解Asp.net管线

管线(Pipeline)这个词也是很有点意思，这个词也形象地说明了每个Asp.net请求的处理过程：请求是在一个管道中，要经过一系列的过程点，这些过程点连接起来也就形成一条线。 以上是我对于这个词的理解，如果有误，恳请给予指正。 这些一系列的过程点，其实就是由HttpApplication引发的一系列事件，通常可以由HttpModule来订阅，也可以在Global.asax中订阅，这一系列的事件也就构成了一次请求的生命周期。

事件模式，也就是观察者模式。根据【C# 3.0 设计模式】一书中的定义：“ 观察者模式定义了对象之间的一种联系，使得当一个对象改变状态时，所有其它的对象都可以相应地被通知到。" Asp.net的管线设计正是采用了这种方式，在这个设计模式中，观察者就是许多HttpModule对象，被观察的对象就是每个”请求“，它的状态是由HttpApplication 控制，用于描述当前请求的处理阶段，HttpApplication会根据一个特定的顺序修改这个状态，并在每个状态改变后引发相应的事件。 Asp.net会为每个请求分配一个HttpApplication对象来引发这些事件，因此可以让一大批观察者了解每个请求的状态，每个观察者也可以在感兴趣的时候修改请求的一些数据。这些与请求相关的数据的也就是我上篇博客中提到的HttpRequest, HttpResponse。正是由于引入了事件机制，Asp.net框架也有了极强的扩展能力。再来看看管线处理请求的过程，我将直接引用MSDN中的原文【IIS 5.0 和 6.0 的 ASP.NET 应用程序生命周期概述】中的片段。

在处理该请求时将由 HttpApplication 类执行以下事件。希望扩展 HttpApplication 类的开发人员尤其需要注意这些事件。
1. 对请求进行验证，将检查浏览器发送的信息，并确定其是否包含潜在恶意标记。有关更多信息，请参见 ValidateRequest 和脚本侵入概述。
2. 如果已在 Web.config 文件的 UrlMappingsSection 节中配置了任何 URL，则执行 URL 映射。
3. 引发 BeginRequest 事件。
4. 引发 AuthenticateRequest 事件。
5. 引发 PostAuthenticateRequest 事件。
6. 引发 AuthorizeRequest 事件。
7. 引发 PostAuthorizeRequest 事件。
8. 引发 ResolveRequestCache 事件。
9. 引发 PostResolveRequestCache 事件。
10. 根据所请求资源的文件扩展名（在应用程序的配置文件中映射），选择实现 IHttpHandler 的类，对请求进行处理。如果该请求针对从 Page 类派生的对象（页），并且需要对该页进行编译，则 ASP.NET 会在创建该页的实例之前对其进行编译。
11. 引发 PostMapRequestHandler 事件。
12. 引发 AcquireRequestState 事件。
13. 引发 PostAcquireRequestState 事件。
14. 引发 PreRequestHandlerExecute 事件。
15. 为该请求调用合适的 IHttpHandler 类的 ProcessRequest 方法（或异步版 IHttpAsyncHandler.BeginProcessRequest）。例如，如果该请求针对某页，则当前的页实例将处理该请求。
16. 引发 PostRequestHandlerExecute 事件。
17. 引发 ReleaseRequestState 事件。
18. 引发 PostReleaseRequestState 事件。
19. 如果定义了 Filter 属性，则执行响应筛选。
20. 引发 UpdateRequestCache 事件。
21. 引发 PostUpdateRequestCache 事件。
22. 引发 EndRequest 事件。
23. 引发 PreSendRequestHeaders 事件。
24. 引发 PreSendRequestContent 事件。

如果是IIS7，第10个事件也就是MapRequestHandler事件，而且在EndRequest 事件前，还增加了另二个事件：LogRequest 和 PostLogRequest 事件。
只有当应用程序在 IIS 7.0 集成模式下运行，并且与 .NET Framework 3.0 或更高版本一起运行时，才会支持 MapRequestHandler、LogRequest 和 PostLogRequest 事件。

这里要补充一下：从BeginRequest开始的事件，并不是每个事件都会被触发，因为在整个处理过程中，随时可以调用Response.End() 或者有未处理的异常发生而提前结束整个过程。在那些"知名"的事件中，也只有EndRequest事件是肯定会触发的， (部分Module的)BeginRequest有可能也不会被触发。

对于这些管线事件，我只想提醒2个非常重要的地方：
1. 每个请求都将会映射到一个HttpHandler，通常也是处理请求的主要对象。
2. HttpModule可以任意订阅这些事件，在事件处理器中也可以参与修改请求的操作。
这2点也决定了HttpHandler和HttpModule的工作方式。

我找了二张【老图片】，希望能更直观的说明Asp.net管线的处理过程。结合我前面讲述的内容，再品味一下老图片吧。

HttpHandler

HttpHandler通常是处理请求的核心对象。绝大多数的的请求都在【第10步】被映射到一个HttpHandler，然后在【第15步】中执行处理过程，因此也常把这类对象称为处理器或者处理程序。我们熟知的Page就是一个处理器，一个ashx文件也是一个处理器，不过ashx显示得更原始，我们还是来看一下ashx通常是个什么样子：

<%@ WebHandler Language="C#" Class="Login" %>

using System;
using System.Web;

public class Login : IHttpHandler {
        
    public void ProcessRequest (HttpContext context) {
        context.Response.ContentType = "text/plain";

        string username = context.Request.Form["name"];
        string password = context.Request.Form["password"];

        if( password == "aaaa" ) {
            System.Web.Security.FormsAuthentication.SetAuthCookie(username, false);
            context.Response.Write("OK");
        }
        else {
            context.Response.Write("用户名或密码不正确。");
        }
    }
 
    public bool IsReusable {
        get {
            return false;
        }
    }
}

可以看到它仅仅是实现一个IHttpHandler接口而已，IHttpHandler接口也很简单：

// 定义 ASP.NET 为使用自定义 HTTP 处理程序同步处理 HTTP Web 请求而实现的协定。
public interface IHttpHandler
{
    // 获取一个值，该值指示其他请求是否可以使用 System.Web.IHttpHandler 实例。
    //
    // 返回结果:
    //     如果 System.Web.IHttpHandler 实例可再次使用，则为 true；否则为 false。
    bool IsReusable { get; }

    // 通过实现 System.Web.IHttpHandler 接口的自定义 HttpHandler 启用 HTTP Web 请求的处理。
    void ProcessRequest(HttpContext context);
}

IsReusable属性上面有注释，我就不说了。接口中最重要的部分就是方法 void ProcessRequest(HttpContext context); 这个方法简单地不能再简单，只有一个参数，但这个参数的能量可不小，有了它几乎就有了一切，这就是我对它的评价。关于HttpContext的更多详细介绍请参考我的博客【我心目中的Asp.net核心对象】。

在Login.ashx中，我做了三简单的事：
1. 读取输入数据：从Request.Form中。
2. 执行特定的业务逻辑：一个简单的判断。
3. 返回结果给客户端：调用Response.Write()
是的，就是这三个简单的操作，但也是绝大多数ashx文件的常规写法，它的确可以完成一次请求的处理过程。
记住：事实上任何HttpHandler都是这样处理请求的，只是有时会借助一些框架的包装而变了味道而已。

本人认为：HttpHandler的强大离不开HttpContext，HttpHandler的重要性是因为管线会将每个请求都映射到一个HttpHandler。

通常，我们需要新的HttpHandler，创建一个ashx文件就可以了。但也可以创建自己的HttpHandler，或者要将一类【特殊的路径/扩展名】交给某个处理器来处理，那么就需要我们在web.config中注册那个处理器。
注意：如果是【特殊的扩展名】可能还需要在IIS中注册，原因很简单：IIS不将请求交给Asp.net，我们的代码根本没机会运行！

我们可以采用以下方式在web.config中注册一个自定义的处理器：

<httpHandlers>
    <add path="/MyService.axd" verb="*" validate="false" type="MySimpleServiceFramework.MyServiceHandler"/>
</httpHandlers>

或者：（为了排版，我将一些代码做了换行处理）

<httpHandlers>
    <remove verb="*" path="*.cs"/>
    <add verb="*" path="*.cs" validate="false" type="FishWebLib.Ajax.AjaxMethodV2Handler, 
			FishWebLib, Version=3.0.0.0, Culture=neutral, PublicKeyToken=04db02423b9ebbb2"/>

    <remove verb="*" path="*.ascx"/>
    <add verb="*" path="*.ascx" validate="false" type="FishWebLib.Ajax.UserControlHandler, 
			FishWebLib, Version=3.0.0.0, Culture=neutral, PublicKeyToken=04db02423b9ebbb2"/>
</httpHandlers>

HttpModule

前面我已经提到过HttpModule的工作方式：订阅管线事件，并在事件处理器中执行所需的相关操作。
这个描述看起来很平淡，但是，它的工作方式给了它无限强大的处理能力。

它的无限强大的处理能力来源于可以订阅管线事件，因此，它有能力可以在许多阶段修改请求，这些修改最终可能会影响请求的处理。
前面我说过：“HttpHandler是处理请求的主要对象”，但HttpModule却可以随意指定将某个请求交给某个处理器来执行！
甚至，HttpModule也可以直接处理请求，完全不给HttpHandler工作的机会！

我们来看一下HttpModule的实现方式：

/// <summary>
/// 能支持双向GZIP压缩的Module，它会根据客户端是否启用GZIP来自动处理。
/// 对于服务来说，不用关心GZIP处理，服务只要处理输入输出就可以了。
/// </summary>
internal class DuplexGzipModule : IHttpModule
{
    public void Init(HttpApplication app)
    {
        app.BeginRequest += new EventHandler(app_BeginRequest);
    }

    void app_BeginRequest(object sender, EventArgs e)
    {
        HttpApplication app = (HttpApplication)sender;

        // 注意：这里不能使用"Accept-Encoding"这个头，二者的意义完全不同。
        if( app.Request.Headers["Content-Encoding"] == "gzip" ) {
            app.Request.Filter = new GZipStream(app.Request.Filter, CompressionMode.Decompress);

            app.Response.Filter = new GZipStream(app.Response.Filter, CompressionMode.Compress);
            app.Response.AppendHeader("Content-Encoding", "gzip");
        }
    }

    public void Dispose()
    {
    }
}

每个HttpModule只需要实现IHttpModule接口就可以了。IHttpModule也是个简单的接口：

public interface IHttpModule
{
    void Dispose();

    void Init(HttpApplication app);
}

在这二个方法中，第一个方法通常可以保持为空。最重要的方法就是Init，它给了HttpModule能订阅管线事件的机会，然后在相应的事件处理中，我们就可以执行它的具体操作了。

还记得我在博客【我心目中的Asp.net核心对象】最后给出一个示例吗？在QueryOrderService.ashx中，为了支持gzip，需要直接调用GZipStream类，对于一二个ashx来说，或许不是问题，如果这样的处理器变多了，每个处理器都那样写，您能受得了吗？反正我是受不了的，因此今天我把它改成使用Module来实现，代码简单了许多。在本文末尾可以下载。

对于Asp.net项目来说：当您发现有很多处理输入输出的操作非常类似时，那正是HttpModule可以发挥的舞台，请把这些重复的操作交给它吧。

让HttpModule工作也需要在web.config中注册：

<httpModules>
    <add name="DuplexGzipModule" type="MySimpleServiceFramework.DuplexGzipModule"/>
</httpModules>

通常，我会把一些HttpModule放在类库中实现，然后在需要使用的项目的web.config中注册。
这也体现它的高重用性：写一次，许多项目就可以直接使用。

HttpModule的加载方式：前面我说过“Asp.net会为每个请求分配一个HttpApplication对象”，在每个HttpApplication对象的初始化操作中，它会加载所有在web.config中注册的HttpModule。由于Asp.net并不是只创建一个HttpApplication对象，而是多个HttpApplication对象，因此每个HttpModule的Init事件是有可能被多次调用的。许多人喜欢在这里做各类初始化的操作，那么请注意在这里修改静态变量成员时的线程安全问题。特别地，如果要执行程序初始化的操作，那么还是把代码放在Global.asax的Application_Start中去处理吧， HttpModule的Init事件并不合适。

为HttpModule选择订阅合适的管线事件：这是非常重要的，订阅不同的事件，产生的结果也会不一样。原因也很简单，在Asp.net运行环境中，并不只有一个HttpModule，某个HttpModule的判断可能要依据其它HttpModule的输出结果，而且在某些（晚期的）管线事件中，也不能再修改输出数据。在后面的示例中，DirectProcessRequestMoudle订阅了PostAuthorizeRequest事件，如果订阅BeginRequest事件或许将得到更好的性能，但是，在BeginRequest事件中，身份认证模块还没有工作，因此每个请求在这个事件阶段都属于“未登录”状态。

前面说了一大堆的HttpModule，事实上，在这个示例中，主角是另一个对象：Filter 。上篇博客我就提过它，最后为了演示它，把它放在一个HttpHandler里【糟蹋了】，没办法，上篇的主题不是管线呀。今天只好和HttpModule一起出场了。我认为Filter还是应该和HttpModule一起使用才能发挥它的独特价值。Filter的特点还真不合适在HttpHandler中使用，如果您在HttpHandler里使用Filter，我认为有必要考虑一下是不是用错了。

借HttpModule的地盘我们来谈谈Filter。Filter很低调，低调到什么程度：可能很少有人关注过它，因此也少有人用过它。事实也确实如此，一般情况下可以不用它，但用到它，你会发现它非常强大。前面我经常说到【输入输出流】，请求的数据，除了请求头以外，基本上全放在流中，如果您希望对这些数据以流的方式进行处理，特别是希望对于所有请求，或者某类请求，那么使用Filter是非常恰当的。前面的示例就是一个非常合理地使用，好好地品味它，或许您还能发现Filter能做更多的事情。

选 HttpHandler 还是 HttpModule ？

HttpHandler是每个请求的主要处理对象，而HttpModule可以选择请求交给哪个HttpHandler来处理，甚至，它还可以选择它自己来处理请求。
下面我给个示例代码来说明HttpModule也能直接请求：

/// <summary>
/// 此Module示范了直接使用Module也能处理客户端的请求。
/// 建议：除非要很好的理由，否则不建议使用这种方法。
/// </summary>
internal class DirectProcessRequestMoudle : IHttpModule
{
    public void Init(HttpApplication app)
    {
        app.PostAuthorizeRequest += new EventHandler(app_PostAuthorizeRequest);
    }

    void app_PostAuthorizeRequest(object sender, EventArgs e)
    {
        HttpApplication app = (HttpApplication)sender;

        ServiceInfo info = GetServiceInfo(app.Context);
        if( info == null )
            return;

        ServiceExecutor.ProcessRequest(app.Context, info);
        app.Response.End();
    }

为了更好的回答本节的这个问题，我再给段等效的代码，不过，请求是经过HttpHandler来处理

internal class MyServiceHandler : IHttpHandler
{
    internal ServiceInfo ServiceInfo { get; set; }

    public void ProcessRequest(HttpContext context)
    {
        ServiceInfo info = this.ServiceInfo ?? GetServiceInfo(context);

        ServiceExecutor.ProcessRequest(context, info);
    }

HttpHandler和HttpModule都能处理请求，我该选哪个？？

对于此类情况，我的答案是：视情况而定，正如我在注释中描述的那样，除非要很好的理由，否则不建议使用HttpModule处理请求。 用HttpModule在某些时候可能会快点，关键点在于处理完成时要调用Response.End();这会让后面的事件全都短路，其它的HttpModule就没有机会执行。如果您的框架或者项目设计很依赖于管线中的事件处理，那么调用Response.End();无疑会破坏这个规则，也将会导致不能得到正确的结果。选择HttpHandler就不会有这种事情发生。

不过，也没有绝对的事情：在请求处理期间，您可以在任何地方调用Response.End(); 结果也是一样的。

幸好，短路的情况并不经常发生，因此选择HttpHandler会让整个Asp.net的管线都能发挥作用，因此，我建议优先选择HttpHandler。
尤其是在HttpHandler能很好的完成工作的前提下，就应该选HttpHandler，因为选HttpModule会给其它请求带来不必要的性能损失，具体细节请继续阅读。

其实，我们还可以从另一个角度来看这个问题。
首先，请仔细地阅读前面的示例代码，您是否发现它们在实现方式上非常类似？
现在应该找到答案了吧：把具体的处理操作分离到HttpHandler，HttpModule之外的地方。那么，此时这个问题也就不是问题了，您也可以提供多种方案供使用者选择。比如：我就为【我的服务框架】提供了5种方式让使用者可以轻松地将一个C#方法公开为一个服务方法，该如何选择这个问题，由使用者来决定，这个问题不会让我为难。

本人观点：在没有太多技术难度的前提下，提供多种解决办法应该是对的，您将会避开很多麻烦事情。

看不见的性能问题

前面我介绍了HttpModule的重要优点：高重用性。只要写好一个HttpModule可以放在任何Asp.net项目中使用，非常方便。

不过，再好的东西也不能滥用。HttpModule也可以对性能产生负面影响。原因也很简单：对于每个Asp.net请求，每个HttpModule都会在它们所订阅的事件中，去执行一些操作逻辑。这些操作逻辑或许对一些请求是无意义的，但仍会执行。因此，计算机将会白白浪费一些资源去执行一些无意义的代码。

知道了原因，解决办法也就很清楚了：
1. 去掉不需要的HttpModule
2. 在每个HttpModule的事件处理器中，首先要确定是不是自己所需要处理的请求。对一些不相关的请求，应该立即退出。

在我们创建一个Asp.net项目时，如果不做任何修改，微软已经为我们加载了好多HttpModule 。请看以下代码：

protected void Page_Load(object sender, EventArgs e)
{
    HttpApplication app = HttpContext.Current.ApplicationInstance;        
    StringBuilder sb = new StringBuilder();

    foreach( string module in app.Modules.AllKeys ) 
        sb.AppendFormat(module).Append("<br />");

    Response.Write(sb.ToString());
}

输出结果如下：

总共有14个。
哎，大多数是我肯定不会用到的，但它们却被加载了，因此，在它们所订阅的事件中，它们的代码将会检查所有的请求，那些无意义的代码将有机会执行。如果您不想视而不见，那么请在web.config中做类似的修改，将不需要的Module移除。

<httpModules>
    <remove name="Session"/>
    <remove name="RoleManager"/>
</httpModules>

HttpModule的第2个需要注意的地方是：HttpModule对所有的请求有效，如果HttpModule不能处理所有的请求，那么请先判断当前请求是否需要处理，对于不需要处理的请求，应该立即退出。请看以下示例代码：

/// <summary>
/// 【演示用】让Aspx页的请求支持gzip压缩输出
/// </summary>
public class FishGzipModule : IHttpModule
{
    public void Init(HttpApplication app)
    {
        app.BeginRequest += new EventHandler(app_BeginRequest);
    }

    void app_BeginRequest(object sender, EventArgs e)
    {
        HttpApplication app = (HttpApplication)sender;

        // 这里做个简单的演示，只处理aspx页面的输出压缩。
        // 当然了，IIS也提供压缩功能，这里也仅当演示用，或许可适用于一些特殊场合。
        if( app.Request.AppRelativeCurrentExecutionFilePath.EndsWith(
                            "aspx", StringComparison.OrdinalIgnoreCase) == false )
            // 注意：先判断是不是要处理的请求，如果不是，直接退出。
            //        而不是：先执行了后面的判断，再发现不是aspx时才退出。
            return;


        string flag = app.Request.Headers["Accept-Encoding"];
        if( string.IsNullOrEmpty(flag) == false && flag.ToLower().IndexOf("gzip") >= 0 ) {
            app.Response.Filter = new GZipStream(app.Response.Filter, CompressionMode.Compress);
            app.Response.AppendHeader("Content-Encoding", "gzip");
        }
    }

更多实战介绍

本文从这里起，将不再过多的叙述一些理论文字，而是将以实战的形式展示Asp.net的强大管线功能，这些实战展示了一些很经典的应用场景，其中大部分示例代码将做为【我的服务框架】的关键部分。因此请注意理解这些代码。

实战代码大量使用了上篇博客【我心目中的Asp.net核心对象】所介绍的绝大多数对象，也算是再次展示那些核心对象的重要性，因此请务必先了解那些核心对象。

上篇博客仅展示了那些强大对象的功能，单独使用它们，也是不现实的，今天，我将演示它们与HttpHandler, HttpModule一起并肩工作所能完成的各种任务。

故事未讲完，传奇在继续。更多精彩即将上演！

实战演示 - 模拟更多的HttpMethod

近几年又有一种被称为RESTful Web服务的概念进入开发人员的视野，它提倡使用HTTP协议提供的GET、POST、PUT和DELETE方法来操作网络资源。不过，目前的浏览器只支持GET、POST这二种方法，因此就有人想到采用HTTP头，表单值，或者查询字符串的形式来模拟这些浏览器不支持的HTTP方法。每种支持RESTful Web服务的框架都有它们自己的实现方式，今天我将使用HttpModule也来模拟这个操作。最终的结果是可以直接访问HttpRequest.HttpMethod获取这些操作的方法名字。

实现原理：订阅管线中的BeginRequest事件，检查当前请求是否需要修改HttpMethod，如果是，则修改HttpMethod属性。
所以选择BeginRequest这个事件，是因为这个事件比较早，可以让请求的后续阶段都能读到新的结果。

/// <summary>
/// 【演示用】实现了模拟更多 HttpMethod 的Module
/// </summary>
internal class XHttpMethodModule : IHttpModule
{
    private FieldInfo _field;

    public void Init(HttpApplication context)
    {
        // 订阅这个较早的事件，可以让请求的后续阶段都能读到新的结果。
        context.BeginRequest += new EventHandler(context_BeginRequest);
        _field = typeof(HttpRequest).GetField("_httpMethod", BindingFlags.Instance | BindingFlags.NonPublic);
    }

    void context_BeginRequest(object sender, EventArgs e)
    {
        HttpApplication app = (HttpApplication)sender;

        // 这里仅检查是否为POST操作，如果您的应用中需要使用GET来模拟的，请修改这里。
        if( string.Equals(app.Request.HttpMethod, "POST", StringComparison.OrdinalIgnoreCase) ) {

            // 这里为了简单，我只检查请求头，如果还需要检查表单值或者查询字符串，请修改这里。
            string headerOverrideValue = app.Request.Headers["X-HTTP-Method-Override"];

            if( string.IsNullOrEmpty(headerOverrideValue) == false ) {
                if( string.Equals(headerOverrideValue, "GET", StringComparison.OrdinalIgnoreCase) == false &&
                    string.Equals(headerOverrideValue, "POST", StringComparison.OrdinalIgnoreCase) == false ) {

                    // HttpRequest.HttpMethod属性其实就是访问_httpMethod这个私有字段，我将直接修改它。
                    // 这样修改后，最原始的HTTP方法就丢失，通常这或许也是可以接受的。
                    _field.SetValue(app.Request, headerOverrideValue.ToUpper());
                }
            }
        }
    }

我认为采用HttpModule来处理这个问题是个不错的选择。它至少有2个好处：
1. 这个HttpModule能继续给其它的网站项目使用，因此提高了代码的重用性。
2. 我可以随时决定要不要支持模拟，不需要模拟时，从web.config中不加载它就可以了，因此切换很灵活，且不需要修改现有代码。

来看一下页面及调用结果吧

protected void Page_Load(object sender, EventArgs e)
{
    Response.Write(Request.HttpMethod);
}

调用结果如下：

实战演示 - URL重写

使用HttpModule来实现URL重写。这个功能应该是HttpModule非常经典的应用了。

通常情况下，这种应用常用的方式是将一个URL： /product/12 重写为 /product.aspx?id=12 ，此时product.aspx应该是一个已经已存在的页面。显然重写后的地址更友好。URL重写的目的就是能让URL更友好。

实现原理：订阅管线的PostAuthorizeRequest事件，检查URL是不是期望修改的模式，如果是，则调用Context.RewritePath()完成URL的重写操作。在管线的后续处理中，最终会使用新的URL来映射到一个合适的HttpHandler。说明：选择的事件只要在【第10个事件】之前就可以了，因为在第10个事件前重写URL，才能保证到将请求映射到合适的处理器来执行。就这么简单，请参考以下代码：

public class MyServiceUrlRewriteModule : IHttpModule
{
    // 为了演示简单，直接写死地址。
    // 注意：MyService.axd 必须在web.config中注册，以保证它能成功映射。
    public static string RewriteUrlPattern = "/MyService.axd?sc={1}&op={1}";

    public void Init(HttpApplication app)
    {
        app.PostAuthorizeRequest += new EventHandler(app_PostAuthorizeRequest);
    }

    void app_PostAuthorizeRequest(object sender, EventArgs e)
    {
        HttpApplication app = (HttpApplication)sender;

        // 这里将检查URL是否为需要重写的模式，比如:
        //   http://localhost:11647/service/OrderService/QueryOrder
        NamesPair pair = FrameworkRules.ParseNamesPair(app.Request);
        if( pair == null )
            return;

        // 开始重写URL，最后将会映射到MyServiceHandler
        int p = app.Request.Path.IndexOf('?');
        if( p > 0 )
            app.Context.RewritePath(string.Format(RewriteUrlPattern, pair.ServiceName, pair.MethodName)
                + "&" + app.Request.Path.Substring(p + 1)
                );
        else
            app.Context.RewritePath(string.Format(RewriteUrlPattern, pair.ServiceName, pair.MethodName));
    }

重写发生了什么？
对于一个传入请求：http://localhost:11647/service/FormDemoService/ShowUrlInfo
它将被重写为：http://localhost:11647/MyService.axd?sc=FormDemoService&op=ShowUrlInfo
由于在web.config中，对MyService.axd已做过注册，因此Asp.net会将请求转交给注册的处理器来处理它。

注意：URL重写，会影响某些变量的值。请参考以下代码，我将写个服务方法来检测这个现象：

[MyServiceMethod]
public string ShowUrlInfo(int a)
{
    System.Web.HttpRequest request = System.Web.HttpContext.Current.Request;

    System.Text.StringBuilder sb = new System.Text.StringBuilder();
    sb.AppendFormat("Path: {0}\r\n", request.Path);            
    sb.AppendFormat("RawUrl: {0}\r\n", request.RawUrl);
    sb.AppendFormat("Url.PathAndQuery: {0}\r\n", request.Url.PathAndQuery);

    return sb.ToString();
}

输出结果：

实战演示 - URL路由

使用HttpModule来实现URL路由。这个功能随着Asp.net MVC框架的出现也逐渐流行起来了。

URL路由的目标也是为了使用URL更友好，与URL重写类似。

实现原理：订阅管线的PostResolveRequestCache事件，检查URL是不是期望的路由模式，如果是，则要根据请求中所包含的信息找到一个合适的处理器，并临时保存这个处理器，重写URL到一个Asp.net能映射处理器的地址。在管线的PostMapRequestHandler中，检查前面有没有临时保存的处理器，如果有，则重新给Context.Handler赋值，并重写URL到原始地址。在管线的后续处理中，最终会使用Context.Handler的HttpHandler。就这么简单，请参考以下代码：

public class MyServiceUrlRoutingModule : IHttpModule
{
    private static readonly object s_dataKey = new object();

    public void Init(HttpApplication app)
    {
        app.PostResolveRequestCache += new EventHandler(app_PostResolveRequestCache);
        app.PostMapRequestHandler += new EventHandler(app_PostMapRequestHandler);
    }

    private void app_PostResolveRequestCache(object sender, EventArgs e)
    {
        HttpApplication app = (HttpApplication)sender;

        // 获取合适的处理器，注意这是与URL重写的根本差别。
        // 即：根据当前请求【主动】寻找一个处理器，而不是使用RewritePath让Asp.net替我们去找。
        MyServiceHandler handler = GetHandler(app.Context);
        if( handler == null )
            return;

        // 临时保存前面获取到的处理器，这个值将在PostMapRequestHandler事件中再取出来。
        app.Context.Items[s_dataKey] = handler;

        // 进入正常的MapRequestHandler事件，随便映射到一个处理器就行了。
        app.Context.RewritePath("~/MyServiceUrlRoutingModule.axd");
    }

    private void app_PostMapRequestHandler(object sender, EventArgs e)
    {
        HttpApplication app = (HttpApplication)sender;

        // 取出在PostResolveRequestCache事件中获得的处理器
        MyServiceHandler handler = (MyServiceHandler)app.Context.Items[s_dataKey];
        if( handler != null ) {
            // 还原URL请求地址。注意这里和URL重写的差别。
            app.Context.RewritePath(app.Request.RawUrl);

            // 还原根据GetHandler(app.Context)调用得到的处理器。
            // 因为此时app.Context.Handler是由"~/MyServiceUrlRoutingModule.axd"映射得到的。
            app.Context.Handler = handler;
        }
    }

注意：在MyServiceUrlRoutingModule中，我将请求【路由】到一个MyServiceHandler的实例，而不是让Asp.net根据URL来替我选择。

在URL重写的演示中，有些URL相关的属性发生了改变，我们再来看一下URL路由是个什么结果：

实现自己的服务框架

本篇博客在开头说过：将在本次博客中改进上次的服务实现，让它成为一个真正能用的服务框架。
前面在讲述Asp.net管线时，给出了很多示例代码，这些示例代码都可以在博客的结尾处下载到。这些代码来源于【我的服务框架】中的部分源代码，下面我将重点介绍【我的服务框架】。

利用【我的服务框架】将类公开成服务

在【我的服务框架】中，一个类要想公开为服务类，并不需要继承某个类或者实现什么接口，只需要在类上加一个特性就好了，方法也只需加一个特性，示例代码如下：

[MyService]
public class OrderService
{
    [MyServiceMethod]
    public static string Hello(string name)
    {
        return "Hello " + name;
    }

    [MyServiceMethod]
    public List<Order> QueryOrder(QueryOrderCondition query)
    {
        // 模拟查询过程，这里就直接返回一个列表。        
        List<Order> list = new List<Order>();
        for( int i = 0; i < 10; i++ )
            list.Add(DataFactory.CreateRandomOrder());

        return list;
    }

    public string HiddenMethod(string aa)
    {
        // 这个方法应该是不能以服务方式被调用到的。
        throw new NotImplementedException();
    }
}

如果某个方法需要只公开给登录用户或者指定的用户，还可以使用以下方式：

// 这是一个访问受限的服务类，只允许某些用户调用。
[Authorize]
[MyService]
public static class LimitService
{
    [Authorize(Users="fish-li, cc")]
    [MyServiceMethod]
    public static string CalcPassword(string pwd)
    {
        // 这个方法只能由 fish-li, cc 二个用户来调用

        if( pwd == null )
            pwd = string.Empty;

        byte[] buffer = (new MD5CryptoServiceProvider()).ComputeHash(Encoding.Default.GetBytes(pwd));
        return BitConverter.ToString(buffer).Replace("-", "");
    }

    [MyServiceMethod]
    public static string CalcBase64(string str)
    {
        // 这个方法只能由已登录用户调用。

        if( string.IsNullOrEmpty(str) )
            return string.Empty;

        return Convert.ToBase64String(Encoding.UTF8.GetBytes(str));
    }
}

就这么简单，一个类，就可以成为一个服务。
说明：本框架并不要求将服务类在网站项目中实现，完全可以放在类库中实现。

还可以支持Session哦。

[MyService(SessionMode=SessionMode.Support)]
public class SessionDemoService 
{
    [MyServiceMethod]
    public int Add(int a)
    {
        // 一个累加的方法，检验是否可以访问Session

        if( System.Web.HttpContext.Current.Session == null )
            throw new InvalidOperationException("Session没有开启。");

        object obj = System.Web.HttpContext.Current.Session["counter"];
        int counter = (obj == null ? 0 : (int)obj);
        counter += a;
        System.Web.HttpContext.Current.Session["counter"] = counter;
        return counter;
    }
}

SessionMode的定义如下：

public enum SessionMode
{
    NotSupport,
    Support,
    ReadOnly
}

【我的服务框架】支持的序列化的种类

在上篇博客中，我演示了使用JSON序列化的做法来实现一个服务响应。本来也是打算让框架仅支持JSON序列化的，因为传输的数据量小嘛。没想到，做到后来，还是认为有必要把XML序列化也加进来，XML序列化快呀。最后，居然想到既然是服务框架，Ajax调用也能算是服务吧，总不能不支持吧，后来干脆也能支持部分的Ajax调用了。

在【我的服务框架】中，服务端判断客户端发送的数据序列化方式是通过判断请求头"Serializer-Format"来实现的。序列化的种类还允许继续自定义。只要实现以下接口：

public interface ISerializerProvider
{
    object Deserialize(Type destType, HttpRequest request);

    void Serializer(object obj, HttpResponse response);
}

然后调用以下方法就可以了：

public static class SerializerProviderFactory
{
    public static void RegisterSerializerProvider(string name, Type type)
    {
        // ...................................
    }

判断客户端的序列化方式，由属性FrameworkRules.GetSerializerFormat来决定：

public static class FrameworkRules
{
    private static string Internal_GetSerializerFormat(HttpRequest request){
        string flag = request.Headers["Serializer-Format"];
        return (string.IsNullOrEmpty(flag) ? "form" : flag);
    }

    private static Func<HttpRequest, string> _serializerFormatRule = Internal_GetSerializerFormat;

    /// <summary>
    /// 此委托用来判断客户端发起的请求中，数据是以什么方式序列化的。
    /// 返回的结果将会交给SerializerProviderFactory.GetSerializerProvider()来获取序列化提供者
    /// 默认的实现是检查请求头："Serializer-Format"
    /// </summary>
    public static Func<HttpRequest, string> GetSerializerFormat
    {
        internal get { return _serializerFormatRule; }
        set
        {
            if( value == null )
                throw new ArgumentNullException("value");
            _serializerFormatRule = value;
        }
    }

只是一个委托，可以自己重新实现。

目前本框架提供了三个实现了接口ISerializerProvider的类供用户使用：JsonSerializerProvider, XmlSerializerProvider, FormSerializerProvider

这里只展示JsonSerializerProvider的实现：

internal class JsonSerializerProvider : ISerializerProvider
{
    private static readonly MethodInfo s_JSSDeserializeMI
                                = typeof(JavaScriptSerializer).GetMethod("Deserialize");

    JavaScriptSerializer jss = new JavaScriptSerializer();

    public object Deserialize(Type destType, HttpRequest request)
    {
        StreamReader sr = new StreamReader(request.InputStream, request.ContentEncoding);
        string input = sr.ReadToEnd();

        MethodInfo deserialize = s_JSSDeserializeMI.MakeGenericMethod(destType);

        return deserialize.Invoke(jss, new object[] { input });
    }

    public void Serializer(object obj, HttpResponse response)
    {
        if( obj == null )
            return;

        response.ContentType = "application/json";

        response.Write(jss.Serialize(obj));
    }

注意：FormSerializerProvider的实现不够完善，因为再搞下去，就和【我的WEB框架】就重复了。有兴趣的自己去完善吧。

这里再给自己的作品打个广告：
【Asp.net MVC 框架，我也来山寨一下】，【晒晒我的Ajax服务端框架】，【我的Ajax服务端框架 - (1) JS直接调用C#方法】

【我的服务框架】对gzip的支持

对于gzip的支持，我只想说：太简单了。
前面不是已给出DuplexGzipModule的实现代码嘛。是的，就是把它注册到web.config中就可以了。
你说简不简单？完全不用写多余的代码，要不要gzip支持，也只是个配置问题！

说到这里，我想起前段时间Artech写的一篇博客通过WCF扩展实现消息压缩，正如我在前篇博客的回复中说到的：“本来真没兴趣看的，不过，为了验证我的猜想，还是去看了一下，果然也没让我失望。”。

在此，有必要公开一下我的想法：绝对没有半点看不起Artech的意思，只是我对WCF没有兴趣了。理由也简单：不够简单。

还是接着说，Artech的博客展示了在WCF中压缩消息的方式，当然我相信Artech对于WCF的理解，他的方案或许应该是最简单的解决方案，但是和【我的服务框架】对gzip的支持的易用性根本没法比。

WCF的粉丝们，当您看到这里，请先别忙着喷我。听我说完：WCF的确很强大，我的这个不到700行的框架那也是根本不能和它相比的。

做这个比较仅仅是为了展示Asp.net是一个强大的平台，Asp.net有更高水准的扩展性。

利用【我的服务框架】发布服务的5种方式

【我的服务框架】可以提供5种不同的方式，让您将一个类及方法公开成一个服务，供外界调用。

方法1：使用DirectProcessRequestMoudle，只需要配置web.config即可。

<httpModules>
    <add name="DirectProcessRequestMoudle" type="MySimpleServiceFramework.DirectProcessRequestMoudle"/>
</httpModules>

客户端调用URL：http://localhost:11647/service/OrderService/QueryOrder

说明：URL模式是可以自由定义的，只要给FrameworkRules.ParseNamesPair赋值即可，它的定义如下：

public static Func<HttpRequest, NamesPair> ParseNamesPair

默认的实现方式：

internal static class UrlPatternHelper
{
    // 为了演示简单，我只定义一个URL模式。【因为我认为对于服务来说，一个就够了】
    // 如果希望适用性更广，可以从配置文件中读取，并且可支持多组URL模式。
    // URL中加了"/service/"只是为了能更好地区分其它请求，如果您的网站没有子目录，删除它也是可以的。
    private static readonly string UrlPattern = @"/service/(?<name>[^/]+)/(?<method>[^/]+)[/\?]?";

    public static NamesPair ParseNamesPair(HttpRequest request)
    {
        if( request == null )
            throw new ArgumentNullException("request");

        MatchCollection matchs = Regex.Matches(request.Path, UrlPattern);
        if( matchs.Count != 1 )
            return null;

        Match m = matchs[0];
        return new NamesPair {
            ServiceName =  m.Result("${name}"),
            MethodName = m.Result("${method}")
        };
    }

客户端调用URL： http://localhost:11647/service/OrderService/QueryOrder

方法2：使用MyServiceUrlRoutingModule，只需要配置web.config即可。

<httpModules>
    <add name="MyServiceUrlRoutingModule" type="MySimpleServiceFramework.MyServiceUrlRoutingModule"/>
</httpModules>

客户端调用URL： http://localhost:11647/service/OrderService/QueryOrder

说明：只有这种方式才能支持Session

方法3：使用MyServiceUrlRewriteModule，只需要配置web.config即可。

<httpHandlers>
    <add path="/MyService.axd" verb="*" validate="false" type="MySimpleServiceFramework.MyServiceHandler"/>
</httpHandlers>
<httpModules>
    <add name="MyServiceUrlRewriteModule" type="MySimpleServiceFramework.MyServiceUrlRewriteModule"/>
</httpModules>

客户端调用URL： http://localhost:11647/service/OrderService/QueryOrder

方法4：使用MyServiceHandler，只需要配置web.config即可。

<httpHandlers>
    <add path="/MyService.axd" verb="*" validate="false" type="MySimpleServiceFramework.MyServiceHandler"/>
</httpHandlers>

客户端调用URL： http://localhost:11647/MyService.axd?sc=OrderService&op=QueryOrder

方法5：创建一个ashx，不需要任何配置。

<%@ WebHandler Language="C#" Class="MyService" %>

using System;
using System.Web;
using MySimpleServiceFramework;

public class MyService : IHttpHandler {
    
    public void ProcessRequest (HttpContext context) {
        NamesPair pair = new NamesPair();
        pair.ServiceName = context.Request.QueryString["sc"];
        pair.MethodName = context.Request.QueryString["op"];

        ServiceExecutor.ProcessRequest(context, pair);
    }
 
    public bool IsReusable {
        get {
            return false;
        }
    }
}

客户端调用URL： http://localhost:11647/MyService.ashx?sc=OrderService&op=QueryOrder

注意：前三种方法，需要在IIS中做些额外的配置，因为URL中不包含文件扩展名了，IIS不知道把请求交给Asp.net来处理。
具体配置见下图，此处省略78个字。

我对发布服务的5种方式的建议

虽然，我给出了5种发布方式，但是我还是想说说我个人的想法。

在这些方法中，使用URL重写，URL路由的方法，并不是我想推荐的，写它们是主要是为了展示HttpModule 。不推荐它们是因为它们要判断URL是否符合指定模式，这个判断是有成本的。至于成本有多高，特此，我专了做门的测试。在示例代码压缩包中有个___TestRoutePerformance目录，结果如何，还是您自己去看吧，我也有点累了。

此外，我想问：对于服务来说，URL友好有多大意义？服务的URL会让用户来输入还是让Google的爬虫来访问？

如果以上二个问题都是否定的，那么，这二种方法就是在白白浪费机器的性能了。
当然了，如果您的站点访问量不大，那么这点性能也可以忽略不计了，就当我没说。

使用URL重写URL路由，还有个比较麻烦的事情：如果想通过URL多传递一个参数，那么，是不是又要修改URL模式？

对于使用DirectProcessRequestMoudle这种模式，我以前已经说过了：除非要很好的理由，否则不建议使用这种方法。

至于其它的二种方式，本质上是一样的，只是说：处理器谁来写的差别了。
不过，如果您要是选择手工创建一个处理器，除了不用修改web.config之外，还可以自定义URL参数名，可以选择要不要支持Session

【我的服务框架】的一些核心类

ReflectionHelper类用于根据类名及服务名定位到一个服务类型以及要调用的方法。
因此，它在框架中的作用也是非常关键的。

internal static class ReflectionHelper
{
    private static List<TypeAndAttrInfo> s_typeList;

    static ReflectionHelper()
    {
        InitServiceTypes();
    }

    /// <summary>
    /// 加载所有的服务类型，判断方式就是检查类型是否有MyServiceAttribute
    /// </summary>
    private static void InitServiceTypes()
    {
        s_typeList = new List<TypeAndAttrInfo>(256);

        ICollection assemblies = BuildManager.GetReferencedAssemblies();
        foreach( Assembly assembly in assemblies ) {
            try {
                (from t in assembly.GetExportedTypes()
                 let a = (MyServiceAttribute[])t.GetCustomAttributes(typeof(MyServiceAttribute), false)
                 where a.Length > 0
                 select new TypeAndAttrInfo { 
                            ServiceType = t, Attr = a[0], AuthorizeAttr = t.GetClassAuthorizeAttribute() }
                 ).ToList().ForEach(b => s_typeList.Add(b));
            }
            catch { }
        }
    }

    private static AuthorizeAttribute GetClassAuthorizeAttribute(this Type t)
    {
        AuthorizeAttribute[] attrs = (AuthorizeAttribute[])t.GetCustomAttributes(typeof(AuthorizeAttribute), false);
        return (attrs.Length > 0 ? attrs[0] : null);
    }

    /// <summary>
    /// 根据一个名称获取对应的服务类型（从缓存中获取类型）
    /// </summary>
    /// <param name="typeName"></param>
    /// <returns></returns>
    private static TypeAndAttrInfo GetServiceType(string typeName)
    {
        if( string.IsNullOrEmpty(typeName) )
            throw new ArgumentNullException("typeName");


        // 查找类型的方式：如果有点号，则按全名来查找(包含命名空间)，否则只看名字。
        // 本框架对于多个匹配条件的类型，将返回第一个匹配项。
        if( typeName.IndexOf('.') > 0 )
            return s_typeList.FirstOrDefault(t => string.Compare(t.ServiceType.FullName, typeName, true) == 0);
        else
            return s_typeList.FirstOrDefault(t => string.Compare(t.ServiceType.Name, typeName, true) == 0);
    }
    
    

    private static Hashtable s_methodTable = Hashtable.Synchronized(
                                        new Hashtable(4096, StringComparer.OrdinalIgnoreCase));

    /// <summary>
    /// 根据指定的类型以及方法名称，获取对应的方法信息
    /// </summary>
    /// <param name="type"></param>
    /// <param name="methodName"></param>
    /// <returns></returns>
    private static MethodAndAttrInfo GetServiceMethod(Type type, string methodName)
    {
        if( type == null )
            throw new ArgumentNullException("type");
        if( string.IsNullOrEmpty(methodName))
            throw new ArgumentNullException("methodName");

        // 首先尝试从缓存中读取
        string key = methodName + "@" + type.FullName;
        MethodAndAttrInfo mi = (MethodAndAttrInfo)s_methodTable[key];

        if( mi == null ) {
            // 注意：这里不考虑方法的重载。
            MethodInfo method = type.GetMethod(methodName,
                     BindingFlags.Static | BindingFlags.Instance | BindingFlags.Public | BindingFlags.IgnoreCase);

            if( method == null )
                return null;

            MyServiceMethodAttribute[] attrs = (MyServiceMethodAttribute[])
                                        method.GetCustomAttributes(typeof(MyServiceMethodAttribute), false);
            if( attrs.Length != 1 )
                return null;


            // 由于服务方法的参数来源于反序列化，此时只可能包含一个参数。
            ParameterInfo[] paraInfos = method.GetParameters();
            if( paraInfos.Length != 1 )
                throw new ArgumentNullException("指定的方法虽找到，但该方法的参数数量不是1");

            AuthorizeAttribute[] auths = (AuthorizeAttribute[])method.GetCustomAttributes(typeof(AuthorizeAttribute), false);

            mi = new MethodAndAttrInfo {
                        MethodInfo = method,
                        ParamType = paraInfos[0].ParameterType,
                        Attr = attrs[0],
                        AuthorizeAttr = (auths.Length > 0 ? auths[0] : null)
            };

            s_methodTable[key] = mi;
        }

        return mi;            
    }


    /// <summary>
    /// 根据类型名称以及方法名称返回要调用的相关信息
    /// </summary>
    /// <param name="pair">包含类型名称以及方法名称的对象</param>
    /// <returns></returns>
    public static InvokeInfo GetInvokeInfo(NamesPair pair)
    {
        if( pair == null )
            throw new ArgumentNullException("pair");

        InvokeInfo vkInfo = new InvokeInfo();

        vkInfo.ServiceTypeInfo = GetServiceType(pair.ServiceName);
        if( vkInfo.ServiceTypeInfo == null )
            return null;

        vkInfo.MethodAttrInfo = GetServiceMethod(vkInfo.ServiceTypeInfo.ServiceType, pair.MethodName);
        if( vkInfo.MethodAttrInfo == null )
            return null;


        if( vkInfo.MethodAttrInfo.MethodInfo.IsStatic == false )
            vkInfo.ServiceInstance = Activator.CreateInstance(vkInfo.ServiceTypeInfo.ServiceType);


        return vkInfo;
    }

}

ServiceExecutor用于调用服务方法，前面所说的5种服务发布方式，最终都要经过这里。

/// <summary>
/// 最终调用服务方法的工具类。
/// </summary>
public static class ServiceExecutor
{
    internal static void ProcessRequest(HttpContext context, ServiceInfo info)
    {
        if( context == null )
            throw new ArgumentNullException("context");
        if( info == null || info.InvokeInfo == null )
            throw new ArgumentNullException("info");

        //if( context.Request.InputStream.Length == 0 )
        //    throw new InvalidDataException("没有调用数据，请将调用数据以请求体的方式传入。");
        
        if( info.InvokeInfo.AuthenticateRequest(context) == false )
            ExceptionHelper.Throw403Exception(context);
        
        // 获取客户端的数据序列化格式。    
        //   默认实现方式：request.Headers["Serializer-Format"];
        //   注意：这是我自定义的请求头名称，也可以不指定，默认为：form (表单)
        string serializerFormat = FrameworkRules.GetSerializerFormat(context.Request);

        ISerializerProvider serializerProvider =
                    SerializerProviderFactory.GetSerializerProvider(serializerFormat);

        // 获取要调用方法的参数类型
        Type destType = info.InvokeInfo.MethodAttrInfo.ParamType;

        // 获取要调用的参数
        context.Request.InputStream.Position = 0;    // 防止其它Module读取过，但没有归位。
        object param = serializerProvider.Deserialize(destType, context.Request);
        
        // 调用服务方法
        object result = info.InvokeInfo.MethodAttrInfo.MethodInfo.Invoke(
                                info.InvokeInfo.ServiceInstance, new object[] { param });

        // 写输出结果
        if( result != null )
            serializerProvider.Serializer(result, context.Response);
    }

    /// <summary>
    /// 【外部接口】用于根据服务的类名和方法名执行某个请求
    /// </summary>
    /// <param name="context"></param>
    /// <param name="pair"></param>
    public static void ProcessRequest(HttpContext context, NamesPair pair)
    {
        if( pair == null )
            throw new ArgumentNullException("pair");

        if( string.IsNullOrEmpty(pair.ServiceName) || string.IsNullOrEmpty(pair.MethodName) )
            ExceptionHelper.Throw404Exception(context);


        InvokeInfo vkInfo = ReflectionHelper.GetInvokeInfo(pair);
        if( vkInfo == null )
            ExceptionHelper.Throw404Exception(context);

        ServiceInfo info = new ServiceInfo(pair, vkInfo);

        ProcessRequest(context, info);
    }        
}

关于写框架

以前曾在网上见过几次关于“重复造轮子”的说法。基本上，全是反对意见。

我今天也想谈谈这个话题：要不要自己写框架？

我的答案是：要。

自己写框架的好处不在于能将它做得多强大，多完美，而是从写框架的过程中，可以学到很多东西。

一个框架写完了，不在乎要给多少人使用，而是自己感觉有没有进步，这才是关键。

如果您不重复造轮子，可能永远不知道造轮子的过程，造轮子需要什么内容。

如果不重复造轮子，世界上将只有一个操作系统。
如果不重复造轮子，世界上将只有一个数据库。
如果不重复造轮子，世界上将只有一种编程语言。
这样单调会很好吗？

WebForms, MVC, Linq To SQL, Entity Framework, Remoting, Web Service, WCF
微软不也是一直在重复造轮子吗？

结束语

终于写完了这篇博客。这篇博客花了我最多的写作时间：整整二个周末还加上一些业余时间。
当然了，其中也包括实现框架的时间。这其实也是希望更好地展示Asp.net的核心内容。
写框架不是目标，展示Asp.net技术，写博客才是目标哦。

因此，这篇博客可谓是【下足了料】，只希望：
1. 能给大家分享Asp.net的核心内容。
2. 这篇博客的成绩能赶上【细说Cookie】。
我的写博热情也离不开您的肯定支持哦，如果您认为阅读此文有收获，别忘了点一下右下角的【推荐】，【关注 Fish Li】。

Asp.net是个伟大的平台，能完成许多应用。这些应用的实现离不开这二次博客所提过的核心对象的支持，
本来还想再写点其它的示例，只是时间花得太多了。今天的示例已经很精彩了，到此为止吧，我也想休息了。

每个对象都是一个不朽的传奇，每个传奇背后都有一个精彩的故事。
我是Fish Li, 感谢大家阅读我的博客，请继续关注我的后续博客。

本文链接

给页面加速，干掉Dom Level 0 Event

2011-04-16T07:17:00Z

现在的web应用越来越复杂,需要响应各种各样的用户触发事件,因而也就不可避免的,需要给我们的html页面上的dom元素增加事件监听函数.

我们知道给dom元素绑定事件监听函数的方法有如下3种:

1 : 页面html:

<button onclick=”test();”></button>

2: 页面html:

<button id=”btn”></button>

Javascript:

document.getElementById(“btn”).onclick =  test;

3: 页面html:

 <button id=”btn”></button>

Javascript:

document.getElementById(“btn”).atachEvent(“onclick”,test); //ie

这3种方法的功能效果和差异,大家都了解,在此就不在赘述了,但是这3种方法,对页面渲染的速度,资源的消耗,却是有很大不同的.

正文后面的html代码是一个demo页面,大家可以用ie浏览器打开,通过注释不同的代码段,查看页面运行效果.

可以看到第一种方式的效率是最低的,随着页面节点的增多,页面渲染时间急剧增加,在ie7下运行,大概670ms;

第二种方式明显好一些,在ie7下,大概250ms

而第三种方式则是最快的方法,也是web前端开发推荐的标准写法,在ie7下,大概188ms;

然后我们去掉事件绑定的逻辑,发现只渲染dom元素,不绑定事件的时间,仅仅125ms,可见事件绑定的时间消耗还是很大的 ,尤其是第一种方式,也就是Dom Level 0 Event,最为耗时.

另外,大家运行各段代码的时候,不妨打开任务管理器,找到浏览器对应的进程,查看代码运行时cpu的消耗以及内存的使用.

我们可以看到,Dom Level 0 Event,对cpu的消耗明显要高很多.

对内存的消耗分析:

重新打开浏览器,空白页面的内存占用量大概是37M,虚拟内存为28M,页面渲染后:

1 内存使用 54M,虚拟内存41M

2 内存使用44M,虚拟内存31M

3 内存使用44M,虚拟内存31M

可见Dom Level 0 Event对内存的消耗,也远远超出了其它方式.

为什么Dom Level 0 Event会这么消耗系统资源呢?对cpu和内存的消耗都远远超出了其它方式.我们来做一个简单分析.

为了便于分析,我们不妨修改一下我们的代码 <button onclick=”debugger;test();”></button> ,然后运行页面,在ie的script debugger里我们找到堆栈调用这一项,可以看到有一个anonymos function,这个function是从何而来的呢.原来浏览器在对Dom Level 0 Event做绑定的时候,会自动生成一个包含我们的代码的匿名函数,然后把这个匿名函数绑定到事件.类似于如下方式:

document.getElementById(“btn”).onclick = function(event){

test();

} ;

而ie浏览器又没有足够的智能,区分出众多内部功能完全一致的匿名函数并合并它们的引用,所以导致了随着dom事件绑定的越来越多,匿名函数的个数也越来越多.因为要声明数量众多的事件处理匿名函数,也就不难明白,为什么会消耗如此多的系统资源了.

随着dom元素的增多,这个资源消耗就会越来越严重.而且我们可以尝试着刷新一下页面,发现随着刷新的次数增加,页面运行越来越慢,cpu消耗也越来越多,内存也会有少量增加.可见,Dom Level 0 Event 还会带来少量的内存泄露.至于时间的延长,cpu消耗的加聚,推测是因为浏览器忙于释放众多的匿名函数所占用的资源所带来的后果.

进一步深入,由于ie浏览器是基于冒泡的事件模型,子元素的event会冒泡到父元素,所以更极致的优化,是去掉众多子元素的事件绑定,而将事件绑定到父元素,在正文后的demo中,也有这方面的尝试,可以看到不仅cpu,内存消耗最低,时间上也跟渲染干净的html页面是一样的.

所以我们在页面事件绑定中,要尽量避免Dom Level 0 Event,而且要尽可能的将事件上升．（当然也要考虑事件处理的灵活性）．

demo：

<BODY>
    <ul id="list"></ul>
    <SCRIPT LANGUAGE="JavaScript">
    <!--
        var $ = function(id){
        return document.getElementById(id)
        };
        function test(){
            alert(1)
        }
        var ul = $("list");
        var count = 5000;
        // ie7 
    //-->
    </SCRIPT>
  <script>
    var d = new Date()
    var str = [];
    for(var i = 0;i<count;i++){
        str.push('<li onclick="test();">'+i+'</li>')
    }
    ul.innerHTML = str.join("");
    alert(new Date - d);
    //670  刷新时时间增加   85
  </script>
  <SCRIPT LANGUAGE="JavaScript">
  <!--
    /*var d = new Date()
    var str = [];
    for(var i = 0;i<count;i++){
        str.push('<li>'+i+'</li>')
    }
    ul.innerHTML = str.join("");
    alert(new Date - d); */  
    //125
  //-->
  </SCRIPT>
  <SCRIPT LANGUAGE="JavaScript">
  <!--
    /*var d = new Date()
    var str = [];
    for(var i = 0;i<count;i++){
        str.push('<li>'+i+'</li>')
    }
    ul.innerHTML = str.join("");
    var li = document.getElementsByTagName("li");
    var l = li.length;
    for(var i=0;i<l;i++){
        li[i].onclick = test;
    }
    li = null;
    alert(new Date - d);*/
    //250
  //-->
  </SCRIPT>
   <SCRIPT LANGUAGE="JavaScript">
  <!--
    /*var d = new Date()
    var str = [];
    for(var i = 0;i<count;i++){
        str.push('<li>'+i+'</li>')
    }
    ul.innerHTML = str.join("");
    var li = document.getElementsByTagName("li");
    var l = li.length;
    for(var i=0;i<l;i++){
        li[i].attachEvent("onclick",test);
    }
    li = null;
    alert(new Date - d);*/
    //188
  //-->
  </SCRIPT>
   <SCRIPT LANGUAGE="JavaScript">
  <!--
    /*var d = new Date()
    var str = [];
    for(var i = 0;i<count;i++){
        str.push('<li>'+i+'</li>')
    }
    ul.innerHTML = str.join("");
    ul.attachEvent("onclick",test);
    alert(new Date - d);*/
    //125
  //-->
  </SCRIPT>
 </BODY>

本文链接

Asp.net中网站级异常捕获

2011-04-16T06:34:00Z

近在公司某管理系统中，用了一些独立的模块，在这些类的实现中，错误是直接抛出异常的，我想这是我们通常的做法。然而，问题也来了，由于自己在Asp.net页面中没有去捕获这些异常，并且多处页面中都使用了这些类，于是在多个页面都会出现不友好的错误提示信息。

怎么办？又不想一处一处修改代码，既费时又费力，这样编程不就变成了体力劳动，从而失去了乐趣。这时让我想起了自定义错误页，于是Google，终于找到了答案。

1、配置web.config:

关键是redirectMode属性，该属性默认为ResponseRedirect，由于被Redirect了，异常也就被忽略了，使你无法捕获到异常。这里罗嗦一句：因为出错前后被认为是两次请求，我们知道http协议是一种无状态的协议，第二次请求忽略了第一次的异常也就不奇怪了。于是有人用了Session或Application来保存异常，这是不可取的。正确的做法是使用“ResponseRewrite"。

2、输出异常信息：

我们知道网站出错时，会自动导向我们的ErrorPage.apx页面，在ErrorPage.aspx中如何访问这个异常呢？答案是:Server.GetLastError()，当然有可能是Server.GetLastError().InnerException。这要具体分析了。

if(Server.GetLastError()!=null){
Response.Write(Server.GetLastError().Message);
}

顺便说一下：

Asp.net MVC中就简单多了，框架自带了一个Error.aspx，异常保存在Model.Exception中，并且Web.config中也为我们配置好了。

在下从去年以来开发的网页就基本是MVC的了，结构清晰，扩展方便，清凉的HTML代码输出。有空看看MVC的源代码还是很有帮助的。

本文链接

vsjitdebugger.exe 进程解决方法

2011-03-17T02:44:00Z

服务器上时不时就会出现vsjitdebugger.exe这个进程，还经常是好多一起出现，一旦出现，服务器上运行的软件就不工作了，甚是郁闷！远程桌面到服务器上，能看到每一个进程其实就是一个visual studio的调试窗口，挨个关掉就好了。有没有更好的解决方法呢？

今天上网查了查，终于找到了解决办法，但不知道给程序调试会不会留下什么隐患，后来想想反正服务器上也不做debug，就这样吧。

禁用实时调试：打开VS2005，在“工具”菜单中单击“选项”，选择“调试”文件夹，选择“实时”页，清除相关的程序类型：“托管”、“本机”、“脚本”，单击“确定”。

删除以下注册表项：
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]

"Debugger"="C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]

"DbgManagedDebugger"="C:\WINDOWS\system32\vsjitdebugger.exe" PID %d APPDOM %d EXTEXT "%s" EVTHDL %d

这样，windows就没有任何调试器了。

如果想恢复原来的调试：
选上相关的程序类型：“托管”、“本机”、“脚本”
或执行： drwtsn32 -i

本文链接

Sql2000把数据库备份到网络上其余地电脑上

2011-02-24T05:16:00Z

SQL code

--你是否有足够的权限?如果有足够的权限,可以备份到本机

--如果有,可以用下面的方法,查询分析器中操作:

-- 创建共享目录
exec master.dbo.XP_cmdshell 'md c:\bak'
exec master.dbo.XP_cmdshell 'net share bak=c:\bak'

--进行数据备份
backup database 数据库 to disk='c:\bak\备份.bak'

/*--以下操作在我的电脑中进行:
   打开我的电脑,地址栏中输入:
   http://www.cnblogs.com/jvstudio/admin/file://\\SQL服务器的计算机名\bak\
   复制里面的备份.bak到你的电脑就行了

--我的电脑中的操作结束--*/

--删除备份生成的文件
exec master..xp_cmdshell 'del c:\bak\备份.bak'

--删除共享
exec master.dbo.XP_cmdshell 'net share c:\bak /delete /y'
exec master.dbo.XP_cmdshell 'rd c:\bak'

--否则,你还是完全共享你本机的目录,用下面的方法备份:
backup database 数据库 to disk='\\你的计算机名\共享目录名\备份文件名'

---或通过映射网络驱动器(这样可以解决权限问题)

--1.映射
exec master..xp_cmdshell 'net use z: \\xz\c$ "密码" /user:xz\administrator'

/*--说明:
z:            是映射网络路径对应本机的盘符,与下面的备份对应
\\xz\c$            是要映射的网络路径
xz\administrator        xz是远程的计算机名,administrator是登陆的用户名
密码                        上面指定的administrator用户的密码
--*/

--2.进行数据库备份
backup database 数据库名 to disk='z:\备份文件名'

--3.备份完成后删除映射
exec master..xp_cmdshell 'net use z: /delete'

本文链接

使用InternalsVisibleToAttribute控制internal成员的访问

2010-08-12T01:24:00Z

在上一篇文章中，为了解决成员访问级别的问题，我采用了一个object adapter，使得客户程序无法轻易地修改对象的属性。网友评论说，我的这种做法就是绕了一圈，的确，这种方法没办法阻止客户程序刻意地去修改对象的属性，但在一定程度上起到了保护作用：至少降低了误操作的可能性。

今天发现其实可以用System.Runtime.CompilerServices.InternalsVisibleToAttribute这个特性达到同样的效果。以下是操作步骤。

假设ExposedSetter.Library这个class library中包含了一个具有internal setter属性的SourcedAggregationRoot类。首先，对ExposedSetter.Library作数字签名。在ExposedSetter.Library项目上点右键选择“Properties”。在“Signing”页下选择“Sign the assembly”选项，然后指定一个强名称密钥文件。SourcedAggregationRoot的代码以及ExposedSetter.Library的签名设置如下
隐藏行号复制代码？代码
1. ```
public class SourcedAggregationRoot : IVersionControllable
```
2. ```
{
```
3. ```
private long version;
```
4. ```
private long branch;
```
6. ```
#region IVersionControllable Members
```
8. ```
public long Version
```
9. ```
{
```
10. ```
get { return this.version; }
```
11. ```
internal set { this.version = value; }
```
12. ```
}
```
14. ```
public long Branch
```
15. ```
{
```
16. ```
get { return this.branch; }
```
17. ```
internal set { this.branch = value; }
```
18. ```
}
```
20. ```
#endregion
```
21. ```

```
22. ```
    public override string ToString()
```
23. ```
{
```
24. ```
return string.Format("Version = {0}, Branch = {1}",
```
25. ```
version, branch);
```
26. ```
}
```
27. ```
}
```
新建一个class library，以调用ExposedSetter.Library中SourcedAggregationRoot的internal setter属性。为方便描述，我们将这个class library命名为ExposedSetter.Library2。在这个class library上添加对ExposedSetter.Library的引用，同时随便写一个测试的类，在类里直接调用SourcedAggregationRoot的internal setter属性来设置属性值。
隐藏行号复制代码？代码
1. ```
public class Class1
```
2. ```
{
```
3. ```
public SourcedAggregationRoot Test()
```
4. ```
{
```
5. ```
SourcedAggregationRoot sar = new SourcedAggregationRoot();
```
6. ```
sar.Branch = 125;
```
7. ```
return sar;
```
8. ```
}
```
9. ```
}
```
同样，为ExposedSetter.Library2做数字签名（这一点很重要！）
启动Visual Studio的Command Line，使用sn.exe获得ExposedSetter.Library2的公共密钥（public key），注意：是public key，而不是public key token
打开ExposedSetter.Library的AssemblyInfo.cs文件，向其添加InternalsVisibleToAttribute：
隐藏行号复制代码？代码
1. ```
[assembly: InternalsVisibleTo("ExposedSetter.Library2, PublicKey=0024000004800000940000000602000000240" +
```
2. ```
"000525341310004000001000100bbccb249a2e7a1" +
```
3. ```
"7cbddf86e24532777568cb13c2ea7643b61cf60367068f2b9ca785dca303c49f015823e4eaa17b" +
```
4. ```
"50ed60ac47563dc8d8771358f10c3dc41f288530cfa350e6a2a24781dedeb8ec4138f93e76c537" +
```
5. ```
"bce6c5aa7b25858fa90d6ef5c6ea613b1b49e6e287f9ebb7f990cfa0ce17fbfe1c338e95e88c14" +
```
6. ```
"81f9598f")]
```
注意，InternalsVisibleToAttribute的参数指定了允许访问其internal成员的assembly名称和公共密钥数据。在此不能设置assembly的版本等信息，否则编译都过不去。
编译解决方案

这种方式有点像C++的友元。与我上文提到的引入object adapter的解决方案相比，这种做法更加professional一些，毕竟可以通过.NET Framework直接支持，而且也更加安全一些，它能够明确指定哪些assembly可以访问，其余的则不能访问。但这种做法也有弊端：假设我今后又有一个assembly希望使用ExposedSetter.Library中的internal成员，我需要去修改ExposedSetter.Library中的代码，以添加一个InteralsVisibleToAttribute特性。

转帖地址：http://www.cnblogs.com/daxnet/archive/2010/08/12/1797782.html

本文链接

XML数据读取方式性能比较（一）

2010-08-12T01:19:00Z

几个月来，疑被SOA，一直在和XML操作打交道，SQL差不多又忘光了。现在已经知道，至少有四种常用人XML数据操作方式(好像Java差不多)，不过还没有实际比较过这些方式各有哪些特点或优劣。正好看到网上也没有这方面的实验，偶来总结一下。

测试开始先读取XML源，用一个比较大的RSS文件链接，复制到项目bin/debug目录下。

Stream xmlStream = new MemoryStream(File.ReadAllBytes(path));

一、XmlDocument 方式

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

--> 1 static IList testXmlDocument()
2 {
3 var doc = new XmlDocument();
4 doc.Load(xmlStream);
5 var nodeList = doc.DocumentElement.ChildNodes;
6 var lstChannel = new List<Object>(nodeList.Count );
7 foreach (XmlNode node in nodeList)
8 {
9 var channel = new
10 {
11 Title = node.SelectSingleNode("title").InnerText,
12 Link = node.SelectSingleNode("link").InnerText,
13 Description = node.SelectSingleNode("description").InnerText,
14 Content = node.SelectSingleNode("content").InnerText,
15 PubDate = node.SelectSingleNode("pubDate").InnerText,
16 Author = node.SelectSingleNode("author").InnerText,
17 Category = node.SelectSingleNode("category").InnerText
18 };
19 lstChannel.Add(channel);
20 }
21 return lstChannel;
22 }

二、XPathNavigator 方式

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

--> 1 static IList testXmlNavigator()
2 {
3 var doc = new XmlDocument();
4 doc.Load(xmlStream);
5 var nav = doc.CreateNavigator();
6 nav.MoveToRoot();
7 var nodeList = nav.Select("/channel/item");
8 var lstChannel = new List<Object>(nodeList.Count);
9 foreach (XPathNavigator node in nodeList)
10 {
11 var channel = new
12 {
13 Title = node.SelectSingleNode("title").Value,
14 Link = node.SelectSingleNode("link").Value,
15 Description = node.SelectSingleNode("description").Value,
16 Content = node.SelectSingleNode("content").Value,
17 PubDate = node.SelectSingleNode("pubDate").Value,
18 Author = node.SelectSingleNode("author").Value,
19 Category = node.SelectSingleNode("category").Value
20 };
21 lstChannel.Add(channel);
22 }
23 return lstChannel;
24 }

三、XmlTextReader 方式

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

--> 1 static List<Channel> testXmlReader()
2 {
3 var lstChannel = new List<Channel>();
4 var reader = XmlReader.Create(xmlStream);
5 while (reader.Read())
6 {
7 if (reader.Name == "item" && reader.NodeType == XmlNodeType.Element)
8 {
9 var channel = new Channel();
10 lstChannel.Add(channel);
11 while (reader.Read())
12 {
13 if (reader.Name == "item") break;
14 if (reader.NodeType != XmlNodeType.Element) continue;
15 switch (reader.Name)
16 {
17 case "title":
18 channel.Title = reader.ReadString();
19 break;
20 case "link":
21 channel.Link = reader.ReadString();
22 break;
23 case "description":
24 channel.Description = reader.ReadString();
25 break;
26 case "content":
27 channel.Content = reader.ReadString();
28 break;
29 case "pubDate":
30 channel.PubDate = reader.ReadString();
31 break;
32 case "author":
33 channel.Author = reader.ReadString();
34 break;
35 case "category":
36 channel.Category = reader.ReadString();
37 break;
38 default:
39 break;
40 }
41 }
42 }
43 }
44 return lstChannel;
45 }

四、Linq to XML 方式

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

--> 1 static IList testXmlLinq()
2 {
3 var xd = XDocument.Load(xmlStream);
4 var list = from node in xd.Elements("channel").Descendants("item")
5 select new
6 {
7 Title = node.Element("title").Value,
8 Link = node.Element("link").Value,
9 Description = node.Element("description").Value,
10 Content = node.Element("content").Value,
11 PubDate = node.Element("pubDate").Value,
12 Author = node.Element("author").Value,
13 Category = node.Element("category").Value
14 };
15 return list.ToList();
16 }

测试结果：

XmlDocment	47ms
XPathNavigator	42ms
XmlTextReader	23ms
Xml Linq	28ms

小结一下自己的认识，XmlDocument的操作基本按W3C的DOM操作方式，不过要将全部节点解析成对象加载到内存中，往往造成很大浪费。所以微软自己的编程规范也不推荐用它。这里由于读取了所有节点，可能因此性能和Navigator方式相差不大。在三种随机读取方式中，Xml Linq性能最高，只是方法名有点别扭。XmlTextReader方式是所谓的SAX，只读向前，无疑性能最高，不过实现上麻烦了不少，要比较精确的控制访问逻辑，也无法用匿名类存储数据。

.Net 3.5发布Xml Linq可以很好地取代前两种方式，通常情况下，最好用它。只有个别场合，如果对性能要求极高，或者读取Xml数据量太大不能一下子下载或读取到内存中，那就只好痛苦委身于XmlTextReader了。

转帖地址：http://www.cnblogs.com/XmNotes/archive/2010/08/12/1796162.html

本文链接

使用c#生成gif动画验证码及给gif动画加上水印代码

2010-07-17T06:42:00Z

   using System;
     using System.IO;
     using System.Web;
     using System.Drawing;
     //GIF验证码类
     public class Validate
     {
         //设置最少4位验证码
         private byte TrueValidateCodeCount = 4;
         public byte ValidateCodeCount
         {
             get
             {
                 return TrueValidateCodeCount;
             }
             set
             {
                 //验证码至少为3位
                 if (value > 4)
                     TrueValidateCodeCount = value;
             }
         }
         protected string ValidateCode = "";
         //是否消除锯齿
         public bool FontTextRenderingHint = false;
         //验证码字体
         public string ValidateCodeFont = "Arial";
         //验证码型号(像素)
         public float ValidateCodeSize = 13;
         public int ImageHeight = 23;
         //定义验证码中所有的字符
         public string AllChar = "1,2,3,4,5,6,7,8,9,0,A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,W,X,Y,Z";

         //获得随机四位数
         private void CreateValidate()
         {
             ValidateCode = "";
             //将验证码中所有的字符保存在一个字符串数组中
             string[] CharArray = AllChar.Split(',');
             int Temp = -1;
             //生成一个随机对象
             Random RandCode = new Random();
             //根据验证码的位数循环
             for (int i = 0; i < ValidateCodeCount; i++)
             {
                 //主要是防止生成相同的验证码
                 if (Temp != -1)
                 {
                     //加入时间的刻度
                     RandCode = new Random(i * Temp * ((int)DateTime.Now.Ticks));
                 }
                 int t = RandCode.Next(35);
                 if (Temp == t)
                 {
                     //相等的话重新生成
                     CreateValidate();
                 }
                 Temp = t;
                 ValidateCode += CharArray[Temp];
             }
             //错误检测,去除超过指定位数的验证码
             if (ValidateCode.Length > TrueValidateCodeCount)
                 ValidateCode = ValidateCode.Remove(TrueValidateCodeCount);
         }
         //生成一帧的BMP图象
         private void CreateImageBmp(out Bitmap ImageFrame)
         {
             //获得验证码字符
             char[] CodeCharArray = ValidateCode.ToCharArray(0, ValidateCodeCount);
             //图像的宽度-与验证码的长度成一定比例
             int ImageWidth = (int)(TrueValidateCodeCount * ValidateCodeSize * 1.3 + 4);
             //创建一个长20，宽iwidth的图像对象
             ImageFrame = new Bitmap(ImageWidth, ImageHeight);
             //创建一个新绘图对象
             Graphics ImageGraphics = Graphics.FromImage(ImageFrame);
             //清除背景色，并填充背景色
             //Note:Color.Transparent为透明
             ImageGraphics.Clear(Color.White);
             //绘图用的字体和字号
             Font CodeFont = new Font(ValidateCodeFont, ValidateCodeSize, FontStyle.Bold);
             //绘图用的刷子大小
             Brush ImageBrush = new SolidBrush(Color.Red);
             //字体高度计算
             int FontHeight = (int)Math.Max(ImageHeight - ValidateCodeSize - 3, 2);
             //创建随机对象
             Random rand = new Random();
             //开始随机安排字符的位置，并画到图像里
             for (int i = 0; i < TrueValidateCodeCount; i++)
             {
                 //生成随机点，决定字符串的开始输出范围
                 int[] FontCoordinate = new int[2];
                 FontCoordinate[0] = (int)(i * ValidateCodeSize + rand.Next(1)) + 3;
                 FontCoordinate[1] = rand.Next(FontHeight);
                 Point FontDrawPoint = new Point(FontCoordinate[0], FontCoordinate[1]);
                 //消除锯齿操作
                 if (FontTextRenderingHint)
                     ImageGraphics.TextRenderingHint = System.Drawing.Text.TextRenderingHint.SingleBitPerPixel;
                 else
                     ImageGraphics.TextRenderingHint = System.Drawing.Text.TextRenderingHint.AntiAlias;
                 //格式化刷子属性-用指定的刷子、颜色等在指定的范围内画图
                 ImageGraphics.DrawString(CodeCharArray[i].ToString(), CodeFont, ImageBrush, FontDrawPoint);
             }
             ImageGraphics.Dispose();
         }
         //处理生成的BMP
         private void DisposeImageBmp(ref Bitmap ImageFrame)
         {
             //创建绘图对象
             Graphics ImageGraphics = Graphics.FromImage(ImageFrame);
             //创建铅笔对象
             Pen ImagePen = new Pen(Color.Red, 1);
             //创建随机对象
             Random rand = new Random();
             //创建随机点
             Point[] RandPoint = new Point[2];
             //随机画线
             for (int i = 0; i < 15; i++)
             {
                 RandPoint[0] = new Point(rand.Next(ImageFrame.Width), rand.Next(ImageFrame.Height));
                 RandPoint[1] = new Point(rand.Next(ImageFrame.Width), rand.Next(ImageFrame.Height));
                 ImageGraphics.DrawLine(ImagePen, RandPoint[0], RandPoint[1]);
             }
             ImageGraphics.Dispose();
         }
         //创建GIF动画
         private void CreateImageGif()
         {
             Bitmap ImageFrame;
             Kissogram.Drawing.Gif.AnimatedGifEncoder GifPic = new Kissogram.Drawing.Gif.AnimatedGifEncoder();
             MemoryStream BmpMemory = new MemoryStream();
             GifPic.Start();
             //确保视觉残留
             GifPic.SetDelay(5);
             //-1:no repeat,0:always repeat
             GifPic.SetRepeat(0);
             for (int i = 0; i < 20; i++)
             {
                 //创建一帧的图像
                 CreateImageBmp(out ImageFrame);
                 //生成随机线条
                 DisposeImageBmp(ref ImageFrame);
                 //输出绘图,将图像保存到指定的流
                 ImageFrame.Save(BmpMemory, System.Drawing.Imaging.ImageFormat.Png);
                 GifPic.AddFrame(Image.FromStream(BmpMemory));
                 BmpMemory = new MemoryStream();
             }
             GifPic.OutPut(ref BmpMemory);
             HttpContext.Current.Response.ClearContent();
             //配置输出类型
             HttpContext.Current.Response.ContentType = "image/Gif";
             //输出内容
             HttpContext.Current.Response.BinaryWrite(BmpMemory.ToArray());
             BmpMemory.Close();
             BmpMemory.Dispose();
         }
         //输出验证码
         public void OutPutValidate(string ValidateCodeSession)
         {
             CreateValidate();
             CreateImageGif();
             //把生成的验证码输入到SESSION
             HttpContext.Current.Session[ValidateCodeSession] = ValidateCode;
         }
     }

//加水印的代码：

public static Bitmap WaterMarkWithText(System.Drawing.Bitmap origialGif, string text,string filePath)
{
//用于存放桢
List<Frame> frames = new List<Frame>();
//如果不是gif文件,直接返回原图像
if (origialGif.RawFormat.Guid != System.Drawing.Imaging.ImageFormat.Gif.Guid)
{
return origialGif;
}
//如果该图像是gif文件
foreach (Guid guid in origialGif.FrameDimensionsList)
{
System.Drawing.Imaging.FrameDimension frameDimension = new System.Drawing.Imaging.FrameDimension(guid);
int frameCount = origialGif.GetFrameCount(frameDimension);
for (int i = 0; i < frameCount; i++)
{
if (origialGif.SelectActiveFrame(frameDimension, i) == 0)
{
int delay = Convert.ToInt32(origialGif.GetPropertyItem(20736).Value.GetValue(i));
Image img = Image.FromHbitmap(origialGif.GetHbitmap());
Font font = new Font(new FontFamily("宋体"), 35.0f,FontStyle.Bold);
Graphics g = Graphics.FromImage(img);
g.DrawString(text, font, Brushes.BlanchedAlmond, new PointF(10.0f, 10.0f));
Frame frame = new Frame(img, delay);
frames.Add(frame);
}
}
Gif.Components.AnimatedGifEncoder gif = new Gif.Components.AnimatedGifEncoder();
gif.Start(filePath);
gif.SetDelay(100);
gif.SetRepeat(0);
for (int i = 0; i < frames.Count; i++)
{
gif.AddFrame(frames[i].Image);
}
gif.Finish();
try
{
Bitmap gifImg = (Bitmap)Bitmap.FromFile(filePath);
return gifImg;
}
catch
{
return origialGif;
}
}
return origialGif;
}

本文链接

详解JQuery上传插件Uploadify

2010-07-13T05:41:00Z

Uploadify是JQuery的一个上传插件，实现的效果非常不错，带进度显示。不过官方提供的实例时php版本的，本文将详细介绍 Uploadify在Aspnet中的使用。

首先按下面的步骤来实现一个简单的上传功能。

1 创建Web项目，命名为JQueryUploadDemo，从官网上下载最新的版本解压后添加到项目中。

2 在项目中添加UploadHandler.ashx文件用来处理文件的上传。

3 在项目中添加UploadFile文件夹，用来存放上传的文件。

进行完上面三步后项目的基本结构如下图:

4 Default.aspx的html页的代码修改如下：

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Uploadify</title>
    <link href="JS/jquery.uploadify-v2.1.0/example/css/default.css"
     rel="stylesheet" type="text/css" />
    <link href="JS/jquery.uploadify-v2.1.0/uploadify.css"
     rel="stylesheet" type="text/css" />
    <script type="text/javascript"
     src="JS/jquery.uploadify-v2.1.0/jquery-1.3.2.min.js"></script>
    <script type="text/javascript"
     src="JS/jquery.uploadify-v2.1.0/swfobject.js"></script>
    <script type="text/javascript"
   src="JS/jquery.uploadify-v2.1.0/jquery.uploadify.v2.1.0.min.js"></script>
    <script type="text/javascript">
        $(document).ready(function()
        {
            $("#uploadify").uploadify({
                'uploader': 'JS/jquery.uploadify-v2.1.0/uploadify.swf',
                'script': 'UploadHandler.ashx',
                'cancelImg': 'JS/jquery.uploadify-v2.1.0/cancel.png',
                'folder': 'UploadFile',
                'queueID': 'fileQueue',
                'auto': false,
                'multi': true
            });
        });
    </script>
</head>
<body>
    <div id="fileQueue"></div>
    <input type="file" name="uploadify" id="uploadify" />
    <p>
      <a href="javascript:$('#uploadify').uploadifyUpload()">上传</a>|
      <a href="javascript:$('#uploadify').uploadifyClearQueue()">取消上传</a& gt;
    </p>
</body>
</html>

　　5 UploadHandler类的ProcessRequest方法代码如下：

　　public void ProcessRequest(HttpContext context)
　　{
　　context.Response.ContentType = "text/plain";
　　context.Response.Charset = "utf-8";
　　HttpPostedFile file = context.Request.Files["Filedata"];
　　string uploadPath =
　　HttpContext.Current.Server.MapPath(@context.Request["folder"])+"\\";
　　if (file != null)
　　{
　　if (!Directory.Exists(uploadPath))
　　{
　　Directory.CreateDirectory(uploadPath);
　　}
　　file.SaveAs(uploadPath + file.FileName);
　　//下面这句代码缺少的话，上传成功后上传队列的显示不会自动消失
　　context.Response.Write("1");
　　}
　　else
　　{
　　context.Response.Write("0");
　　}
　　}

6 运行后效果如下图：

7 选择了两个文件后，点击上传，就可以看到UploadFile文件夹中会增加这两个文件。

上面简单地实现了一个上传的功能，依靠函数uploadify实现，uploadify函数的参数为json格式，可以对json对象的key 值的修改来进行自定义的设置，如multi设置为true或false来控制是否可以进行多文件上传，下面就来介绍下这些key值的意思：

uploader ： uploadify.swf 文件的相对路径，该swf文件是一个带有文字BROWSE的按钮，点击后淡出打开文件对话框，默认值：uploadify.swf。

script ：后台处理程序的相对路径。默认值：uploadify.php

checkScript ：用来判断上传选择的文件在服务器是否存在的后台处理程序的相对路径

fileDataName ：设置一个名字，在服务器处理程序中根据该名字来取上传文件的数据。默认为Filedata

method ：提交方式Post 或Get 默认为Post

scriptAccess ：flash脚本文件的访问模式，如果在本地测试设置为always，默认值：sameDomain

folder ：上传文件存放的目录。

queueID ：文件队列的ID，该ID与存放文件队列的div的ID一致。

queueSizeLimit ：当允许多文件生成时，设置选择文件的个数，默认值：999 。

multi ：设置为true时可以上传多个文件。

auto ：设置为true当选择文件后就直接上传了，为false需要点击上传按钮才上传。

fileDesc ：这个属性值必须设置fileExt属性后才有效，用来设置选择文件对话框中的提示文本，如设置fileDesc为“请选择rar doc pdf文件”，打开文件选择框效果如下图：

fileExt ：设置可以选择的文件的类型，格式如：'*.doc;*.pdf;*.rar' 。

sizeLimit ：上传文件的大小限制。

simUploadLimit ：允许同时上传的个数默认值：1 。

buttonText ：浏览按钮的文本，默认值：BROWSE 。

buttonImg ：浏览按钮的图片的路径。

hideButton ：设置为true则隐藏浏览按钮的图片。

rollover ：值为true和false，设置为true时当鼠标移到浏览按钮上时有反转效果。

width ：设置浏览按钮的宽度，默认值：110。

height ：设置浏览按钮的高度，默认值：30。

wmode ：设置该项为transparent 可以使浏览按钮的flash背景文件透明，并且flash文件会被置为页面的最高层。默认值：opaque 。

cancelImg ：选择文件到文件队列中后的每一个文件上的关闭按钮图标，如下图：

上面介绍的key值的value都为字符串或是布尔类型，比较简单，接下来要介绍的key值的value为一个函数，可以在选择文件、出错或其他一些操作的时候返回一些信息给用户。

onInit : 做一些初始化的工作。

onSelect ：选择文件时触发，该函数有三个参数

event:事件对象。

queueID：文件的唯一标识，由6为随机字符组成。

fileObj：选择的文件对象，有name、size、creationDate、modificationDate、type 5个属性。

代码如下：

　　$(document).ready(function()
　　{
　　$("#uploadify").uploadify({
　　'uploader': 'JS/jquery.uploadify-v2.1.0/uploadify.swf',
　　'script': 'UploadHandler.ashx',
　　'cancelImg': 'JS/jquery.uploadify-v2.1.0/cancel.png',
　　'folder': 'UploadFile',
　　'queueID': 'fileQueue',
　　'auto': false,
　　'multi': true,
　　'onInit':function(){alert("1");},
　　'onSelect': function(e, queueId, fileObj)
　　{
　　alert("唯一标识:" + queueId + "\r\n" +
　　"文件名：" + fileObj.name + "\r\n" +
　　"文件大小：" + fileObj.size + "\r\n" +
　　"创建时间：" + fileObj.creationDate + "\r\n" +
　　"最后修改时间：" + fileObj.modificationDate + "\r\n" +
　　"文件类型：" + fileObj.type
　　);
　　}
　　});
　　});

当选择一个文件后弹出的消息如下图：

onSelectOnce ：在单文件或多文件上传时，选择文件时触发。该函数有两个参数event，data，data对象有以下几个属性：

fileCount：选择文件的总数。

filesSelected：同时选择文件的个数，如果一次选择了3个文件该属性值为3。

filesReplaced：如果文件队列中已经存在A和B两个文件，再次选择文件时又选择了A和B，该属性值为2。

allBytesTotal：所有选择的文件的总大小。

onCancel : 当点击文件队列中文件的关闭按钮或点击取消上传时触发。该函数有event、queueId、fileObj、data四个参数，前三个参数同 onSelect 中的三个参数，data对象有两个属性fileCount和allBytesTotal。

fileCount：取消一个文件后，文件队列中剩余文件的个数。

allBytesTotal：取消一个文件后，文件队列中剩余文件的大小。

onClearQueue ：当调用函数fileUploadClearQueue时触发。有event和data两个参数，同onCancel 中的两个对应参数。

onQueueFull ：当设置了queueSizeLimit并且选择的文件个数超出了queueSizeLimit的值时触发。该函数有两个参数event和 queueSizeLimit。

onError ：当上传过程中发生错误时触发。该函数有event、queueId、fileObj、errorObj四个参数，其中前三个参数同上，errorObj 对象有type和info两个属性。

type：错误的类型，有三种‘HTTP’, ‘IO’, or ‘Security’

info：错误的描述

onOpen ：点击上传时触发，如果auto设置为true则是选择文件时触发，如果有多个文件上传则遍历整个文件队列。该函数有event、queueId、 fileObj三个参数，参数的解释同上。

onProgress ：点击上传时触发，如果auto设置为true则是选择文件时触发，如果有多个文件上传则遍历整个文件队列，在onOpen之后触发。该函数有 event、queueId、fileObj、data四个参数，前三个参数的解释同上。data对象有四个属性percentage、 bytesLoaded、allBytesLoaded、speed：

percentage：当前完成的百分比

bytesLoaded：当前上传的大小

allBytesLoaded：文件队列中已经上传完的大小

speed：上传速率 kb/s

onComplete：文件上传完成后触发。该函数有四个参数event、queueId、fileObj、response、data五个参数，前三个参数同上。response为后台处理程序返回的值，在上面的例子中为1或0，data有两个属性fileCount和speed

fileCount：剩余没有上传完成的文件的个数。

speed：文件上传的平均速率 kb/s

onAllComplete：文件队列中所有的文件上传完成后触发。该函数有event和data两个参数，data有四个属性，分别为：

filesUploaded :上传的所有文件个数。

errors ：出现错误的个数。

allBytesLoaded ：所有上传文件的总大小。

speed ：平均上传速率 kb/s

提高ASP.NET首页性能的十大方法

2010-07-13T05:40:00Z

前言

本文是我对ASP.NET页面载入速度提高的一些做法，这些做法分为以下部分：

1.采用 HTTP Module 控制页面的生命周期。

2.自定义Response.Filter得到输出流stream生成动态页面的静态内容(磁盘缓存)。

3.页面GZIP压缩。

4.OutputCache 编程方式输出页面缓存。

5.删除页面空白字符串。（类似Google）

6.完全删除ViewState。

7.删除服务器控件生成的垃圾NamingContainer。

8.使用计划任务按时生成页面。（本文不包含该做法的实现）

9.JS，CSS压缩、合并、缓存，图片缓存。（限于文章篇幅，本文不包含该做法的实现）

10.缓存破坏。（不包含第9做法的实现）

针对上述做法，我们首先需要一个 HTTP 模块，它是整个页面流程的入口和核心。

一、自定义Response.Filter得到输出流stream生成动态页面的静态内容(磁盘缓存)

如下的代码我们可以看出，我们以 request.RawUrl 为缓存基础，因为它可以包含任意的QueryString变量，然后我们用MD5加密RawUrl 得到服务器本地文件名的变量，再实例化一个FileInfo操作该文件，如果文件最后一次生成时间小于7天，我们就使用.Net2.0新增的 TransmitFile方法将存储文件的静态内容发送到浏览器。如果文件不存在，我们就操作 response.Filter 得到的 Stream 传递给 CommonFilter 类，并利用FileStream写入动态页面的内容到静态文件中。

namespace  ASPNET_CL.Code.HttpModules {  
     public  class  CommonModule : IHttpModule {  
         public  void  Init( HttpApplication application ) {  
            application.BeginRequest += Application_BeginRequest;  
        }  
 
         private  void  Application_BeginRequest(  object  sender, EventArgs e ) {  
            var context = HttpContext.Current;  
            var request = context.Request;  
            var url = request.RawUrl;  
 
            var response = context.Response;  
            var path = GetPath( url );  
            var file =  new  FileInfo( path );  
 
             if  ( DateTime.Now.Subtract( file.LastWriteTime ).TotalDays < 7 ) {  
                response.TransmitFile( path );  
                response.End();  
                 return;  
            }  
             try  {  
                var stream = file.OpenWrite();  
                response.Filter =  new  CommonFilter( response.Filter, stream );  
            }  
             catch  ( Exception ) {  
                 //Log.Insert("");  
            }  
        }  
 
         public  void  Dispose() {  
 
        }  
 
         private  static  string  GetPath(  string  url ) {  
            var hash = Hash( url );  
             string  fold = HttpContext.Current.Server.MapPath(  "~/Temp/"  );  
             return  string.Concat( fold, hash );  
        }  
 
         private  static  string  Hash(  string  url ) {  
            url = url.ToUpperInvariant();  
            var md5 =  new  System.Security.Cryptography.MD5CryptoServiceProvider();  
            var bs = md5.ComputeHash( Encoding.ASCII.GetBytes( url ) );  
            var s =  new  StringBuilder();  
             foreach  ( var b  in  bs ) {  
                s.Append( b.ToString(  "x2"  ).ToLower() );  
            }  
             return  s.ToString();  
        }  
    }  
}

二、页面GZIP压缩

对页面GZIP压缩几乎是每篇讲解高性能WEB程序的几大做法之一，因为使用GZIP压缩可以降低服务器发送的字节数，能让客户感觉到网页的速度更快也减少了对带宽的使用情况。当然，这里也存在客户端的浏览器是否支持它。因此，我们要做的是，如果客户端支持GZIP，我们就发送GZIP压缩过的内容，如果不支持，我们直接发送静态文件的内容。幸运的是，现代浏览器IE6.7.8.0，火狐等都支持GZIP。

为了实现这个功能，我们需要改写上面的 Application_BeginRequest 事件：

 private void Application_BeginRequest( object sender, EventArgs e ) {  
    var context = HttpContext.Current;  
    var request = context.Request;  
    var url = request.RawUrl;  
 
    var response = context.Response;  
    var path = GetPath( url );  
    var file = new FileInfo( path );  
 
    // 使用页面压缩  
      ResponseCompressionType compressionType = this.GetCompressionMode( request );  
    if ( compressionType != ResponseCompressionType.None ) {  
        response.AppendHeader( "Content-Encoding", compressionType.ToString().ToLower() );  
        if ( compressionType == ResponseCompressionType.GZip ) {  
            response.Filter = new GZipStream( response.Filter, CompressionMode.Compress );  
        }  
        else {  
            response.Filter = new DeflateStream( response.Filter, CompressionMode.Compress );  
        }  
    }  
 
    if ( DateTime.Now.Subtract( file.LastWriteTime ).TotalMinutes < 5 ) {  
        response.TransmitFile( path );  
        response.End();  
        return;  
    }  
    try {  
        var stream = file.OpenWrite();  
        response.Filter = new CommonFilter( response.Filter, stream );  
    }  
    catch ( Exception ) {  
        //Log.Insert("");  
    }  
}  
 
private ResponseCompressionType GetCompressionMode( HttpRequest request ) {  
    string acceptEncoding = request.Headers[ "Accept-Encoding" ];  
    if ( string.IsNullOrEmpty( acceptEncoding ) )  
        return ResponseCompressionType.None;  
 
    acceptEncoding = acceptEncoding.ToUpperInvariant();  
 
    if ( acceptEncoding.Contains( "GZIP" ) )  
        return ResponseCompressionType.GZip;  
    else if ( acceptEncoding.Contains( "DEFLATE" ) )  
        return ResponseCompressionType.Deflate;  
    else 
        return ResponseCompressionType.None;  
}  
 
private enum ResponseCompressionType {  
    None,  
    GZip,  
    Deflate  
}

三、OutputCache 编程方式输出页面缓存

ASP.NET内置的 OutputCache 缓存可以将内容缓存在三个地方：Web服务器、代理服务器和浏览器。当用户访问一个被设置为 OutputCache的页面时，ASP.NET在MSIL之后，先将结果写入output cache缓存，然后在发送到浏览器，当用户访问同一路径的页面时，ASP.NET将直接发送被Cache的内容，而不经过.aspx编译以及执行 MSIL的过程，所以，虽然程序的本身效率没有提升，但是页面载入速度却得到了提升。

为了实现这个功能，我们继续改写上面的 Application_BeginRequest 事件，我们在 TransmitFile 后，将这个路径的页面以OutputCache编程的方式缓存起来：

private void Application_BeginRequest( object sender, EventArgs e ) {  
           
           //.............  
 
            if ( DateTime.Now.Subtract( file.LastWriteTime ).TotalMinutes < 5 ) {  
                response.TransmitFile( path );  
                // 添加 OutputCache 缓存头，并缓存在客户端  
                  response.Cache.SetExpires( DateTime.Now.AddMinutes( 5 ) );  
                response.Cache.SetCacheability( HttpCacheability.Public );  
                response.End();  
                return;  
            }  
             
           //............  
 }

四、实现CommonFilter类过滤ViewState、过滤NamingContainer、空白字符串，以及生成磁盘的缓存文件

我们传入response.Filter的Stream对象给CommonFilter类：

首先，我们用先Stream的Write方法实现生成磁盘的缓存文件，代码如下，在这些代码中，只有初始化构造函数，Write方法，Close方式是有用的，其中FileStream字段是生成静态文件的操作对象：

namespace ASPNET_CL.Code.HttpModules {  
    public class CommonFilter : Stream {  
        private readonly Stream _responseStream;  
        private readonly FileStream _cacheStream;  
 
        public override bool CanRead {  
            get {  
                return false;  
            }  
        }  
        public override bool CanSeek {  
            get {  
                return false;  
            }  
        }  
        public override bool CanWrite {  
            get {  
                return _responseStream.CanWrite;  
            }  
        }  
        public override long Length {  
            get {  
                throw new NotSupportedException();  
            }  
        }  
        public override long Position {  
            get {  
                throw new NotSupportedException();  
            }  
            set {  
                throw new NotSupportedException();  
            }  
        }  
 
        public CommonFilter( Stream responseStream, FileStream stream ) {  
            _responseStream = responseStream;  
            _cacheStream = stream;  
        }  
 
        public override long Seek( long offset, SeekOrigin origin ) {  
            throw new NotSupportedException();  
        }  
        public override void SetLength( long length ) {  
            throw new NotSupportedException();  
        }  
        public override int Read( byte[] buffer, int offset, int count ) {  
            throw new NotSupportedException();  
        }  
        public override void Flush() {  
            _responseStream.Flush();  
            _cacheStream.Flush();  
        }  
        public override void Write( byte[] buffer, int offset, int count ) {  
            _cacheStream.Write( buffer, offset, count );  
            _responseStream.Write( buffer, offset, count );  
        }  
        public override void Close() {  
            _responseStream.Close();  
            _cacheStream.Close();  
        }  
        protected override void Dispose( bool disposing ) {  
            if ( disposing ) {  
                _responseStream.Dispose();  
                _cacheStream.Dispose();  
            }  
        }  
    }  
}

然后我们利用正则完全删除ViewState：

// 过滤ViewState  
 private string ViewStateFilter( string strHTML ) {  
     string matchString1 = "type=\"hidden\" name=\"__VIEWSTATE\" id=\"__VIEWSTATE\"";  
     string matchString2 = "type=\"hidden\" name=\"__EVENTVALIDATION\" id=\"__EVENTVALIDATION\"";  
     string matchString3 = "type=\"hidden\" name=\"__EVENTTARGET\" id=\"__EVENTTARGET\"";  
     string matchString4 = "type=\"hidden\" name=\"__EVENTARGUMENT\" id=\"__EVENTARGUMENT\"";  
 
     string positiveLookahead1 = "(?=.*(" + Regex.Escape( matchString1 ) + "))";  
     string positiveLookahead2 = "(?=.*(" + Regex.Escape( matchString2 ) + "))";  
     string positiveLookahead3 = "(?=.*(" + Regex.Escape( matchString3 ) + "))";  
     string positiveLookahead4 = "(?=.*(" + Regex.Escape( matchString4 ) + "))";  
 
     RegexOptions opt = RegexOptions.IgnoreCase | RegexOptions.Singleline | RegexOptions.CultureInvariant | RegexOptions.Compiled;  
 
     Regex[] arrRe = new Regex[] {  
         new Regex("\\s*<div>" + positiveLookahead1 + "(.*?)</div>\\s*", opt),  
         new Regex("\\s*<div>" + positiveLookahead2 + "(.*?)</div>\\s*", opt),  
         new Regex("\\s*<div>" + positiveLookahead3 + "(.*?)</div>\\s*", opt),  
         new Regex("\\s*<div>" + positiveLookahead3 + "(.*?)</div>\\s*", opt),  
         new Regex("\\s*<div>" + positiveLookahead4 + "(.*?)</div>\\s*", opt)  
     };  
 
     foreach ( Regex re in arrRe ) {  
         strHTML = re.Replace( strHTML, "" );  
     }  
     return strHTML;  
 }

以下是删除页面空白的方法：

// 删除空白  
  private Regex tabsRe = new Regex( "\\t", RegexOptions.Compiled | RegexOptions.Multiline );  
 private Regex carriageReturnRe = new Regex( ">\\r\\n<", RegexOptions.Compiled | RegexOptions.Multiline );  
 private Regex carriageReturnSafeRe = new Regex( "\\r\\n", RegexOptions.Compiled | RegexOptions.Multiline );  
 private Regex multipleSpaces = new Regex( "  ", RegexOptions.Compiled | RegexOptions.Multiline );  
 private Regex spaceBetweenTags = new Regex( ">\\s<", RegexOptions.Compiled | RegexOptions.Multiline );  
 private string WhitespaceFilter( string html ) {  
     html = tabsRe.Replace( html, string.Empty );  
     html = carriageReturnRe.Replace( html, "><" );  
     html = carriageReturnSafeRe.Replace( html, " " );  
 
     while ( multipleSpaces.IsMatch( html ) )  
         html = multipleSpaces.Replace( html, " " );  
 
     html = spaceBetweenTags.Replace( html, "><" );  
 
     html = html.Replace( "//<![CDATA[", "" );  
     html = html.Replace( "//]]>", "" );  
 
     return html;  
 }

以下是删除ASP.NET控件的垃圾UniqueID名称方法：

        // 过滤NamingContainer  
private string NamingContainerFilter( string html ) {  
            RegexOptions opt =  
                RegexOptions.IgnoreCase |  
                RegexOptions.Singleline |  
                RegexOptions.CultureInvariant |  
                RegexOptions.Compiled;  
Regex re = new Regex( "( name=\")(?=.*(" + Regex.Escape( "$" ) + "))([^\"]+?)(\")", opt );  
html = re.Replace( html, new MatchEvaluator( delegate( Match m ) {  
                int lastDollarSignIndex = m.Value.LastIndexOf( '$' );  
if ( lastDollarSignIndex >= 0 ) {  
return m.Groups[ 1 ].Value + m.Value.Substring( lastDollarSignIndex + 1 );  
                }  
                else {  
                    return m.Value;  
                }  
            } ) );  
 
            return html;  
        }

最后，我们把以上过滤方法整合到CommonFilter类的Write方法：

public override void Write( byte[] buffer, int offset, int count ) {  
    // 转换buffer为字符串  
    byte[] data = new byte[ count ];  
    Buffer.BlockCopy( buffer, offset, data, 0, count );  
    string html = System.Text.Encoding.UTF8.GetString( buffer );  
 
    //  
    // 以下整合过滤方法  
     //  
 
    html = NamingContainerFilter( html );  
    html = ViewStateFilter( html );  
    html = WhitespaceFilter( html );  
 
    byte[] outdata = System.Text.Encoding.UTF8.GetBytes( html );  
 
    // 写入磁盘  
    _cacheStream.Write( outdata, 0, outdata.GetLength( 0 ) );  
    _responseStream.Write( outdata, 0, outdata.GetLength( 0 ) );  
}

五、缓存破坏

经过以上程序的实现，网页已经被高速缓存在客户端了，如果果用户访问网站被缓存过的页面，则页面会以0请求的速度加载页面。但是，如果后台更新了某些数据，前台用户则不能及时看到最新的数据，因此要改变这种情况，我们必须破坏缓存。根据我们如上的程序，我们破坏缓存只需要做2步：更新服务器上的临时文件，删除OutputCache过的页面。

更新服务器上的文件我们只需删除这个文件即可，当某一用户第一次访问该页面时会自动生成，当然，你也可以用程序先删除后生成：

// 更新文件  
foreach ( var file in Directory.GetFiles( HttpRuntime.AppDomainAppPath + "Temp" ) ) {  
    File.Delete( file );  
}

要删除OutputCache关联的缓存项，代码如下，我们只需要保证该方法的参数，指页面的绝对路径是正确的，路径不能使用../这样的相对路径：

// 删除缓存  
HttpResponse.RemoveOutputCacheItem( "/Default.aspx" );

到此，我们实现了针对一个页面的性能，重点是载入速度的提高的一些做法，希望对大家有用～！

本文链接