1

I am building a SaaS application and I would like to retain the single code base I have. I would like to be in separate sub-domains cust1.saascompany.com, cust2.saascompany.com, etc. However, I don't have any TenantID's and would prefer for multiple reasons to stay with separate databases for each customer (primary one is that it's already coded that way and doesn't make sense to change it until usage warrants). The database has the user login membership within it.

I'm guessing I would need separate web.configs for connection strings? Or should I create a separate database that stores all the connection strings and any application level variables/constants? Eventually, I would like to be able to automate this provisioning (again, when usage warrants it).

Are there some articles or posts that anyone can point me to regarding how to set this up with steps? I haven't been able to find what I'm looking for.

scojomodena
  • 842
  • 1
  • 14
  • 24
  • Check this out http://stackoverflow.com/questions/278668/is-it-possible-to-make-an-asp-net-mvc-route-based-on-a-subdomain – Chris Moutray May 25 '12 at 19:36
  • Oh and having a separate database per client is how our product works, with one user logins database to store connection strings. PS think about deployment automation, upgrading 300+ db's on deployment night is fun. – Chris Moutray May 25 '12 at 19:40

1 Answers1

2

Technically, this is simple. We do this for years. Although we use a different convention (my.domain.com/cust1, my.domain.com/cust2 plus url rewriting) this doesn't change anything.

So, this is what you do. You create an abstract specification of a connection string provider:

public interface ICustomerInformationProvider
{
    string GetConnectionString( string CustomerId );  
    ... // perhaps other information
}

then you provide any implementation you want like:

public class WebConfigCustomerInformationProvider : ICustomerInformationProvider { ... }
public class DatabaseConfigCustomerInformationProvider : ICustomerInformationProvider { ... }
public class XmlConfigCustomerInformationProvider : ICustomerInformationProvider { ... }

and you map your interface onto the implementation somehow (for example, using an IoC Container of your choice).

This gives you the chance to configure the provider during the deployment, for example, a one provider can be used by developers (reads connection strings from a file) and another one in the production environment (reads connection strings from a database which can be easily provisioned).

If you have other questions, feel free to ask.

Wiktor Zychla
  • 47,367
  • 6
  • 74
  • 106
  • @wiktor_zychla, thanks for the response. It seems like what you're saying is right, but I don't know the details in how to make it work. I should have also asked, "How do I have one code base with multiple sub-domains"? I missed that piece of info. Any suggestion? – scojomodena May 25 '12 at 18:13
  • You setup the IIS application for multiple host headers. This should be easy. Then, in the processing pipeline, you check the `Request.Uri` to discover what is the requested host header. – Wiktor Zychla May 25 '12 at 18:46