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:
- A new IoC nested lifetime scope is created,
- A WorkspaceFactory class is created inside the newly created IoC nested life scope,
- A new Workspace is created using the newly created WorkspaceFactory,
- Any XAML resource required for the Workspace are dynamically loaded,
- The view model is created and bound to the UI,
- 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:
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 ....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:
I've also pushed an updated version of this code base to github - Simple.Wpf.Composition.