Skip to main content

Using IoC nested lifetime scopes with View Models in MVVM

A common pattern you see when developing web services is the use of the Unit of Work applied to the HTTP request - anything that happens during the processing of the request is viewed as being part of the transaction and therefore when the request is completed any memory allocated during the processing of the request can be garbage collected.  Whether the request is successfully or not is irrelevant in this context the important concept is the freeing of the allocated memory- controller, services, view engines etc. This pattern takes the form of using a nested (child) lifetime scope inside the IoC container used to host the web service - each request is processed inside a unique lifetime scope and when complete this scope is disposed. 

Can I apply this pattern to view models in a WPF (XAML) application?

To clarify what I mean, I'm not referring to every possible view model in an application, I'm referring to the main view model for a screen within an application where there could be multiple screens open at the same time.

You'll probably thinking - why?

Separation of concern  - the separating of different screen concerns from the point of view of the IoC container, this leads to better design of services, specifically shared services within the view models of a a screen - you don't have to be concerned with designing scoping into services & view models because it's taken care for you by the nested lifetime scope. The other main benefit, and this is more tangible, is the tracking down of high memory usage and leaks - because when the nested lifetime scope in the IoC container is disposed then everything allocated in the container should be disposed and the memory freed, anything that is still 'reachable' is likely to be a leaking allocation.

Before I jump into the code I better define a couple of key terms:

Workspace - this is the root class for a UI, it contains the main view model, controller and any resources (XAML). Instances of this class will be created in the nested lifetime scope of the IoC container by a WorkspaceFactory class,

Chrome - this is the application chrome, everything UI that is not a Workspace - the layout, menu, title bar etc.

In the following screenshot the Chrome is highlighted yellow and the Workspace is highlighted in red:
Before I get into the details about the classes, lets have a look at the example UI. When the user selects a Workspace from the combo box it is rendered into the application - the Workspace fills the available space, shown below are three of the example Workspaces:
From a technical point of view when the user selects a Workspace from the combo box the following happens:

  1. A new IoC nested lifetime scope is created,
  2. A WorkspaceFactory class is created inside the newly created IoC nested life scope,
  3. A new Workspace is created using the newly created WorkspaceFactory,
  4. Any XAML resource required for the Workspace are dynamically loaded,
  5. The view model is created and bound to the UI,
  6. Any previous Workspace is disposed.

Starting with the application boot-strapper, this uses Autofac for all IoC concerns and as you can see from the code snippet below there isn't much going on:
You can see pretty standard IoC registration stuff, the interesting parts start at line 49 where the WorkspaceFactory type is register as instance per nested lifetime scope - this basically means a singleton per lifetime scope. The next line is the actually building the IoC container and then resolve the root WorkspaceFactory instance - this is the important part you can see the root scope IoC container interface is being injected as a constructor parameter.

The Workspace is shown below, as you can see it's a very simple class containing the Controller which has the view model, any XAML resources and importantly an injected function to be called when the Workspace is being disposed - this is the important part when it comes to clean up, the Workspace which is the root object in the nested lifetime scope disposes the actual nested lifetime scope, which means everything in the nested lifetime scope is disposed when the Workspace is disposed :)
Loading ....
The WorkspaceFactory is shown below, the responsibilities are to created the nested lifetime scope, created the WorkspaceFactory for the newly created nested lifetime scope and then finally created the Workspace instance.
Loading ....
The WorkspaceFactory is used by a WorkspaceDescriptor, these descriptors are used in the example application to populate the names in the combo box. When a selection is made the CreateWorkspace method on the WorkspaceDescriptor is invoked which uses the WorkspaceFactory to create the Workspace (which contains the view model). The Example WorkspaceDescriptor is shown below:
Loading ....
These classes are part of the following structure, you can see there are 4 workspaces defined - AnotherExample, Example, Recursive & YetAnotherExample. Each workspace has a Controller, View Model and XAML resource files. The application Chrome is defined in the Startup directory, specifically the Chrome is defined by the MainController, MainViewModel & MainWindow:
One final class of interest is the WorkspaceHost user control. This has two responsibilities, firstly rendering the content (view model) of the Workspace and secondly loading any XAML resources. Importantly these resources are scoped to the user control they aren't loaded into the application resources, this is to prevents any resource naming clashes across Workspaces:
Loading ....
The XAML is very simple:
Loading ....
To demostrate it working I've used Ants Memory Profiler, I took several memory snapshots during the application, and each time I've highlighted on the screenshot the number of LifetimeScope instances there are 'live' in the application. A LifetimeScope object is an Autofac class which represents a lifetime scope inside the Autofac IoC container.

There's 1 LifetimeScope when the application is first started and a Workspace has not been selected:
There's 2 LifetimeScope instances when I selected a Workspace from the combo box:
And then the count drops back to 1 for the number of LifetimeScope instances when the Workspace selected is cleared from the combo box:
Earlier I mention the different types of Workspace in the example application, there is a special one called Recursive. This is a Workspace which hosts a nested instance of the application it's self - hosts the application inside application ad infinitum. See below for what I mean, again I've highlighted the number of LifetimeScope instances:
The code is available for download:

I've also pushed an updated version of this code base to github - Simple.Wpf.Composition.


Popular posts from this blog

WPF tips & tricks: Dispatcher thread performance

Not blogged for an age, and I received an email last week which provoked me back to life. It was a job spec for a WPF contract where they want help sorting out the performance of their app especially around grids and tabular data. I thought I'd shared some tips & tricks I've picked up along the way, these aren't probably going to solve any issues you might be having directly, but they might point you in the right direction when trying to find and resolve performance issues with a WPF app. First off, performance is something you shouldn't try and improve without evidence, and this means having evidence proving you've improved the performance - before & after metrics for example. Without this you're basically pissing into the wind, which can be fun from a developer point of view but bad for a project :) So, what do I mean by ' Dispatcher thread performance '? The 'dispatcher thread' or the 'UI thread' is probably the most

Showing a message box from a ViewModel in MVVM

I was doing a code review with a client last week for a WPF app using MVVM and they asked ' How can I show a message from the ViewModel? '. What follows is how I would (and have) solved the problem in the past. When I hear the words ' show a message... ' I instantly think you mean show a transient modal message box that requires the user input before continuing ' with something else ' - once the user has interacted with the message box it will disappear. The following solution only applies to this scenario. The first solution is the easiest but is very wrong from a separation perspective. It violates the ideas behind the Model-View-Controller pattern because it places View concerns inside the ViewModel - the ViewModel now knows about the type of the View and specifically it knows how to show a message box window: The second approach addresses this concern by introducing the idea of messaging\events between the ViewModel and the View. In the example below

Implementing a busy indicator using a visual overlay in MVVM

This is a technique we use at work to lock the UI whilst some long running process is happening - preventing the user clicking on stuff whilst it's retrieving or rendering data. Now we could have done this by launching a child dialog window but that feels rather out of date and clumsy, we wanted a more modern pattern similar to the way <div> overlays are done on the web. Imagine we have the following simple WPF app and when 'Click' is pressed a busy waiting overlay is shown for the duration entered into the text box. What I'm interested in here is not the actual UI element of the busy indicator but how I go about getting this to show & hide from when using MVVM. The actual UI elements are the standard Busy Indicator coming from the WPF Toolkit : The XAML behind this window is very simple, the important part is the ViewHost. As you can see the ViewHost uses a ContentPresenter element which is bound to the view model, IMainViewModel, it contains 3 child v