可以欺骗HTTPContext.Current？

Question

我在程序集中有这行代码：

 HttpContext.Current.Server.MapPath

如果在Web服务中使用程序集，则此方法很有用。

但是如果我把它从Web服务中取出，那么它通常不起作用，因为HTTPContext不存在。

是否有可能欺骗httpContext认为它存在，真的只是为了获得目录的相对路径结构？

我的意思是以某种方式手动创建HTTPContext对象，并为其分配一个基本目录？

更新

是否有更通用的方法：HttpContext.Current.Server.MapPath

可以在可执行文件中使用的东西，以及可以在Web上运行的东西吗？

Answer 1

HttpContext.Current“获取或设置 HttpContext对象”。 HttpContext有一个公共构造函数，它接受一个HttpWorkerRequest（抽象，使用SimpleWorkerRequest），你就可以完全伪造HttpContext。

我同意其他人的意见，你可以重构你的代码以消除这种依赖关系，但有些情况下你必须伪造HttpContext.Current的东西，在这种情况下，如果你搜索这个问题就会显示...

Answer 2

我觉得你需要在另一个对象中包含对HttpContext的调用，然后你可以在正确的环境中使用IOC切换出正确的对象。例如。像IMapPath这样的接口，然后你的实现可能是HttpMapPath或ConsoleAppMapPath等。

Answer 3

在编写使用HttpContext.Current的单元测试时，我们会做类似的事情。我们有一个名为IHttpContext的接口，它包含了普通HttpContext所需的一切。然后，我们有一个扩展方法（HttpContext.Current.Make（）），而不是调用HttpContext.Current，它返回这个IHttpContext接口。

在扩展方法中，我们可以决定HttpContext.Current是否可用，如果不可用，那么我们就可以手动建立一个“Testable”对象并返回它。

当然，如果您正在使用它们，我们必须编写IRequest，IResponse等对象，但我认为这是可以预期的

Answer 4

不确定这是否会有所帮助，但在为asp.net网络应用程序编写单元测试时遇到了类似的问题。在其中一个api调用中的某个时刻，属性由HttpContext.Current.XXXXX设置，该属性不在范围内。我发现答案是将以下属性添加到我的单元测试中：

[TestMethod的（）]
[HOSTTYPE（ “ASP.NET”）]
[UrlToTest（ “http://mytestsite.com/Home.aspx”）]

original article

Answer 5

此类代码是特定于网站的。我觉得为什么它属于商业逻辑。

可能重新考虑此代码将从业务逻辑中排除HttpContext将是最佳解决方案。例如，您可以接受文件路径作为方法参数，而不是在业务逻辑中解析它。