Best approach for shared entities #3974
-
|
I was wondering what is the best approach for handling shared entities among different "components". Image the case where I have a "News" entity with some fields (id, image, title, category, slug url, ...) and I need to render these news in different places. For example, I might have these use cases:
Should I bundle all the required modules inside a single VS solution like discussed here? Which module would be responsible for creating the "News" entity itself? Is it wise to just create a "News Admin" module with a standard data grid with CRUD operations for the entities? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 5 replies
-
|
I find it beneficial to bundle multiple modules into a single solution when data and elements of those modules are shared across all those modules. The solution & distributed DLL names are the packaging for multiple module names that reside within it (see screenshot). When you use the templates to create a new module, you end up with a solution & dll name that matches your module name, but that doesn't have to be the case. For my usage, I create a generic solution name and then create the specific module names within it (again, see screenshot). Using this methodology, you have a single namespace for all the modules. In my example case, all "models" are part of "WB6OZD.Module.Code.Models", all "services" are part of "WB6OZD.Module.Code.Services", and similar for other module content. That makes it much easier to share data & services between your modules without having to add in references. If you already have multiple modules, you can merge them into a single solution by just copying the files from one to another for each sub-area in the solution. Once copied into the "master" solution, you just need to adjust the namespaces on the copied files to be that of the solution namespace.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks, that's exactly what I was looking for!! Also, how do you handle database migrations? Do you use a single DbContext for all modules or do you create one for each? What about module versions? This is a nice a clean approach, but it would be nice to have an official Oqtane module template that was able to create new modules in an existing solution. |
Beta Was this translation helpful? Give feedback.
-
|
@mdmontesinos I do and would extend the current DbContext. |
Beta Was this translation helpful? Give feedback.
-
|
You do use a single DbContext or create one for each? And when you add a migration that adds a field for a specific module, do you need to update versions for all the modules? What if the field is added to an entity shared among different modules? |
Beta Was this translation helpful? Give feedback.
-
|
@W6HBR, could you share a GitHub link for this solution? |
Beta Was this translation helpful? Give feedback.
-
Unfortunately, no. This is private code in the solution. |
Beta Was this translation helpful? Give feedback.
-
|
@W6HBR excellent answer! The Oqtane framework itself is essentially many modules bundled in to a single solution - and custom modules can follow this same approach. |
Beta Was this translation helpful? Give feedback.
I find it beneficial to bundle multiple modules into a single solution when data and elements of those modules are shared across all those modules. The solution & distributed DLL names are the packaging for multiple module names that reside within it (see screenshot). When you use the templates to create a new module, you end up with a solution & dll name that matches your module name, but that doesn't have to be the case. For my usage, I create a generic solution name and then create the specific module names within it (again, see screenshot). Using this methodology, you have a single namespace for all the modules. In my example case, all "models" are part of "WB6OZD.Module.Code.Models",…