IViewResolver
As we have already wrote when we spoke about Runtime Conventions Radical utilizes by default a view first approach, that even if is completely replaceable with a ViewModel first approach, must be understood.
The main and only entry point used to resolve views is IViewResolver interface whose role is to resolve a view instance given a view type:
1
IViewResolver service; //injected by the IoC engine
2
var viewUsingGenerics = service.GetView<SampleView>();
3
var viewUsingType = service.GetView( typeof( SampleView ) );
Copied!
At runtime when the GetView method is called the default built-in view resolver does the following things:
  1. 1.
    goes to the IoC container and resolves an instance of the requested view type;
  2. 2.
    if the view already has a DataContext it assumes that the view is a singleton and has been already resolved once and immediately returns the resolved view;
  3. 3.
    Otherwise, using the conventions:
  4. 4.
    Using the ResolveViewModelType convention determines the type of the associated ViewModel;
  5. 5.
    Resolves, via the container, the ViewModel;
  6. 6.
    Set the relation View – ViewModel;
  7. 7.
    Set the ViewModel as the DataContext of the View;
  8. 8.
    Attaches to the View the required behaviors;
  9. 9.
    Exposes services registered to be exposed as resources in the View
  10. 10.
    Returns the view to the caller;

How to use the IViewResolver in our application

The typical usage of the view resolver in the application is to open/show another view, the easiest way is to declare a dependency on the resolver in our component:
1
class SampleViewModel
2
{
3
readonly IViewResolver service;
4
5
public SampleViewModel( IViewResolver service )
6
{
7
this.service = service;
8
}
9
10
public void ShowAView()
11
{
12
var myView = this.service.GetView<MyView>();
13
myView.Show();
14
}
15
}
Copied!
We are using the simplest possible approach in order to keep the sample complexity really low.

Notes

  • In the above sample we are violating the MVVM pattern because we are dealing with a view within the ViewModel, in the chapter related to the MessageBroker we’ll see how to avoid this mix.
  • A view does not require a view model to work properly, the IViewResolver can resolve views that don't have view models;