我们总是需要使用上下文吗.Server.MapPath?如果我缓存结果会怎样

本文关键字：如果 缓存 结果 MapPath Server 上下文 我们 | 更新日期: 2023-09-27 17:58:09

我觉得每次使用context.Server.MapPath只是为了确定app_data文件夹下某个已知目录/文件的物理位置很奇怪。我知道，一旦一个应用程序运行，如果不首先关闭它，就不可能更改它的物理位置。如果这是真的，那么我可以在application_start上缓存app_data的物理路径，并在其执行寿命中使用缓存值！

我需要专家对此事发表意见。我的假设正确吗？在不重新启动应用程序的情况下，不可能更改应用程序的物理路径，对吧？

如果这是真的，这将为我节省大量时间，而不必在每个奇数方法中都将上下文作为参数！

方法接口的清晰性对我来说是最重要的，并且<上下文>就是不适合这样。

顺便说一句，我使用共享主机，所以我无法控制应用程序的物理位置。这有关系吗？

我们总是需要使用上下文吗.Server.MapPath?如果我缓存结果会怎样

路径是相对于当前请求的，因此MapPath("foo")可能会对不同url的请求产生不同的结果。然而，如果你的路径是相对于应用程序根目录（"~/foo"）或相对于网站根目录（"/foo"）的，你几乎可以随心所欲地缓存。

可能存在一种边缘情况，即人们在执行过程中在IIS中添加虚拟目录，但这几乎不可能，而且无论如何都会造成痛苦。

如果我是你，我不会缓存任何东西，因为我不相信缓存会让任何东西更快。或者，如果速度更快，那大约是几纳秒。

关于你传递上下文的问题，这是因为你的设计。

我会重构我的代码，创建一个执行IO操作的单点，即IOHelper类，并在那里缓存上下文。

我认为您不必将上下文作为参数传递。总是有可能使用

 HttpContext.Current.Server.MapPath("~/...");

这比将变量存储在缓存中更容易。

编辑：如果你真的认为这样的调用会很昂贵，那么创建一个Singleton类应用程序，该应用程序具有一个可以存储根路径的属性，例如：

public class Application
{
  private static string _rootPath = HttpContext.Current.Server.MapPath("~");
  public static string RootPath
  {
      get { return _rootPath; }
  }
}

你可以从任何地方访问你的根。您也可以将此代码放在global.asax中。

相关文章：