Context spanning views

Problem description

Imagine you have some context you want share between several views. For example you could have in your shell an overview (view) where you represent a list of customers and to the right you could have an action menu (view) where you have buttons „new“, „edit“, „delete“, etc.

The context you want to share between the overview and the action menu is the list of customers or maybe the current selected customer (selected item). So how do you accomplish this task? There are several well known solutions for this, but I want to introduce you some new concepts to do it.

I believe that lose coupling is the most important requierement for sharing context in the UI. That´s why all of this presented concepts concentrate on this requierement.

Some of them are easier to implement and some bring in some drawbacks. So it is up to you as developer to pick up the concept which fulfills your needs.

Concepts

Event Manager

This concept is a well known and that´s why it is the easiest to introduce in your solution.

You don´t have to implement a new event manager by yourself. Many intelligent guys already implemented some event managers for you (EventAggregator by Prism, Messanger by MVVM Light Toolkit).

I don´t want to explain how to use each of the event manager at this point. It is up to you to read the documentation to understand the funcionality of each event manager.

Pub/Sub-UI-Control

This is a solution I developed recently for my employer. This solution allows independent views to connect with each other without strong coupling. The coupling is based on a contract. The contract is normally a constant string.

With pub/sub-controls you can create a shared context for what ever you want. In the coming code examples I share the currently selected item and the itemsource of a listview.

In the code example above you can see a control which defines a subcriber. In the next code example you see a publisher.

The difference here between a subscriber and a publisher is the name of the attached property.

The attached property to subsribe for a shared selected item is „SelectionGroupManager.SelectionGroupName“ and the attached property to subscribe for the shared itemsource is „ItemsGroupManager.ItemsGroupName“.

The attached property to publish the selected item is „SelectionGroupManager.SelectionGroupSource“ and the attached property to publish the shared itemsource is „ItemsGroupManager.ItemsGroupSource“.

Of course this is just the beginning. In the end you need at least one viewmodel for each part of the pub/sub-control.

A viewmodel for the publisher would look like this:

A viewmodel for the subscriber would look like this:

In the end it is only a manual data binding by „SelectionGroupManager“ or by „ItemsGroupManager„.

Context shared by Parent(-ViewModel) with an AttachedProperty

This solution takes advantage of the attached property in WPF and the possibility to inherent your attached property to your child controls. When your shared context is inherited to your child controls then your viewmodels of the child controls can do a data binding to this shared context.

This only work of course only when you have a parent viewmodel which holds all your information inside a context you want to share.

Creation of child-ViewModels by ParentViewModel and sharing context

This solution is a little bit easier to implement as the previous solutions. Here you pass in a parent viewmodel into your controls which want to share a context and your parent viewmodel creates the datacontext by a factory method. Inside the factory method every viewmodel which works as datacontext for the current control (or view) receives the shared context by the parent viewmodel.

Context-registration for each view-context

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *