How best to leverage Oqtane to represent parent/child relationships as related modules?

[nissan]

I'm a big fan and advocate for Oqtane with my present team, but new to the concept of modular frameworks so am still learning so forgive me if this question is simplistic.

I have a Client module, which holds details about the clients. I also have a Projects module, which holds information about Projects. I want to list inside the Client module a list of their Projects. Because it is modular, there would be a SQL linking table for ClientProjects declared as a script that would hold a ClientID (from the Client Module's built in "Add") and a Project ID (from the Project module's built in ad). But how do I make a List[ClientProjects] property for Clients that is part of the model so that it is mapped to the separate database table? Also, is there a way to embed the front end from Projects module in the Clients module "Add" page if they want to add a new Project within the Client module's add?

This type of Parent/Child relationship is easy enough when it's all a monolith and we can just call to it as they are the same library, but what would be the right approach to keep within the Oqtane philosophy for building modular applications, using the microservice approach?

Thanks for any guidance given.

• Nissan

[sbwalker]

Oqtane is indeed modular... but it is up to each developer to decide how to organize/separate their own solutions from a physical development and deployment perspective. If you need the ability to develop/deploy each module independently from one another then you would want to create separate projects for each module. If you are fine with doing monolithic development/deployment then you can group a variety of modules within the same project.

For example, if you look at the Oqtane framework itself you will notice that the Oqtane.Client project contains many different modules that are all compiled into a single DLL. Similarly, the Oqtane.Server project contains many different APIs that are all compiled into a single DLL. This provides a simple deployment story as there are only a few DLLs which need to be managed.

If you have a bunch of modules that comprise your solution you may want to use the same approach as the core framework. Create Client, Server, and Shared projects which contain subfolders for each module. This will result in fewer DLLs to deploy.

Your other questions seem to be focused on how to use EF Core with a more complex data model. There are some examples in the Oqtane core framework which have similar requirements ( ie. User, Role, UserRole ). There is also plenty of information available online of how to use EF Core. And I should also mention that EF Core is not even a requirement - in your modules you are free to use whatever data access method you feel most comfortable with.