Pros/cons of reading connection string from physical file vs Application object (ASP.NET)?

Question

my ASP.NET application reads an xml file to determine which environment it's currently in (e.g. local, development, production).

It checks this file every single time it opens a connection to the database, in order to know which connection string to grab from the Application Settings.

I'm entering a phase of development where efficiency is becoming a concern. I don't think it's a good idea to have to read a file on a physical disk ever single time I wish to access the database (very often).

I was considering storing the connection string in Application["ConnectionString"]. So the code would be

public static string GetConnectionString
        {
            if (Application["ConnectionString"] == null)
            {
                XmlDocument doc = new XmlDocument();
                doc.Load(HttpContext.Current.Request.PhysicalApplicationPath + "bin/ServerEnvironment.xml");
                XmlElement xe = (XmlElement) xnl[0];

                switch (xe.InnerText.ToString().ToLower())
                {
                    case "local":
                        connString = Settings.Default.ConnectionStringLocal;
                        break;

                    case "development":
                        connString = Settings.Default.ConnectionStringDevelopment;
                        break;

                    case "production":
                        connString = Settings.Default.ConnectionStringProduction;
                        break;

                    default:
                        throw new Exception("no connection string defined");
                }
                Application["ConnectionString"] = connString; 
            }
            return Application["ConnectionString"].ToString();
        }

I didn't design the application so I figure there must have been a reason for reading the xml file every time (to change settings while the application runs?) I have very little concept of the inner workings here. What are the pros and cons? Do you think I'd see a small performance gain by implementing the function above?

THANKS

Answer 1

Wow. Throw that in the bin.

All .config files (web or app.config) have a section dedicated to connection strings and these can be read using the ConfigurationManager.ConnectionStrings property.

For local and test environments, I simply set up three connection strings as follows

<connectionStrings>
    <add name="default.local" connectionString="etc ..>
    <add name="default.test" connectionString="etc ..>
    <add name="default" connectionString="etc ..>
</connectionStrings>

Determine which connection stirng to fetch based on another setting in the config file. A small utility function utilises this information to pick the correct connection string.

In this way, the config file stays the same across the different deployments apart from the environment setting.

EDIT: forgot to mention these values are cached in memory and the app restarts when they are changed (may be a problem, may be useful) Performance is absolutely fine going directly to the .config file through the ConfigurationManager class.

Answer 2

I totally agree with James Westgate. If you use the web.config, you don't have to take care about this issue.

In case that you can't use the web.config for any reason I would say that your approach is correct. Storing the value on the Application storage you're avoiding to read the connections string over and over again from disk.

If you need to change the connection string, you would have to restart the application. A connection string is not supposed to change everyday so this shouldn't be a problem.

BTW: I don't like very much the logic asking in which environment you are. That shouldn't be necessary at all...