3

context.Server.MapPath我发现每次都使用它来确定 app_data 文件夹下某些已知目录/文件的物理位置很奇怪。我的理解是，一旦应用程序运行，如果不先将其关闭，就不可能更改其物理位置。如果这是真的，那么我可以在 application_start 上缓存 app_data 的物理路径，并将缓存值用于其执行生命周期！

我需要专家对这个问题的意见。我的假设对吗？没有重新启动应用程序的物理路径是不可能的，对吧？

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

方法接口的清晰对我来说是最重要的，而 <context> 不适合这一点。

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

4

3 回答 3

1

该路径是相对于当前请求的，因此MapPath("foo")在不同 url 的请求上可能会产生不同的结果。但是，如果您的路径是相对于 app-root ( "~/foo") 或相对于 site-root ( "/foo") 的，那么您几乎可以缓存到您心中的内容。

可能存在人们在执行期间在 IIS 中添加虚拟目录的极端情况，但这几乎不可能，而且无论如何都会引起痛苦。

于 2011-05-31T18:04:28.823 回答
0

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

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

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

于 2011-05-31T18:39:21.910 回答
0

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

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

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

编辑：如果您真的认为这样的调用成本很高，请创建一个具有可以存储根路径的属性的单例类应用程序，例如：

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

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

于 2011-05-31T18:12:19.417 回答