Let's assume you wish to store your database connection string in the <connectionStrings> configuration section of Web.config. This is the best practice in my opinion because you can (and should) encrypt the section in production. Now you have two basic options:

(1) fetch the connection string at the UI level and pass it back to the data layer.

(2) remove the dependency altogether and let the data layer fetch it from Web.config

I've done it both ways. With option (1) you have a simple call to the ConfigurationManager:

string connectionString = ConfigurationManager.ConnectionStrings["FooBar"].ConnectionString;

Most people do this and it's quick and simple. If you don't want the coupling or you don't feel like parameter passing or you want your unit test assembly to be able to get a connection string without needing to reflect over the UI assembly, then option (2) involves creating a helper method that any assembly in your solution can call. Here's one that opens a config file from an explicit virtual root location and returns a string value that matches the passed in key:

public static string GetConnectionString(string connectionName) {

    string connectionString = string.Empty;

    // reading from explicit IIS virtual root alias name rather than "~"

    Configuration c = WebConfigurationManager.OpenWebConfiguration(@"\Widget");

    if (c != null) {

        ConnectionStringsSection section = c.GetSection("connectionStrings") as ConnectionStringsSection;

        foreach (ConnectionStringSettings css in section.ConnectionStrings) {

            if (css.Name.ToUpper().CompareTo(connectionName.ToUpper()) == 0) {

                connectionString = css.ConnectionString;

                break;

            }

        }

    }

    return connectionString;

} 

Then it's pretty simple to fetch a connection string from your DAL layer: 

string connectionString = GetConnectionString("FooBar");

SqlConnection cn = new SqlConnection(connectionString);

Here's my own solution to a problem that seems to plague a lot of .NET developers out there. The problem is how best to enumerate application settings stored in a section of an ASP.NET 2.0 app.config file at runtime. Let's suppose you have a settings file called Color.settings with the following key-value pairs:

BLU - Blue
BRO - Brown
GRN - Green
HAZ - Hazel

The designer stores those settings in app.config. It also creates the getters for each key and decorates them with the value:

[global::System.Configuration.ApplicationScopedSettingAttribute()]

[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]

[global::System.Configuration.DefaultSettingValueAttribute("Blue")]

public string BLU {

    get {

        return ((string)(this["BLU"]));

    }

}

In this way the Color class is strongly-typed and, given a code, makes it easy to fetch its value through the settings property:

string color = Color.Default.BLU;

But what if you don't know the key at design time? Fortunately, the singleton instance exposed by the Color.settings class implements ApplicationSettingsBase Properties. Reference System.Configuration and simply enumerate the SettingsPropertyCollection to find the value:

string key = "BLU";

string value = string.Empty;

foreach (SettingsProperty sp in Color.Default.Properties) {

    if (sp.Name.Equals(key)) {

        value = sp.DefaultValue.ToString();

        break;

    }

}

Usually custom SiteMap providers are written because we're pulling our nodes from a source other than xml. Jeff Prosise's provider written for SQL Server is a classic example. But I had a case recently in which the out of the box XmlSiteMapProvider was just fine; my problem was that I needed to do some peculiar security trimming on the nodes. No problem, just add roles to the nodes and enable security trimming in Web.config for the provider right? Not exactly. The requirements were that the system had to ship with the ability to turn a major piece of functionality on or off in production. Let's call the functionality "ViewWidgets" and let's say there's an app setting in Web.config called "ViewWidgets" with value="false". That means, the web site should suppress the Widgets unless and until it is flipped to true. Then Widgets should be available to the end user. One way of implementing this would have been to set a generic role or override Web.config in a subfolder. But I wanted the webmaster to be able to flip the flag to true or false in Web.config where he was more comfortable working. The solution turns out to be pretty easy. Just derive a custom provider from XmlSiteMapProvider and override the Initialize method to trim the node based on the app setting:

[AspNetHostingPermission(SecurityAction.Demand, Level = AspNetHostingPermissionLevel.Minimal)]

public class CustomSiteMapProvider : XmlSiteMapProvider {

    const string VIEW_WIDGET_KEY = "ViewWidgets";

    public override void Initialize(string name, System.Collections.Specialized.NameValueCollection attributes) {

        lock (this) {

            base.Initialize(name, attributes);

            bool viewWidget = Convert.ToBoolean(AppSettingHelper.GetAppSetting(VIEW_WIDGET_KEY));

            if (!viewWidget) {

                foreach (SiteMapNode childNode in base.RootNode.ChildNodes) {

                    if (childNode.ResourceKey.ToUpper().Equals("WIDGET")) {

                        base.RemoveNode(childNode);

                        break;

                    }

                }

            }

        }

    }

}

In this case I've encapsulated calls to AppSettings in an AppSettingHelper class. And of course you have to register your custom provider in the <system.web> section of Web.config. And that's about it.