Using Prism for Non-UI modules (good idea?)

Topics: Prism v2 - Silverlight 3, Prism v2 - WPF 3.5
Jul 23, 2009 at 7:17 PM

I'm working with the patterns in PRISM for the UI portions of my application(s)...and other than the Region facets, most of these patterns are really good, generally applicable patterns that are good practice to apply in many areas of the stack.  

What's would be the downside, if any, to using PRISM as modules for my other class libraries?

In particular I'm thinking about 'Modularity' and 'EventAggregator' (Dependency Injection too of course, but that's available seperately with UNITY, so not so applicable to this question of broader PRISM re-use).

Is this a good idea, or be there dragons lurking when PRISM gets used in a wider context that composing UI?


Jul 24, 2009 at 6:57 PM

Hi Phil, 

It a perfectly good idea. Although Prism was developed to solve composite UI problems, one of its design goals was to "give developers the ability to use pieces of the Composite Application Library without having to use the entire library" (this was not the case with CAB). 

As you said, dynamically loading modules could be perfectly used in non-UI applications and EventAggregator as a mean for decouple communication between them. You could also check MEF for the modularity approach and Glenn Block's  post on Event Aggregation with MEF (with and without EventAggregator).

You might surely find useful Damian Schenkelman's post useful where shows how to extract only the EventAggregator from CAL assemblies (something similar could be done for modularity):

 Hope it helps! 

Matias Bonaventura

Jul 24, 2009 at 8:33 PM

Fantastic.  Thanks for the confirmation, and additional reading references.  Cheers Matias!