Home/ Questions/Q 7048641
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T02:54:59+00:00

I am looking for a truly decoupled way of supporting navigation in a Silverlight

  • 0

I am looking for a truly decoupled way of supporting navigation in a Silverlight application using MVVM. I am trying to accomplish more of a “purist” implementation of the pattern where the UI is completely separated from the ViewModels so that the application can actually run entirely without a UI. To do this, I need to support navigation without UI concerns.

I have several ideas how to accomplish this (with Messaging, etc) but haven’t come up with a good way of “mapping” the View to the ViewModel so that the UI can show the appropriate View when the ViewModel is “displayed”. I recall coming across an article some time ago that described a solution to this very problem but can’t seem to locate it online anymore.

Does anyone know how to find this article or have any experience solving this problem?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    So here’s my somewhat long-winded description what we ended up doing:

    First, we decided to use the built-in Page Navigation framework. We had multiple reasons but since it is built-in and is also the navigation framework du jour in Windows 8, we opted to try this approach.

    I should also mention that we use MVVM Light and MEF in our applications. (This comes into play below.)

    To make this work, we created an application Shell (UserControl) that contains the Frame control. The Shell’s DataContext is set to an instance of the ShellViewModel which exposes a single CurrentPage property (of type String). We then bind the Frame’s Source property to CurrentPage. This approach is similar to Rachel’s app-level ViewModel.

    The ShellViewModel registers with the Messenger to receive CurrentPageChanged messages. When the message is received, the CurrentPage property is updated, the PropertyChanged event raised and the UI updated. The message originates from the NavigationService (which implements INavigationService and is injected/imported using MEF).

    The NavigationService exposes a NavigateTo method which accepts the string name of the ViewModel representing the destination. This name matches the contract name applied to the ViewModel when exported (using MEF) and used to lookup the instance using our ViewModelLocator.

    In the NavigateTo method, we use the ViewModelLocator to retrieve the ViewModel instance, call Deactivate on the current ViewModel (if one), call Activate on the new ViewModel then send the CurrentPageChanged message with the name of the new view as a parameter. Activate/Deactivate are helper methods on the ViewModels that allow us to perform any necessary tasks when the ViewModel is navigated to or from.

    This appears to be working well and gives us a very MVVM-ish implementation with all navigation isolated from our ViewModels via the INavigationService and messaging.

    The only down-side right now is that while we are using string constants in code to represent the ViewModel names, we are still hard-coding the strings in the Views to set the DataContext. I will be looking into a way to set the DataContext automatically as part of the navigation ‘tooling’.

    I should mention that this approach was parsed together from a number of sources, including (but not limited to) Rachel and the following links:

    http://blogs.microsoft.co.il/blogs/eladkatz/archive/2011/01/25/adapting-silverlight-navigation-to-mvvm.aspx

    http://blog.galasoft.ch/archive/2011/01/06/navigation-in-a-wp7-application-with-mvvm-light.aspx

    http://www.geoffhudik.com/tech/2010/10/10/another-wp7-navigation-approach-with-mvvm.html

    • 0