Pattern for Silverlight child window

RAVAGE


I just wanted to convey the enitre motivation of this article in a simple sentence which resulted in the 'keyword like' entry as the title "Pattern for Silverlight child window". As per my observation the UI approach (way of presentation to the end user) for Silverlight varies with that of ASP.Net UI. In most of the Silverlight applications that I visited, I didn't noticed the heavy usage of the child (popup) window for interaction purpose except the light usage of notification purpose such as confirmation / information display dialogs. If we do need to use the child window for interaction purpose, then the first idea that we need to plan is about how to share object between the parent and the child window.


I came across a similar situation in my project where my client wanted to present the child window for interaction purpose in order to produce a native UI approach. I thought of implementing this without breaking the MVVM pattern. To achieve that, first I thought of sharing the same ViewModel object between the parent and child. It got ruled out immediately due to well know reasons of maintainabiltiy and scalability. Not all the members of the object will be common for both parent and child window. Hence sharing same ViewModel / object won't be the right choice.

Next option is to have two seperate view models for parent and child dialog holding reference to each other. This is better than the previous one, but think of the case having more than one child window which will result in the parent holding reference to each of the child window and each child window holds reference to the parent. Going one step forward, think of a case having more than one parent view and multiple child view which are related, might end up with each object having reference to other as a worst case scenario. So, are there any pattern that provides solution for the above case? Yes, as many article over the web  suggests, Mediator pattern provides us the solution.

MEDIATOR FOR PARENT-CHILD VIEW

Mediator holds the instances of the parent and child objects and manage the interactions between the objects. The parent and child objects in turn holds the reference of the mediator and notifies the mediator about the relevant changes. Having received the change notification, the mediator will call the required update / action aginst the objects in relation to the change.

I implemented this change in my project and worked fine for me. But out of curiosity, I further fine tuned this implementation such that the parent and child view objects interact with the mediator using Observer pattern.

The implementation goes something like as follows:
I created an abstract class called Colleague which holds the instance for the Mediator as a property and an Update method which can be overriden by the class that inherits it.
Then I created an Mediator class which provides the methods to Attach, Detach and Notify. The Attach methods takes in an object of type Colleague as parameter and adds to a list of Colleague(to be notified). The Detach method takes in an Colleague type as parameter which removes from the list of Colleague. The Notify method iterates through the list of Colleague object and calls the Update method on each Colleague object.

The parent and child ViewModels inherits the Colleague class and overrides the Update method if needed. For example I was about to pass a selected item from my child ViewModel to my parent ViewModel. To achieve that upon selecting a particluar item from a list of items in the child view, I'll call the Notify method of my Mediator by passing the selected item. My parent ViewModel in its constructor will subscribe to receive the notification by calling and passing itself as paramter to the Attach method of the Mediator object. Upon the Mediator receives the notification from child view, it calls Update method of the Colleague (parent in this case) which got  subscribed to it.

STRUCTURE

SUMMARY

I actually have described an idea about the implementation in my project. Based on my project scenario, I had extended the same concept to handle multiple parent and child view models for which the usage of Observer pattern for interaction with the Medaitor helped me to produce a scalable and maintainable code. On the whole my idea is to implement a Mediator which acts as a change request manager holding the responsibility of interaction between the ViewModels. In my case, since I had only one change request manager (Mediator), I eliminated the introduction of abstract Mediator class. After completing my implementation, I realized that single instance for my Mediator holds good for my scenario. Hence, finally I also implemented Singleton pattern for my Mediator class.