<cite>@fncap on Gitter Chat: </cite> I've a question about how to organise entities on project suppose you are developing a SaaS app organised in features and editions like an e-commerce (but I don't develop an e-commerce) so you can organise editions to sell a module for managing contacts, and another editions to sell orders management so ... in first module i can have an entity called Category that refers to product category, and in orders module i can have another entity with same name but refers to Contact category the have placed an order actually I have to put in a common DbContext two IDbSet with different name, like ProductCategories and ContactsCategories.
It would be nice if i can refer to ProductCategories like a namespaces ... e.g. DbContext.Catalogue.Categories.GetAll() and refer to other entity same way, like DbContext.Orders.Categories.GetAll() someone have an idea ?
Nobody are using Gitter Chat? <a class="postlink" href="https://gitter.im/aspnetboilerplate/aspnetboilerplate">https://gitter.im/aspnetboilerplate/aspnetboilerplate</a>
3 Answer(s)
-
0
Yes, we don't use it (just opened to get the name and test it).
First, I want to fix a misunderstanding: Editions are not introduced to create modules. We have already modules independent from edition system (<a class="postlink" href="http://www.aspnetboilerplate.com/Pages/Documents/Module-System">http://www.aspnetboilerplate.com/Pages/ ... ule-System</a>). Modules can define/implement features, edition is used just to group features. In your case, you can implement all your features in a single pysical module (assembly) or distribute code base to 2 or more assemblies (modules). Your tenants can not know that. Then you can define two features "product management" and "order management" if you want to enable/disable it per edition/tenant. You can even define more subfeatures of "product management" for example if you enable/disable some sub features. Or you can even define a feature named "Product count" that is an integer to restrict product count by edition.
For your actual question: As I know Entity Framework does not support such a thing. You can define 2 seperated dbcontext if you like.
-
0
Thank for reply! As always, you are very helpful!
Understood Edition/feature mechanism, good clarification!
About multiple DbContext, I know and tried that ... but in my scenario modules can refer to entity of other module. Using separate DbContext whit different ContextKey make EF to "recreate" table mapped to entity in referenced assembly.
And this is not good!
I'm approaching to as system that can provide verticalized solution when needed.
For example, if I have developed a module for managing contacts, and I have two customer that can use this module, simply start from AspNetBoilerPlate template, add my own nuget package and that's all!
This maybe sound strange, but is commonly in our "customer habitat" where they want own server inside their office ... because they feel more secure.... mah... I never understand this thoughts!
So finally I'm imaging a separate ABP modules that are able to manage their own migrations, and concur to one big application-per-customer based on their needs.
-
0
Hi,
Using separate DbContext whit different ContextKey make EF to "recreate" table mapped to entity in referenced assembly
Unfortunately, EF has no built-in support for that (while community has some workarounds). I had created an issue for EF Core about that: <a class="postlink" href="https://github.com/aspnet/EntityFramework/issues/5572">https://github.com/aspnet/EntityFramework/issues/5572</a>
