Modularization in CAB

Topics: CAB & Smart Client Software Factory
Sep 10, 2007 at 9:32 PM
Edited Sep 10, 2007 at 9:33 PM
I am about to start using the CAB (WPFCAB from SCSF Contrib). One aspect of the framework design I am suspicious about is a guideline to make a module dependant on a shell (through workspaces mainly).

Let's say I have two modules and each implements single use case (and includes all the components of a use-case: DAO, rules, and views). On activation module will put its view on the "MainWorkspace" deck workspace, so that at most one module is active at a time. While Shell will provide the "MainWorkspace".

Now I decide that modules should be shown at the same time in two separate workspaces - left and right panels of the shell. Though, I would expect that only Shell has to be changed, in fact all three components (two use-case modules and the shell) will have to be modified per CAB (SCSF) as I understand it.

Any good reading on this topic?

I understand that this binding has to live somewhere. It just seems wrong to have:
inside a module.

or a type-safe version, to the same result:

So binding of a module to the main UI can be defined in the Shell, in the Module, in the Shell's layout, in the config file for example.
Any other ideas?

I don't really have a question. I am interested in hearing opinions.

Roman V. Gavrilov
Sep 14, 2007 at 4:27 PM
Hi Roman,

I don’t think it’s a bad practice binding a module with the UI in this way:

In my opinion, it is a good idea to use constants to define the names of the Workspace.
I recommend you to read the Lab 1 and Lab 2 of the SCSF’s Hands on labs
There you will see that SCSF uses constants to facilitate the work and to reduce the impact on changes.

Please let me know if this helps!

Mariano Converti
Sep 17, 2007 at 4:04 PM
I understand the pros of using constants for binding, but all it does is replaces compile-time binding, with run-time binding. This has it's place in the development world, but it comes with a price. The argument "it reduces impact on changes" can also be applied to calling method by name, instead of through interface (as a language construct).

It is certainly benefitial to be able to extend application by deploying an extra module and not having to recompile the shell, but I would limit such flexibility to the extensibility portion of the app, while having it's core rigid and type-safe. And the main reason for that is binding at this level (core) of the design is known at compile time, so it can as well be compiler enforced.