Cross Cutting Concern(s) Modules?

Topics: Prism v2 - WPF 3.5
Sep 2, 2009 at 3:49 PM

Hi all,

IMO, it seems like a lot of the quickstarts and examples are composite applications where each module exists in complete isolation.

These examples are a great way to learn about EventAggregators, Composite/Delegate Commands, View Injection/Discovery etc etc, but....
I'm still pretty confused about the 'best practice' for implementing a cross cutting concern type module.

I think I've worked out how to provide a custom logger, by overriding the LoggerFacade on the bootstrapper.
You can then use the container to resolve the iloggerfacade from other modules in order that everything logs to the same place.
First question, have I got this right - or have I just hacked some code together that works right now, but might blow up in the future?

My next question, what about other cross cutting functionality? Caching for example.
If I wanted my application to have 1 component that provides access to a common cache used by all the components in the application, is that just a module?
That module would presumably have no view? So what does it look like?

Sorry if I'm being dumb here, but I just haven't figured it out yet!
I think I maybe adding to my own confusion by trying to learn CAL and MVVM at the same time, I'm thinking maybe the caching module doesn't adhere to MVVM?

Are there any examples of this kind of thing?

Thanks,

 

Sep 2, 2009 at 8:25 PM

Hi

The way you are providing a custom logger for your application is correct. As a matter of fact, this is the recommended way in the Prism documentation. You can check that out here.

As for caching, I believe the best approach would be having a service registered in the container which exposes the required data or functionality. As in logging, you can make use of the service anywhere in your application by getting it from the container.

Now, you can either directly register this service in the container (through the Bootstrapper) or have a separate module which is related to caching do it. This module sole responsibility might be registering the service, but in a growing application some other functionality might be added in the future. Another benefit is that you would not have to modify your application to provide the caching, you can decide whether to load the module or not, based on the way you are configuring modules to be loaded.

Take into account, that this module would need to be loaded before any module tries to use this functionality.

Please let me know if this helps.

Damian Schenkelman
http://blogs.southworks.net/dschenkelman