What to keep in mind when developing a multi-tenant asp.net MVC application?

Question

Good afternoon - I have a pretty general question today - I've been tasked with creating a web application to manage some basic information on customers. It's a very simple application, but what I don't know is what to keep in mind to develop the site around supporting multiple users at their own domains or subdomains of our url?

How would I restrict users from logging in to each others portion of the app?

I've seen mention of database scoping in similar questions on Stack Overflow, could anybody elaborate on best practices for an implementation like this?

Are there any new features in MVC3 to support multi-tenancy? I am facing this issue with MVC2 and my eCommerce site where we decided we wanted it white-labeled and customizable for multiple shop owners, and don't know where to begin in implementing these features in an existing application. Any input is appreciated.

edit

To elaborate on multi-tenancy, what I mean - in the context of a store for example, multiple users sign up for their own store at www.mystore.com and are each given a unique subdomain to access their own instance of the store, at user1.mystore.com, user2.mystore.com etc. Each store would have customers with order histories, and those customers would have logins. I would need to restrict customers of user1.mystore.com from logging in at user2.mystore.com without a new account, and likewise prevent user2.mystore.com from accessing user1.mystore.com's customer history.

Answer 1

I implemented a complete MVC multi-tennant app. Here are some links I found handy and some sample apps:

http://msdn.microsoft.com/en-us/library/aa479086.aspx

http://codeofrob.com/archive/2010/02/14/multi-tenancy-in-asp.net-mvc-controller-actions-part-i.aspx

http://www.developer.com/design/article.php/10925_3801931_2/Introduction-to-Multi-Tenant-Architecture.htm

http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_cc

http://lukesampson.com/post/303245177/subdomains-for-a-single-application-with-asp-net-mvc

http://code.google.com/p/multimvc/

http://www.paulstovell.com/widgets

http://www.agileatwork.com/bolt-on-multi-tenancy-in-asp-net-mvc-with-unity-and-nhibernate/

http://ayende.com/blog/3530/multi-tenancy-approaches-and-applicability

http://weblogs.asp.net/zowens/archive/tags/Multi-tenancy/default.aspx

http://cloudsamurai.codeplex.com/

http://cloudninja.codeplex.com/

http://msdn.microsoft.com/en-us/library/hh534484.aspx

http://blog.maartenballiauw.be/post/2009/05/20/ASPNET-MVC-Domain-Routing.aspx

http://blog.tonywilliams.me.uk/asp-net-mvc-2-routing-subdomains-to-areas

Even starting from scratch, you are in for a world of hurt. The MVC framework does very little to help you address the issues.

Answer 2

There has been some talk of multi-tenancy support in Sharp Architecture (based on MVC 3) found here: http://www.yellowfeather.co.uk/2011/02/multi-tenancy-on-sharp-architecture-revisited/

Not sure if that really helps you with your existing application, porting over would be a bit of a job.

Answer 3

Most likely you are about to spend a fair amount of time restructuring your database.

The first step is that you are going to create a table to house your "Tenant" list. Then you need to add this TenantId to just about every table in your system to make sure no one steps on each other. You can skip any tables that are global in nature. One example might be a list of Status Codes.

However, everything from users to the data they have etc will have to have this ID. Also, modify all of your indexes to take tenantid into account.

Once you have that, you'll need to modify all of your queries to take the tenantid into account.

One column of the tenants table should be the portal url. Like customername.oursite.com or whatever. This way you could point multiple urls to the exact same code. When the site needs to use the current tenantid just look it up based on the URL the passed in.

If I was doing this, I'd plan to spend about 1 to 2 hours per table in the database to make it "multi-tenant". Obviously some tables (and their queries) will go faster; others will take longer.

Incidentally, this doesn't cover things like customizing the UI (look / feel) per tenant or anything of that nature. If you need to do this then you'll have to either create a directory on the server for each tenant to hold their style sheets or load it directly from the DB (which has it's own issues with regards to caching).

Typically, you design for this at the beginning of the project. Refitting an already (or almost) complete project is a PITA.

Finally, test, test, test and do more testing. You will have to make sure that every single query pulls only the data it absolutely needs to.