CODEWITHSUNDEEP
asp.net-mvc-4multi-tenant
jpgrassi
jpgrassi

Reputation: 5732

Multi-tenant ASP.Net MVC application - Where to store tenant specific data

I'm working on a requirement to change an existing ASP.NET MVC application to become multi-tenant ready. The application was built for "only one customer" by other means, for each client there's a new installation of the MVC app. The application has its database structure prepared to have "multi" websites inside one MVC app, so all the database queries already take the "site" into consideration (siteId).

I have several questions regarding multi-tenancy applications and I'm still studying it. Today I started doing changes on the MVC app and I came across on one thing. The application has a table with several configurations. Things like AppSMTPServer, AppShowLoginBox and etc. These are parameters created to make the app dynamic.

All these configurations are currently stored in the ApplicationState inside a static class, something like this:

public static IDictionary<String, String> Configurations
    {
        get
        {
            if (HttpContext.Current.Application[CONFIGURATIONS] == null)
            {
                LoadConfiguration();
            }
            return (IDictionary<String, String>)HttpContext.Current.Application[CONFIGURATIONS];
        }
        private set
        {
            HttpContext.Current.Application[CONFIGURATIONS] = value;
        }
    }

My question is. If I change the MVC to become multi-tenant ready, each tenant will have its own configuration values. So, I cannot store them in the ApplicationState anymore as it will be populated on application_start and will stay there for good.

What are the options for storing tenant specific configuration data? I looked on several sites and couldn't find a "good practices" on this. If I missed something that would help, please leave a comment. Thanks!

Upvotes: 2

Views: 1213

Answers (1)

Saravanan
Saravanan

Reputation: 7854

In my experience in building multi-tenant app's this use-case can be handled as follows,

  1. Data remains in the Db
  2. Upon a tenant login, we might require their config values, we can fetch from the db store and add them to a cache [redis - distributed cache]
  3. similarly for each tenant hit, we can cache them, this way as the application is being repeatedly used, the more static data goes in to the cache and lesser the load on the app and the cache and higher the response times

Upvotes: 3

Related Questions