我们是否总是需要使用context.Server.MapPath？如果我缓存结果怎么办？

问题描述

| 我发现每次仅使用ѭ0来确定app_data文件夹下某个已知目录/文件的物理位置是很奇怪的。我的理解是，一旦应用程序运行，就必须先关闭它，然后才能更改其物理位置。如果是这样，那么我可以在application_start上缓存app_data的物理路径，并在其执行生命周期内使用缓存值！ 我需要专家对此事发表意见。我的假设正确吗？不重新启动应用程序就无法更改其物理路径，对吗？ 如果是这样，那么在每一个奇怪的方法中都必须将上下文作为参数包含进去，这将节省我很多时间！ 方法接口的清晰度对我来说最重要，而根本不适合。 顺便说一句，我正在使用共享主机，所以我无法控制应用程序的物理位置。这有关系吗？     

解决方法

        该路径是相对于当前请求的，因此对于不同URL的请求，“ 1”可能会有不同的结果。但是，如果您的路径是相对于应用程序根目录（

\"~/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中。