Multi Tenancy - Keep It Simple, REALLY Simple
Previously on the Multi Tenancy series:
One of the most common approaches for handling multi tenancy is composed of the following core ideas: Dynamic and Configurable.
You build the application to be dynamic, so you can change the entities layout, the UI look and feel, modify business logic using configuration, etc.
This is wrong!
This is wrong mainly because it is so bloody complex as an approach. Let us take the example of the UI, dynamic UI is fairly simple to start with. However, when you need to start considering things like validation, error handling, different field types, and so on, you get to realize that this is not really as simple as it seems.
Don't get me started on the 3 tables DB (tblEntities, tblFields, tblFieldValues) that get you so much dynamic it is dynamite.
The main issue is that trying to build something using this approach is just bloody hard. You have to keep the dynamicism of the application at mind at all point. Most of the time, you wouldn't even notice that your choice prevent you from applying the dynamicism in the app, but you are still paying the price for using this.
In many ways, it is similar to having VB.Net Option Implicit (If I got it right, the one where it doesn't give you a compilation error if you call non existing method, only at runtime). In fact, this is a great corollary. The VB.Net "dynamic" stuff is so limited that it is useless in most scenarios. Compare what you can do with a dynamic language like Python or Ruby vs. what you can do with VB.Net. There is very little value of having this option in VB.Net. It is usually a mine, not a feature. (Yeah, okay, it is really good feature if you are working with IDispatch, I know. Work with me here).
By the same token adding dynamic features to your application, runtime configurable and so on, will tend to be a mine more often than help.
My approach is quite different. Instead of trying to add configurability to the application, or adding dynamic behaviors, we can choose a static approach, one that allows use to make the best use of the tools and approaches that we have.
How do we get the variability that we need?
Oh, that is easy. Seams.
Each individual piece has no concept of dynamic / configuration / fubar. It is self contained and cohesive unit that can be combined with other pieces.
If I want to modify the behavior of the system, I can just plug in a new piece, and the entire machine keep on chugging along, without really noticing that the new Widgetometor is bright orange and flashing in Morse code.
Using this approach, we don't have to pay the price for using dynamic, configurable to the Nth degree. We can write the application as we would always will, and when variability calls...
Just plug the new stuff in.
Keep is simple, and keep it simple throughout!
