Multi tentant MVC application

Hi We are designing a multi tenant MVC application. We thought of having a separate schema for each tenant in some of the databases. Some of the mayor concerns:

• each tenant (or user - don't know yet) will have their own credentials to connect to the correct database
• we need to be sure that the database context of the different tenants/users who are logged in can not be mingled. Never. This is a major concern.

My question is: can lightspeed support this scenario. And how well is it suited to have different tenants using different connectionstrings in the same application.

Kind regards

Yes this should be fairly straightforward assuming I am understanding you correctly.

You will want to have a per-request scoped UnitOfWork as this is a web application. Our normal recommendation is to have a statically defined LightSpeedContext however in your case you will want to define the context on a per request basis as well as this holds the connection string details and any other concerns relating to establishing the connection to the database for the UnitOfWork.

Presumably you will be able to identify the tenant details based on the incoming request (host header etc) so as part of the logic for creating the per-request scoped UnitOfWork instance you will want to determine the tenant and then initialise a LightSpeedContext based on that information and then use that context to create the UnitOfWork to be used for the request.

Jeremy

Hi Jeremy

This is perfect.

Is the only purpose of the lightspeed context to hold the connectionstring? If not what are the trade-ins we are making when instantiating on a per request base?

Kind regards

Hi,

We have bought lightspeed. I've been reading the book since than. The only drawback I could come up with is the following:

• You can't make use of the build in UnitOfWorkPerRequest classes
• When you use the keytable you will be 'losing' ON EVERY REQUEST some numbers.

Someone else any idea's?

You shouldn't have a problem continuing to use the built-in PerRequestUnitOfWorkScope class for managing your UnitOfWork on a per request basis - you will have to customise how you are handling your contexts so you are instantiating your PerRequestUnitOfWorkScope with a context which has the appropriate connection string for your tenant. Have you looked into this approach and found a problem with this for your situation?

With the KeyTable identity strategy, the approach with this is to use a batch size which in a balance between making too many requests for new keys (too small) or wasting keys (too large). You can tune this by adjusting the IdentityBlockSize on the LightSpeedContext. In terms of wasting keys, this isn't really going to be a problem if you are using an Int64 based KeyTable so I would not be too worried about this.

Jeremy