Maintaining 2 similar but different websites

Question

I have a requirement where I need to host the same website in 2 domains. The only differences between the 2 are minor style differences (basically just the logo and the header), where the site will be hosted and the connection string for the database (the db structure is going to be the same).

I suppose this is roughly a similar requirement to the different stackexhange websites.

What is the best way to create and maintain this? I want to avoid having 2 complete separate solutions as that will become a maintenance nightmare. There is a slight chance that enhancements may need to be made to the 2 sites seperately.

My project structure is roughly as follows:

• Web Project (asp.net web forms)
• Data Project (EF for data access)
• Services Project (for returning data from data layer and processing any calculations)

This is the way I was thinking of doing it:

• Have logic in the web project that will display different styles depending on where it is accessed from.
• Have separate service classes for the 2 domains with different connection strings. This will mean alot of duplicated code in the service layer.
• Use dependency injection where I can easily change which service class is going to be used at deployment time.

Something like

aspx:

<% if(domain) { %>
   some html
<% } %>

aspx.cs:

 [Inject]
 public IService service { get; set; }

IService.cs:

public interface IService
    {
        string GetClients();
    }

Service.cs:

public class DomainAService: IService
{
 DbContext db = new DbContext("connectionStringA");
    public string GetClients()
    {
        return db.Clients.ToString();
    }
}

public class DomainBService: IService
{
DbContext db = new DbContext("connectionStringB");
    public string GetClients()
    {
        return db.Clients.ToString();
    }
}

Does this architecture make sense? Is the duplicated logic in the service layer a problem? I wonder how the stack exchange sites do it.

Answer 1

You could put the configuration details in the web.config as application settings.

So the connection string would be in the web.config. And where you need a different logo, you could have a 'logo' application setting.

The code in the service layer would then look like this:

public class DomainService: IService
{
    var connectionString = ConfigurationManager.AppSettings["ConnString"];
    DbContext db = new DbContext(connectionString);

    public string GetClients()
    {
        return db.Clients.ToString();
    }
}

ConfigurationManager is in the System.Configuration namespace / assembly.

So the two deployments only differ in the web.config.

If the connection string contains sensitive userName / password then you can encode the settings - see this question Encrypting appSettings in web.config.

Answer 2

Keep it simple. One web site solution, rendering out different content and styles depending on the url.

We do this by using a master page and css. Master page:

<%-- override css --%>
<link id="overrideCSS" rel="stylesheet" href="" runat="server" />

In code behind, programatically set the CSS file depending on the domain requested (this can set the logo for example) and render any strings which are url dependent. Likewise, other infrastructure can be hidden/shown/modified in individual page load methods.

I'm not seeing the need for seperate services when you could do this:

public class DomainService: IService
{
    public string GetClients()
    {
        string connectionStringForDomain = someFunctionWhichChecksUrlAndReturnsConnectionString();
        return new DbContext(connectionStringForDomain).Clients.ToString(); // btw, why convert to string? Can't the serialiser take care of this automatically?
    }
}

If you DO need distinct service classes, some form of dependency injection would likely be the way to go. I've had great success sharing code across disparate Linq to Sql data contexts, for example, by declaring interfaces, implementing those on 2 dcs, and injecting the relevant dc as required.