views:

636

answers:

3

In a Composite WPF application, what is the best way to store global variables needed by several modules? For example, I am working on an application in which several modules need to get a file name, so they can fetch the data they need from the file.

Is there a best practice for storing information like this in a Composite WPF app? How do I get the information to my modules while still keeping loose couplings? Thanks for your help

David Veeneman
Foresight Systems

+1  A: 

Write a service that encapsulates the logic you require and package that service into a module. Then have your other modules use that service to get their job done. Note that the service may expose the file name directly, or may instead choose to expose operations that operate on an underlying file without consumers being aware of said file.

HTH, Kent

Kent Boogaart
+1  A: 

Create an interface who's responsibility it is to return the "selected file name". Unlike most services / dependencies, it won't do a lot of processing - it's just responsible for returning a value. Use dependency injection to provide an implementor of this service to all places that need it.

At the moment this file name might seem truly global, but imagine your app had to transition from SDI to MDI. It's never a good idea to have true singletons in you composite apps.

Rob Fonseca-Ensor
As for singletons and MDI, you can have an app that has a "single" file open and an MDI interface. Visual Studio solutions are a single file in an MDI environment.
Cameron MacFarland
A: 

Thanks for both answers, both of which look very good. I came up with a third approach while out on my morning run, and I think I'm going to try this one:

I load all of the modules in my Composite WPF app at startup and activate only the views that will be shown initially. So, all of my modules, even the ones not shown, are available as soon as startup completes.

When they are initialized, each module that needs the file path will subscribe to a FileOpened composite event in the Prism event aggregator. When a file is opened from the Shell, the Shell View Model will publish a FileOpened composite event. The composite event will carry the file path as its payload.

So, when the FileOpened event is published by the Shell view model, the appropriate callback method in each module will be called by the Prism event aggregator, and the filePath will be passed to each module's view model.

David Veeneman