Geek asks and answers

Do we always need to use context.Server.MapPath? what if i cache the result?

It seems strange to me to use context.Server.MapPatheach time only to determine the physical location of any known directory / file in the app_data folder. I have an understanding that after starting the application it should not be possible to change your physical location without disconnecting it first. If so, I can cache the physical path app_data on application_start and use the cache value for its runtime!

I need expert opinion on this. Is my assumption correct? there is no way to change the physical path of the application without restarting, right?

If so, it will save me time to include context as a parameter in every odd method!

The clarity of the method interface is most important to me, and <context> just doesn't fit into that.

By the way, I use shared hosting, so I have no control over the physical placement of the application. Does it matter?

+3
source share
3 answers

The path refers to the current request, so it MapPath("foo")may have a different result for requests at different URLs. However, if your path is relative to the root application ( "~/foo") or relative to the root of the site ( "/foo"), you can pretty much cache the contents of your heart.

There may be a brief case scenario for people adding virtual directories inside IIS at runtime, but this is disappearingly unlikely and will be very painful anyway.

+1

, .

 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.

0

, , , - . , .

, - .

, -, .. IOHelper, .

0

More articles:


All Articles