The online documentation has a section on 'Database & Deployment Architecture'
In our use case we are currently favoring a 'Single Deployment Multiple Database' approach (each Tenant has it's own Database).
My question is this:
In the future, if there was to be some divergence in the models between Tenants, what would be the best option to take?
I'm thinking it might be to abandon the single host approach and set up a separate host/Tenant.
Does this sound like a reasonable statement/approach?
Another option may be to use the Abp Module approach to coping with the conflicts. Obviously means more tables/etc and may not always make sense
Cheers,
John
Depending on extent of divergence in the models, you can consider IExtendableObject Interface.
var person = new Person("John"); // Set person.SetData("CustomData", new MyCustomObject { Value1 = 42, Value2 = "forty-two" }); // Get var customData = person.GetData<MyCustomObject>("CustomData");
If you need different views, you can conditionally call View("Index_Tenant1")
in your actions.
If the divergence requires explicit type safety, database column search, or foreign key references, then Multiple Deployment would be a reasonable approach. Updating forks has its own challenges, but that will keep your DbContext
clean, your migrations independent and fulfill the requirements.
It may be tricky to configure the subdomain routing — unless having different domains is okay.
You can still use a single host database though, configured by specifying the connection string. This allows you to manage things like editions and features from a single (or any) application.