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.


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.


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

Unit Tests with cross-cutting concerns

Did you ever have trouble with writing tests where your class-under-test (cut) was dealing with cross-cutting concerns such as time management?

The following text is a 90% copy of the 7.5 chapter from the book „The Art of Unit Testing„:

The problem with cross-cutting concerns like DateTime is that when they exist in your code, they´re used in so many places that architecting them as injectable pieces of Lego can end up making your code very testable but also very hard to read and follow.

Let´s say that your application needs the current time for scheduling or for logging, and you´d also like to test that your application is using the current time in its logs.

You might have this type of code in your system:

If you were to make it more testable by making an ITimeProvider interface, you´d then have to use this interface everwhere DateTime is used. This is very time consuming, when in fact you can have more straightforward approaches.

It is much easier when you create a custom class, named SystemTime, and make sure all your production code uses that class instead of the standard built-in DateTime.

Now you can alter the current time throughout the system. This gives you a perfect way to test that the current time is used in your production code through a simple test like the one following:

You don´t have to inject a million interfaces into your production code. The price you pay is a simple [TearDown] method in your test class that makes sure any test doesn´t change the time for other tests.

Tutorial for Test Driven Development

Have you ever tried TDD and failed (for several reasons)? Do you wanna give it a try again with a valueable tutorial by your side. Than try out the free ebook of Grzesiek Galezowski:

This ebook does not only mention basics of TDD but also very important principles of Object-oriented programming (SRP, ISP, Object Composability, How to start writing valueable tests before even start writing productive code, etc.)

Give it a try!

Prism – RegionManager ready for Unit-Tests

You are using Prism for navigation and region management of your application. Be it WPF, Silverligh, Windows Apps, etc.

In any kind of application you will need to work with prism ultimate wappon for navigation and region management – IRegionManager interface.

But how can you test your Modules, ViewModels and any kind of logic which is used to handle navigation or region management. ‚IRegionManager‘ interface is a little bit tricky because many methods are implemented as extension methods. And extension methods can not be mocked by any unit test framework out there.

But there is a pretty simple solution for this problem: ‚Adapter Design Pattern‘. Take a look at a possible solution:

Now all you need to write your unit-tests is to mock ‚IMyRegionManager‘. If you need to mock much more extension methods just add them to YOUR interface and implement an adapter method for the extension method of ‚IRegionManager‘.