每当控制流离开页面派生的Web表单上的代码的时候，HttpContext类的静态属性Current可能是有用的。 使用这个属性，我们可以获取当前请求(Request)，响应(Response)，会话(Session,)和应用程序对象(Application objects)以及请求更多服务。 以下面的代码为例。
private void Page_Load(object sender, System.EventArgs e)
{
MyClass myClass = new MyClass();
myClass.DoFoo();
}
class MyClass
{
public void DoFoo()
{
HttpContext.Current.Response.Write("Doing Foo");
}
}
Context在同一个应用程序域中请求当前上下文的能力是强大的，但也可能被滥用。你可以从业务对象使用HttpContext.Current打破你的架构层的界限，并且很轻松地将类与ASP.NET结合，而Windows Forms和the Compact Framework PDA则无法应用于此场景。
HttpContext.Current是如何找到上下文当前请求。 此外，它总是能找到当前请求？ 例如，下面的代码的行为会是什么？
private void Page_Load(object sender, System.EventArgs e)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(DoWork));
}
public void DoWork(object state)
{
HttpContext context = HttpContext.Current;
context.Response.Write("Do Work");
}
答：上面的代码会生成一个System.NullReferenceException，因为HttpContext.Current返回null。从设计的角度来看，上面的代码至少存在两个问题，但是让我们讨论HttpContext.Current工作之前是如何工作的。
快速查看反编译器实现Current的属性看起来像下面这样。
public static HttpContext get_Current()
{
return (CallContext.GetData("HtCt") as HttpContext);
}
CallContext是类似于方法调用的线程本地存储区的专用集合对象，并提供对每个逻辑执行线程都唯一的数据槽。CallContext 为调用路径提供数据槽。CallContext.SetData 和 CallContext.GetData 可用于管理应用程序代码中的调用上下文槽。每一调用路径都有唯一的数据槽；也就是说，调用路径之间不共享状态。这些数据槽是命名过的，名称用于访问数据槽，使用该名称可以显式地释放数据槽。线程本地存储是一个概念，其中在一个应用程序域中的每个逻辑线程都有一个唯一的数据槽，以保持特定于自身的数据。 线程不共享数据，一个线程不能修改本地数据到另一个线程中。ASP.NET中，选择一个线程来执行传入的请求后，在本地的线程存储参考当前请求的上下文。现在，无论线程在哪执行（一个业务对象，数据访问对象），上下文时时存在方便检索。
知道了上面我们可以声明如下：如果在处理请求时，执行移动到不同的线程（通过QueueUserWorkItem，或异步委托，作为两个例子），当前背景下HttpContext.Current将不知道如何检索，将返回null。 你可能会认为解决这个问题的一种方法是将引用传递给工作线程，就像下面的例子。
private void Page_Load(object sender, System.EventArgs e)
{
WorkerClass2 worker = new WorkerClass2();
ThreadPool.QueueUserWorkItem(new WaitCallback(worker.DoWork), HttpContext.Current);
}
///………
class WorkerClass2
{
public void DoWork(object state)
{
HttpContext context = state as HttpContext;
Thread.Sleep(15000);
context.Response.Write("Request.Url = " + context.Request.Url);
}
}
然而，在我的环境中，上面的代码还抛出一个异常，虽然此异常来源于mscoree类库。 无论是上面的代码，并与QueueUserWorkItem第一个例子从另一个缺陷患：两者都可以活得比的页面请求的生命周期，也分配给该页面请求的HttpContext对象的有效寿命。 虽然我们可以保持一个参考的任何要求，以防止垃圾回收器把它的HttpContext，ASP.NET运行时肯定是自由的，只要页面请求处理完成清除一些资源。 我不相信有反正说会与上面的代码会发生什么，在不同的情况下，代码可以实际工作的一些机器，但失败的几率确实存在，并应避免的条件。
有一些方法可以保证页面请求没有完成，直到工作线程完成其工作，例如，下面的代码。
private void Page_Load(object sender, System.EventArgs e)
{
WorkerClass worker = new WorkerClass(_resetEvent);
ThreadPool.QueueUserWorkItem(new WaitCallback(worker.DoWork),
HttpContext.Current);
try
{
_resetEvent.WaitOne();
}
finally
{
_resetEvent.Close();
}
}
AutoResetEvent _resetEvent = new AutoResetEvent(false);
…
class WorkerClass
{
public WorkerClass(AutoResetEvent resetEvent)
{
_resetEvent = resetEvent;
}
public void DoWork(object state)
{
try
{
HttpContext context = state as HttpContext;
Thread.Sleep(500);
context.Response.Write("Do work");
}
finally
{
_resetEvent.Set();
}
}
AutoResetEvent _resetEvent = null;
}
上面的代码能正常的工作在浏览器中。 然而，设计仍然存在一些疑虑。 首先，ASP.NET运行时处理多个请求的时候，它的线程使用数量有限。 我们刚刚完成相同数量的工作，但我??们已经增加了一倍所需的线程数，产生额外的上下文切换，和现在有一个同步原语来管理。 当等待工作任务完成，在原始线程执行额外的工作，则可能是一个好处。 然而，一般来说，你更应该使用额外的线程在ASP.NET中使用一定量的保留的做法。
在这篇文章中，我们已经深入了解HttpContext.Current是如何工作的，并看到了一些场景，我们需要谨慎行事。 不要滥用HttpContext.Current，每当调用在代码调用它的时候，应多检查您的设计架构。
慎用System.Web.HttpContext.Current,布布扣,bubuko.com