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.