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.

Comments

Popular posts from this blog

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

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

Custom AuthorizationHandler for SignalR Hubs

How to implement IAuthorizationRequirement for SignalR in Asp.Net Core v5.0 Been battling this for a couple of days, and eventually ended up raising an issue on Asp.Net Core gitHub  to find the answer. Wanting to do some custom authorization on a SignalR Hub when the client makes a connection (Hub is created) and when an endpoint (Hub method) is called:  I was assuming I could use the same Policy for both class & method attributes, but it ain't so - not because you can't, because you need the signatures to be different. Method implementation has a resource type of HubInnovationContext: I assumed class implementation would have a resource type of HubConnectionContext - client connects etc... This isn't the case, it's infact of type DefaultHttpContext . For me I don't even need that, it can be removed completely  from the inheritence signature and override implementation. Only other thing to note, and this could be a biggy, is the ordering of the statements in th