1

How would one implement a multi tenancy application structure with the following technologies:

  • Multiple SQL Server Databases (One per tenant)
  • Asp.Net
  • Entity Framework
  • Active Directory and possibly custom role providers for authorization.
  • 1
    If you have a PluralSight subscription, I'd strongly recommend watching this course: pluralsight.com/courses/… - There's a step by step on how to build what you want, and discussions about caveats while implementing a multi-tenant app. Warning: Not free content. – Machado Jan 23 '17 at 18:01
1

It all comes to measuring:

  • How large is the gap between the code of those eight sites,

  • How will this gap evolve over time.

If the websites are expected to evolve nearly independently, having eight projects may make sense. However, if much of the changes apply to all eight websites, it is unfortunate to make the change eight times.

Given the constraint that the database schema cannot be changed, you'll be unable to have one database anyway (given that this should have been the original choice, and databases should have been split exclusively in a case where schema differences were too blatant to lead to extreme usage of switch statements to adapt the common schema to all the eight cases.

This, coupled with the usage of Entity Framework, means that you'll have eight projects at data access level. Now, if there are few differences, it may make sense to have a common website using one of the eight data providers. If differences are too numerous, this eventually leads to eight website projects. In this case, still, try to export as much business code as possible in a common library.

8 Web MVC websites, one for each organization. Specific business logic here.

Since websites are, according to your question, 90-95% similar, this means that 90-95% of those business rules will be duplicated, over and over and over. As with any duplication, this means that whenever someone changes a rule for one site, either he forgets to make the same change for seven other sites, or he makes one where he shouldn't or creates regressions because he forgets about the specificity of one of the sites.

  • That is a good point about the risk of not maintaining duplication. I agree that having a shared database would solve a lot of the problems here. There are a few reasons why they have to remain separate, but as an exercise, I think it makes it more interesting as well :). – AnotherDeveloper Jan 20 '17 at 21:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.