HttpContextWrapper 真的那么有用吗？

Question

我一直在清理控制器代码以使每个操作都可测试。一般来说，这并不太困难——当我们有机会使用固定对象时，比如 FormsAuthentication，我们通常会适当地引入某种形式的包装器，然后就可以愉快地进行了。

由于与本次对话不太相关的原因，在处理 HttpContext 的使用时，我们决定使用新创建的 HttpContextWrapper 类，而不是发明一些自行开发的类。我们确实引入的一件事是交换 HttpContextWrapper 的能力（例如，用于单元测试）。这完全受到 Oren Eini 使用 DateTimes 处理单元测试的方式的启发 (参见文章，我们也使用这种模式）

public static class FooHttpContext
{
    public static Func<HttpContextWrapper> Current = () 
         => new HttpContextWrapper(HttpContext.Current);

    public static void Reset()
    {
        Current = () => new HttpContextWrapper(HttpContext.Current);
    }
}

没有什么特别奇特的。它在我们的控制器代码中运行得很好。当我们去编写单元测试时，问题就来了。我们使用 Moq 作为我们的模拟框架，但可惜的是，

var context = new Mock<HttpContextWrapper>() 

由于 HttpContextWrapper 没有无参数构造器，所以中断了。它需要什么作为 ctor 参数？一个 HttpContext 对象。所以我发现自己陷入了第 22 条陷阱。

我正在使用规定的方式来解耦 HttpContext，但我无法模拟其中的值，因为原始 HttpContext 对象是密封的，因此难以测试。我可以映射 HttpContextBase，它们都派生自——但这并不能真正让我得到我想要的东西。我是否只是错过了有关 HttpContextWrapper 的要点？

编辑以澄清意图

我们找到了解决问题的方法 - 但我想我们要解决的最终问题是 HttpContextWrapper 给桌面带来了什么价值？我不怀疑某个地方有人完全惊叹不已！但我就是想不起来。我在这里看到的大多数帖子都从可测试性的角度讨论它——但我自己的经验让我相信它在这方面并没有带来太多好处。除非我们做错了。 （完全有可能）。

Answer 1

这篇博文很好地解释了这一点：

http://splinter.com.au/httpcontext -vs-httpcontextbase-vs-httpcontext

要点是“老式”HttpContext 不实现 HttpContextBase，并且不是虚拟的，因此不能被 Mocked。 HttpContextBase 在 3.5 中作为可模拟的替代方案引入。但仍然存在一个问题，即老式 HttpContext 没有实现 HttpContextBase。

因此 HttpContextWrapper 是一个方便的包装类（或“kludge”），它实现了 HttpContextBase，并且可以在使用 IOC 注入“真实”HttpContext 时使用，通常使用如下工厂方法：新的 HttpContextWrapper(HttpContext.Current)

Answer 2

您应该使用抽象的 HttpContextBase ，它比 HttpContextWrapper 更容易模拟。

public static Func<HttpContextBase> Current = 
    () => new HttpContextWrapper(HttpContext.Current);

在你的单元测试中：

SomeClass.Current = MockHttpContextBase(); // Sorry I don't know the syntax for Moq

Answer 3

除了测试之外，还有一个现实世界的例子。
除了嘲笑之外，我偶然发现了一个特殊的问题，包装类确实帮助我解决了这个问题。我们在 Azure 中有一个应用程序，并且我们只能控制该应用程序。它位于反向代理后面，该代理更改传入请求的主机标头并在自定义标头中发送原始主机。应用程序依赖主机标头来构建动态链接、验证重定向等。因此我们需要一种方法来替换 HttpContext.HttpRequests.Url 属性中设置的主机。由于我们仅使用应用程序中各处的包装器将 HttpContext 公开为 HttpContextBaase，因此我们能够创建一个继承 HttpContextWrapper 并覆盖 Request 的类，然后返回从 RequestWrapper 继承并覆盖 Url 属性的对象。因此，最终应用程序将 ASP.NET 用于上下文的 url 中的主机替换为反向代理设置的自定义标头中的自定义主机。除了手动搜索使用 HttpContext.Request.Url 的代码并应用修复之外，应用程序内没有其他方法可以做到这一点。