HttpContext 类

最新推荐文章于 2019-02-28 15:35:00 发布

auroralr

最新推荐文章于 2019-02-28 15:35:00 发布

阅读量1.5k

点赞数

分类专栏： .Net 文章标签： asp.net 单元测试 cache 测试 delete action

本文链接：https://blog.csdn.net/auroralr/article/details/5896419

版权

.Net 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

HttpContext 类:封装有关个别 HTTP 请求的所有 HTTP 特定的信息.也有人叫上下文信息.

1.生存周期:从客户端用户点击并产生了一个向服务器发送请求开始---服务器处理完请求并生成返回到客户端为止.
注:针对每个不同用户的请求,服务器都会创建一个新的HttpContext实例直到请求结束,服务器销毁这个实例.

2.为什么会有HttpContext类呢:在ASP年代,大家都是通过在.asp页面的代码中使用Request,Respose,Server等等这些Http特定信息的.但在ASP.NET时代,这中方式已经无法满足应用,(比如我们要在IHttpModule中处理Request时,我们使用什么方法来获取呢?于是就产生了HttpContext类,它对Request,Respose,Server等等都进行了封装,并保证在整个请求周期内都可以随时随地的调用.)

3.特殊性:当然HttpContext不仅仅只有这点功能.ASP.NET中它还提供了很多特殊的功能.例如Cache.还有HttpContext.Item,通过它你可以在HttpContext的生存周期内提前存储一些临时的数据,方便随时使用.

打个不是很适当的比方:
参加奥运会比赛的运动员一般都会有礼仪小姐来领路, 就拿体操全能比赛来说吧, 从进赛场的那一该起, 礼仪小组就带领运动员到不同的项目地点参加比赛(如先比双扛, 再比跳马, 然后比自由操...), 在整个过程中, 礼仪小姐一直在你身边, 尽管她不参加比较, 在比赛的过程中你有什么问题或困难可以与她交流(比方说:要求她给你提供饮用水, 要求好给你保管衣物, 问她比赛的一些问题等等), 当所有的比较项目结束的时候, 礼仪小姐又会把你带出赛场, 这时候, 她的任务就完成了.

这里,礼仪小姐就好比是当前请求的HttpContext, 它保存了请求过程中的一些信息(如Response, Request), 你可能通过HttpContext来访问相关的信息. 从CLR接收到请求的那一刻开始, HttpContext就创建了, 它将贯穿请求的整个过程. 在CLR处理ASP.NET请求的过程中, 你可以通过HttpContext访问相关的信息(如:Request, Response)等, 也可以在请求的各个阶段创建相关的信息保存在HttpContext中.

==================================================================================================

　　在ASP.NET中进行单元测试的天敌便是HttpContext，它是ASP.NET的核心，极端复杂，却无法进行Mock1——可见微软能够写出那么庞大的ASP.NET框架真不那么容易。现在这

个状况改善了不少，因此大家已经可以使用System.Web.Abstractions.dll了，这个程序集中提供了对于HttpContext的抽象，也就是HttpContextBase抽象类。因此在ASP.NET MVC中，各种组件均依赖于HttpContextBase而不是HttpContext。这是一个优秀的做法，大家以后可以尽可能地摆脱HttpContext了。

　　不过这似乎又是一个悖论。虽然已经可以对HttpContext进行Mock（这点增强了可测试性），但是过度依赖HttpContext对于单元测试来说也是一个伤害。这是HttpContext对象的天性所致：它实在太复杂了。您应该已经察觉到，这是个集万千宠爱于一身的对象，从请求，回复，应用程序，缓存……几乎包含了Web应用程序需要的所有信息。如果要测试一个依赖于HttpContext的方法，您势必要为HttpContext的Mock对象填充各种信息——其复杂程度视业务而定。而且，Mock关注的是“行为”，也就是说它关注的是做一件事情所使用“路径”。那么如果做一件事情可以采用多个路径又会怎样？是否需要在测试之前准备好所有的路径，并且验证被测试的代码“采用了，并仅仅采用了其中一条路径”？因此，Stub慢慢进入人们的视线。Stub关注的是“状态”……这就是另一个话题了，还会涉及到采用Record & Replay还是Arrange-Act-Assert方式来进行单元测试，暂且不提。

　　之前谈到对视图进行单元测试时，老赵曾经谈起在视图中应该只使用ViewData中的数据。这不是第一次说起要放弃HttpContext了，自从有了“抽象”这一有利武器后，一切“不和谐”因素都能够被分离。试想在MVP模式中，View和Presenter都使用各自的抽象进行交互，一切Web控件，HttpContext等对象都不复存在了，大家眼中只有“数据”和“模型”。同样，在ASP.NET MVC的Action方法中，也不应该使用HttpContext，这是基于良好的“可测试性”而考虑的。您可能会想，现在的HttpContextBase对象已经可以Mock了啊。没错，它的确“可以”，但是这样做会引起单元测试代码的膨胀，因为测试代码中的相当部分必须关注在测试数据的准备，而不是被测试的功能上。对于一个Action方法来说，它关注的应该是用户与业务逻辑的交互，而不是“如何把HTTP请求转化为可用的数据”。其实说到底，还是要“分离关注点”。

　　在ASP.NET MVC中负责“转化数据”的层次为Model Binder。关于这一点，现有的“示例”大都关注把Form或QueryString中的数据转化为Action参数上，不过Model Binder可用的地方其实更多。例如在《最佳实践》的代码中，原本AccountController的Delete方法实现如下：

public ActionResult Delete(string userName)
{
this.MiddleTier.UserManager.Delete(userName);

Uri urlReferrer = this.Request.UrlReferrer;
return this.Redirect(urlReferrer.ToString());
}
　　在删除了指定对象之后，页面将跳转到Url Referrer地址中。在上面的代码中，这个值将通过访问Request.UrlReferer来获得。这就使您的Action方法与HttpContext产生了依赖，因此它的单元测试代码就需要这样编写：

[TestMethod]
public void DeleteTest()
{
string userName = "jeffz";
Uri urlReferrer = new Uri("http://www.microsoft.com");

var mockHttpContext = new Mock<HttpContextBase>();
mockHttpContext.Setup(c => c.Request.UrlReferrer).Returns(urlReferrer);

    var mockController = this.GetMockController();
    mockController.Setup(c => c.MiddleTier.UserManager.Delete(userName)).Verifiable();
    mockController.Object.ControllerContext = new ControllerContext(
        mockHttpContext.Object, new RouteData(), mockController.Object);

mockController.Object.Delete(userName)...
}
　　在单元测试代码中，我们Mock了一个HttpContextBase对象，让它的Request.UrlReferrer属性返回我们准备好的对象，再构造一个新的ControllerContext并交给Controller。而如果我们的UrlReferrer能够作为Delete方法的参数，那么单元测试代码就会一下子简单很多：

[TestMethod()]
public void DeleteTest()
{
string userName = "jeffz";
Uri urlReferrer = new Uri("http://www.microsoft.com");

var mockController = this.GetMockController();
mockController.Setup(c => c.MiddleTier.UserManager.Delete(userName)).Verifiable();

mockController.Object.Delete(userName, urlReferrer)...
}
　　有些朋友可能会问，不就是从Request的UrlReferrer属性中取值吗？我们为什么要构造一个ControllerContext，不能直接设置Controller对象吗？例如这样就简单多了：

mockController.Setup(c => c.Request.UrlReferrer).Returns(urlReferrer);
　　似乎可行，不过您运行的时候就会发现，框架会抛出异常，说只有接口的成员，或可以override的成员才能够被Mock。没错，Controller的Request属性不是virtual的，无法override。Controller类如此设计是故意的，目的就是限制了可用的路径。试想，如果您Mock了Controller.Request属性，但是程序代码通过Controller.HttpContext.Request进行访问又怎么办呢？类似的做法还有对方法重载的设计。一般来说，都会把其中几个方法委托给其中唯一的方法，而只有那个方法是可以被override的。这样在编写测试时，我们仅有的Mock入口便确定了，避免了测试代码过度了解方法实现的问题。

　　回到正题。如果要让Delete方法接urlReferrer受参数，那么我们就要编写Model Binder相关的组件：

public class UrlReferrerModelBinder : IModelBinder
{
    public object BindModel(
        ControllerContext controllerContext,
        ModelBindingContext bindingContext)
    {
        return controllerContext.HttpContext.Request.UrlReferrer;
    }
}
　　并使其可以直接运用到Action的参数上：

public class UrlReferrerAttribute : CustomModelBinderAttribute
{
private static UrlReferrerModelBinder s_modelBinder =
new UrlReferrerModelBinder();

    public override IModelBinder GetBinder()
    {
        return s_modelBinder;
    }
}
　　于是乎，我们的Delete方法便可写为：

public ActionResult Delete(string userName, Uri urlReferrer)
{
this.MiddleTier.UserManager.Delete(userName);
return this.Redirect(urlReferrer.ToString());
}
　　如今的代码，无论是应用程序还是框架类库，都必须考虑“可测试性”这个要求。例如.NET 3.0的WF，由于其可测试性不佳一直为人所诟病。现在我们在编写程序时，要时刻询问自己：“这么做方便测试吗？”考虑到这个问题，可能您就会放心地做出某些抉择了2。

注1：其实还是可以Mock的。例如Typemock使用Profiler的方式进行直接注入，可以Mock任何成员。不过，如果Moq等框架无法满足您的需要，一般便是您的设计有些问题了。

注2：例如，究竟让Action方法返回ActionResult，还是返回void，并直接通过Response输出呢？

HttpContext.Cache和HttpRuntime.Cache
Asp.Net中可以方便的使用缓存，对于Cache，一般有两种方式调用：HttpContext.Cache和HttpRuntime.Cache。那么这两种Cache有什么区别呢？
先来看看Msdn上的注释：
HttpRuntime.Cache：获取当前应用程序的 Cache。
HttpContext.Cache：为当前 HTTP 请求获取 Cache 对象。
那么是不是说对于HttpRuntime.Cache就是应用程序级，而HttpContext.Cache则是针对每个用户的呢？NO，而实际上，两者调用的是同一个对象。他们的区别仅仅在于调用方式不一样（就我所知）。
事实胜过雄辩，写个例子来证实一下（限于篇幅仅贴出关键代码，完整代码见附件WebDemo.rar）：
        /// <summary>
        /// 通过HttpRuntime.Cache的方式来保存Cache
        /// </summary>
        private void btnHttpRuntimeCacheSave_Click(object sender, System.EventArgs e)
        {
            HttpRuntime.Cache.Insert(cacheKey, cacheValue, null, DateTime.Now.AddMinutes(3), TimeSpan.Zero);
        }

        /// <summary>
        /// 通过HttpRuntime.Cache的方式来读取Cache
        /// </summary>
        private void btnHttpRuntimeCacheLoad_Click(object sender, System.EventArgs e)
        {
            if (HttpRuntime.Cache[cacheKey] == null)
            {
                cacheContent = "No Cache";
            }
            else
            {
                cacheContent = (string)HttpRuntime.Cache[cacheKey];
            }
            lblCacheContent.Text = cacheContent;
        }

        /// <summary>
        /// 通过HttpContext.Cache的方式来保存Cache
        /// </summary>
        private void btnHttpContextCacheSave_Click(object sender, System.EventArgs e)
        {
            HttpContext.Current.Cache.Insert(cacheKey, cacheValue, null, DateTime.Now.AddMinutes(3), TimeSpan.Zero);
        }

        /// <summary>
        /// 通过HttpContext.Cache的方式来读取Cache
        /// </summary>
        private void btnHttpContextCacheLoad_Click(object sender, System.EventArgs e)
        {
            if (HttpContext.Current.Cache[cacheKey] == null)
            {
                cacheContent = "No Cache";
            }
            else
            {
                cacheContent = (string)HttpContext.Current.Cache[cacheKey];
            }
            lblCacheContent.Text = cacheContent;
        }
通过这个例子可以很容易证明：
HttpContext.Cache保存的Cache，HttpContext.Cache和HttpRuntime.Cache都可以读取。
HttpRuntime.Cache保存的Cache，HttpContext.Cache和HttpRuntime.Cache都可以读取。
无论是哪个用户通过什么方式对Cache的改变，其他用户无论用什么方式读取的Cache内容也会随之变。