There are a number of different options for complex module systems.

Each come with their own set of work flow issues.

For big systems - I prefer creating separate modules for each individual task.  That way you place the accounts module on a page and its automatically the accounts module - no extra layers of stuffing around with dynamics and redirection - also its much easier to take advantage of dnn's inbuilt permissions and roles systems if you dont need to code for it explicitly inside a single mega module - you can set access permissions at the page level at let dnn handle things.

Dynamic loading has its place - but it also comes with a whole very messy layer of additional coding and state handling issues which often seem to add more work and effort than the benefits of using it bring.  Not to mention debugging nightmares.
A simple example of this is the need to manually handle the recreation of the dynamic elements on every postback.

A site we have just finished has something like 35 custom modules in its system - doing all that with one mega module would have been not a fun job.

DNN already has all this cool code into it to handle dynamic loading at the page level - the way I see it - unless you absolutely have a situation where you need to dynamically or otherwise load custom controls yourself - take advantage of what dnn has built it.  Let it load modules onto pages etc.

As to your other question about where to store information - dnn has a very good built in modulesettings system that lets your store pretty much any sort of information about a module inside the generic dnn database without the need for creating your own table.
For simple information like a module mode or state this is the best place to store that sort of thing.  Obviously if you are building an account system or some such you create tables for that sort of data - but for information about a module - modulesettings or tabmodulesettings is the best option.  DNN also includes the ability to store personalization settings as well - basically per user information unique to a module instance.

If you really do want to go down the multiple views in one module approach - one other option instead of dynamic loading is to use the asp.net panel or multiview components.  That let you switch the information you are displaying at any time.

Just my 2 cents

Westa

Wes Tatters> Thanks for the input, I really appreciate it.

Actually after what you said I don't know anymore if I need to do one big module or one for each functionality. It is true that I need to handle permissions and I definitely want to use dnn's built in roles. I thought that one big module would facilitate deployment but if it makes navigation harder....

But how do you handle related data ? for example the sales are going to be linked to clients, if sales and clients are in 2 modules it's going to be problematic. Do you use a library as a datalayer that both modules reference?

And how do you navigate between modules, if I'm in the sales module and I need to add a new client, do I need to create a link to the page with the client module ? Hardcode a link in a module to a page created dynamically seems wrong to me...

Most of my entities are going to be linked one way or another to the other, and they will need to interact between themselves. But they also needs their own set of permissions, and I don't understand yet how all of this will work.

cathal connolly> Thanks for the input also, but as you can see above, I'm not really sure of the way to go and after reading this article about navigation (mostly the end: "Why recreate extensive navigation when the framework already provides it?") I tend to agree with Wes' choice, but it brings many questions to the surface.