Configuration question: sharing connection string for modules in app.config best practice

Question

I have connection string declared in [app|web].config and assemblies (for example DAL and Reporting) that relies on this connection string. What is the best thing for you to configure such assemblies:

• Use hard-coded connection string name in [app|web].config connectionStrings section to let assembly retrieve it's configuration by hard-coded name. So there possibly would be two identical connection strings: "reportingServer" and "dataSource".

• Use the only connection string in connectionStrings section with any name you like and configure DAL|Reporting assemblies to use this name via custom configuration sections. Now assemblies retrieve connection string name to use and then connection string data.

• Configure connection string name via AppSettings hard-coded key. For example you should always have "reportingServerConnectionStringName" & "dataSourceConnectionStringName" keys in this case.

• Something better what I missed...

Thank you in advance!

Answer 1

You may look at this question for good practices:
http://stackoverflow.com/questions/619276/connection-string-best-practices

Also, Enterprise Connection String Management in ASP.NET - Best Practice
http://weblogs.asp.net/jgalloway/archive/2004/05/11/129941.aspx

Hope it helps!

//Edit: Added the following

The primary advantage of having Config files is exactly the scenario that you are dealing with (multiple projects and centralised configuration).

Either ways, you would need to hard-code some information for your assemblies to be able to extract the required information from App/Web config.

For my practical purposes, I usually keep two connection strings ("reportingServer" and "datasourceServer") and if need be to make them dynamic, have two AppSettings keys to load the required connection strings dynamically.

A simple but effective way to enable dynamic loading of connection strings.

<appSettings>
<add key="reportingServer" value="reportingServerDev"/>
<add key="dataSourceServer" value="dataSourceServerDev"/>
</appSettings>
<connectionStrings>
<add name="reportingStaging" connectionString="proper connection string"/>
<add name="reportingDev" connectionString="proper connection string"/>    
<add name="dataSourceStaging" connectionString="proper connection string"/>
<add name="dataSourceDev" connectionString="proper connection string"/>
</connectionStrings>

Hope this time i answered in the correct context.

Happy Configuring!

Answer 2

There is generally two ways I've handled connection strings. The first way is the way you have listed in your first bullet point.

The advantages are:

• It's easy
• If assemblies use the same connection string name, you can get reuse

The disadvantages are:

• The names are fixed
• If you don't want the same connection for the same name, you're then stuck - although overriding/using add & remove elements might help in this case, but I've not tested it

The other technique I use is the same as the provider model used by ASP.NET Membership,etc

<configuration>
  <connectionStrings>
    <add name="SqlServices" connectionString="Data Source=localhost;Integrated Security=SSPI;Initial Catalog=aspnetdb;" />
  </connectionStrings>
  <system.web>
    <membership defaultProvider="SqlProvider">
      <providers>
        <add 
          name="SqlProvider" 
          type="System.Web.Security.SqlMembershipProvider" 
          connectionStringName="SqlServices"
          moreSettings="... other settings ..."  />
      </providers>
    </membership>
  </system.web>
</configuration>

The advantages are:

• You can reuse connection strings across multiple components
• Connection string names are not hard coded in your assemblies
• This approach is much more flexible

The disadvantages are:

• A lot more work to set up - sometimes overkill for a small project
• Requires an understanding of how to set up configuration sections and providers (not necessarily a bad thing, they're damn useful sometimes)
• The configuration file can become a lot more verbose.