This project is read-only.

Use of Courier with multiple instances

Apr 29, 2010 at 6:26 AM

Great product - saved me a lot of time.

With its implementation as a static class, it seems to me that only one instance of the view models is supported at any given time. I have an application where the user can open several windows at a time (each with its set of the same view models). Is there a mechanism for making sure the messaging stays within the set of view models in a window?


Apr 30, 2010 at 10:17 PM

Hi Steve,


  My example application is a little contrived in that way. I am creating a static instance in BaseViewModel.cs for the purposes of demonstration. There is nothing specific to the courier framework that requires you to have only a single mediator instance.You could create multiple instances as needed. However, it could start to get complicated to manage what messages are going through what mediator.

You could also fully qualify message names in some way to keep all messages unique in one mediator. I have also tried having multiple mediator instances that were injected via a IoC container. In my case I used Unity and spun up child containers to manage different instances of the mediator.

Hopefully that gives you some ideas. Maybe you can explain a little more about your specific challenge? I would be interested to know how you are using the framework.



May 2, 2010 at 6:08 PM

Thanks a bunch, Brad,

I'll briefly describe my application approach. My app can create one or more windows to provide registration of persons. Each window registers a separate person. The window has a Frame that loads a set of pages through URIs. Each page contributes to some part of the registration process. The URI's are provided by a Worflow Foundation workflow, since I have to support multiple types/sequences of registration that I have implemented as separate workflows. I'm using a strict view-first MVVM approach in which the window view creates the underlying view model (and a loaded page view creates its own view model. I use view-first since the Frame navigation process loads the views, and my reading of MVVM is that the view knows of the view model, but not the converse.

There is a dependency between a window and its child pages, since the window has to coordinate the identity of the person with each of its child pages. I cannot use direct dependency or dependency injection since the Frame/Page construct totally isolates the window from the page, and with multiple windows open I have no way to associate a loaded page view model with the view model of the window that loaded it. For example, I cannot attach the page DataContext to the window DataContext (which would solve my problem).

The only pattern that seems to solve my problem is the Mediator pattern that you have developed in Courier. I will have to add a token to the communication process that will allow the view models to make sure they are working on the correct person. I cannot use a qualified message name directly since there is no way for a view model to know which qualified message to listen for (I though about that before you suggested it, but can't seem to work it out). The token could be passed as part of the payload, but this requires me to develop payload containers that encapsulate both the message data and the token. I though about modifying Courier myself to include the token as part of its infrastructure separate from the payload, but don't want to spin off another thread of development since you may continue to add features to Courier that I may want in the future.

Obviously none of this would be a problem if my app only needed to have one patient registration open at a time, but requirements dictate otherwise. It would also not be a problem if the Frame and its pages were not so isolated. WPF prohibits binding to the NavigationContext of the page view, which would also allow me some linkage between the data the page. The only way to link the NaviagationContext is in the code-behind, and since I'm trying to stick to a strict MVVM pattern, that is prohibited.

I'd appreciate any thoughts. Perhaps I'm overlooking some very simple, but I've been wrestling with this for some time.


May 5, 2010 at 2:57 AM
Edited May 5, 2010 at 2:58 AM

Interesting use of Courier Steve. It sounds like you have tried any of the suggestions I would have and have settled on a decent path given your requirements. As for payload containers that should be easy enough for you to implement for your purposes. Since Register and Broadcast both take in <T> as a param you are free to pass any kind of wrapper you need. 

Keep me posted on how things are going and if you run into any issues. You can contact me outside of Codeplex: Brad _ at _ (The contact link in my Codeplex profile should also work)

May 5, 2010 at 7:31 PM

Thanks Brad. When I get things finalized I'll let you know if I've done anything different, but so far appears to be working.