Programmatically change the connection string in web.config file.

Let’s say you have the below connection string in your web.config file and you need to change that dynamically.

<add name="DefaultConnection"
connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\test.mdf;
Initial Catalog=test;Integrated Security=True"

providerName="System.Data.SqlClient" />

You can use the below code to change the connection string programmatically.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Web;
using System.Configuration;
using System.Web.Configuration;
using System.Web.Services;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace ForumsTest
public partial class WebForm1 : System.Web.UI.Page
protected void Page_Load(object sender, EventArgs e)
Configuration config = WebConfigurationManager.OpenWebConfiguration("~");
ConnectionStringsSection sec = (ConnectionStringsSection)config.GetSection("connectionStrings");
sec.ConnectionStrings["DefaultConnection"].ConnectionString = "Set the connection string here";

On the first line, I’m getting a reference to the web.config file.

On the second line I’m getting the section connectionStrings.

On the third line, I’m getting the specific connection string I want to change. In this example, I’m going to change the connection string named by “DefaultConnection”. Then I set the property value ConnectionString to the new value.

Finally, I’m saving the changes to the configuration.

Keep in mind that editing the web.config file will cause restarting the application pool so think twice before you going in this approach. If you can help it, avoid dynamically changing the web.config file since it’s not a recommended practice in ASP.NET web development.


To Tier or Not To Tier

Before deploying the application in to tiers, you must decide carefully whether you actually need it.

Deploying in tiers will be expensive since you would have to pay for the networking cost and hardware cost for the servers. On the other hand, it will increase the maintainability of the projects since if you do some change at one tier, you only need to deploy the changes to only one server. Deploying in a layers will be relatively cheaper.

If the developers of each tier is going to be in separate countries, then it will make easier for them to go for a tier architecture because then they can handle the deployment in their own server at their country. But keep in mind that it will decrease the performance so badly since the inter communication between the servers would be needed. With the help of techniques like caching, you can reduce the round trips though. If you prefer to have a good flexibility and scalability, then go for tiered architecture.

Scalability could also be achieved in a layered architecture if you deploy the application in a web farm. But tiered architecture would be more scalable according to the situation. For an example, let's say you need to improve the resources in data access/data storage area. Then if you use a layered architecture you can't directly increase the resources for only data access layer. What you can do is increase the resources for whole application. But again, you can't guarantee those resources will only be used by the data access layer. It will be shared among other layers too. But in a tiered architecture, you can easily increase the resources on data access tier.
In Web Farms, there will be no separate resources available for separate layers. But in tiered architecture there will be individual resources for each tire. So if you need to scale up a one tire, you can easily do that by upgrading the resource in that particular server. In web farm situation, you can't individually increase the resources for separate layers. In a case of increasing the resources only for some particular layers, tiered architecture would be much easier. If you want to simply increase the resources for the whole application, then a layered application hosted in the web farms would do that.

In my opinion, it will be easier to monitor the performance of each area of the application, if you host it in tiers.

Being said all the above, this kind of decision cannot be taken by just reading a blog post. It will require a better understanding of the project requirements, budget etc. My efforts are to give you a rough idea on deciding whether to go with the tiered approach or not. It’s a critical decision in your project so I strongly suggest to do more research on the subject before implementing it.