How fine grained should modules in Prism be?

Question

Hey girls and guys!

I am currently working on a project of mine using Prism (the Composite Application Library/Guidance). The application will be a specialized MSPaint-like application for basketball (predefined objects for balls, players etc.).

Now I am wondering how to go about organizing my application into Prism modules. Especially when thinking about the drawing part of the software.

Should I split the general drawing view (2 columns: toolbox, canvas) in 2 modules (toolbox and canvas) or would the overhead created by the constant communication of these modules be too overwhelming?

How fine grained should Prism modules really be?

Thanks in advance and best regards, crischu

Answer 1

There's very little overhead when you separate into modules.

I would go with what helps you organize your solution, rather than worrying very much about performance considerations. You can easily combine modules if you find they are causing you trouble or you are finding that two modules really belong together.

The rule is:

Make it run. Make it run right. Make it run fast.

In that order. Do what feels good first and refactor later if necessary.

Answer 2

I'd say it depends on how you distribute the functionality of your application over the UI. If you have just one screen, but with multiple sections that manage different features, each of that section (tab page, panel, etc) should have it's own module. This is the case with the StockTrader RI or NewsAggregator samples. But on the project we are starting we decided to have multiple pages, one page for each major feature and to have navigation between them. In this case, a module will represent a page, nothing smaller than that.