Menu Control and Prism

I want to put a customized menu control in the shell that populates at runtime from database. Each menu item fires an event and in response loads the view. Let us suppose we are creating nested menu that has n no of sub menus. So far that purpose I can't
use module for each menu. What will be the easiest and simplest way to achieve this with low maintenance cost.

Based on our understanding, Prism might help you with the following design concept(s):

UI Composition, could help in this scenario for composing user interfaces in loosely coupled way.

Modularity, is really important if you have the requirement to divide an application into a set of decouple functional units.

First of all, I think you could start defining the layout of your application by designing what
regions it might include. This way, you would be able to know where the nested menu will be displayed as well as the views.

In my opinion, the menu view could be part of the same project where the Shell window is (Shell module project).

As for the views that would be displayed based on the user gestures, I think you have the following options:

The Shell module could also include the views.

Add a new module that could include all the views that can be displayed.

Create a module for each functional unit in you application, and include the views to its rightful module.

If you plan to include all your UIs (menu + views) in the Shell module project, you could use
.Net events to notify to a controller for displaying its view.
However, if you decided to build a more decoupled application, and it contains more than one module that might be communicated between them, the recommended approach in Prism is the usage of
Event Aggregator. Additionally, you could check the
Communication section that exposes all the different approaches in Prism on this subject.

Regarding to how to display a view into a region, you could take a look at the following documentation sections:

Conclusion: ideally all the views should not be included in the Shell module, so it is highly coupled and in the future you could be
compromise in terms of scalability. That said, I would recommend an scenario where there is different modules, even more if this application could response showing/hiding functionality based on a database.