A Convention based Approach for wiring your Views to ViewModels in MVVM – AutoViewModelLocator

Preface

This post assumes you are familiar a bit with the MVVM concepts. Otherwise, here is a 5 minute overview from John Papa

How do you wire up your ViewModels to your Views in your WPF and Silverlight apps? Of course, the simplest approach is assigning your View Model’s instance to the View’s data context, in the code behind .

    /// <summary>
    /// Interaction logic for MainWindow.xaml
    /// </summary>
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            this.DataContext = new MainViewModel();
        }
    

Understanding The ViewModelLocator Concept

An alternate way to do the above task is via a ViewModelLocator implementation, mainly so that you can preserve the Blendability – to enable designers to see see the correct preview of the View. Laurent Bugnion has a pretty neat implementation of ViewModelLocator in his MVVM Light toolkit . A simple approach to use ViewModelLoator in MVVMLight is – you can create an instance of ViewModelLocator and keep it in App.xaml as a global resource, so that you can bind your views to that – As shown below. Assume we have a MainWindow.xaml view and a MainViewModel class as our view model

1 – Create a global resource in your App.xaml

    <Application.Resources>
        <!--Global View Model Locator-->
        <vm:ViewModelLocator x:Key="Locator"
                             d:IsDataSource="True" />
    </Application.Resources>

2 – You can bind to your locator from your Views.

<Window x:Class="MvvmLightApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow"
        Height="300"
        Width="300"
        DataContext="{Binding Main, Source={StaticResource Locator}}">

		<!-- More Xaml -->

</Window>	

If you are interested in the actual implementation of ViewModelLocator in MVVMLight, here is a ‘trimmed down’ version (The whole code of ViewModelLocator.cs is here in codeplex, under MVVMLight repository)

  public class ViewModelLocator
    {
        private static MainViewModel _main;

        /// <summary>
        /// Initializes a new instance of the ViewModelLocator class.
        /// </summary>
        public ViewModelLocator()
        {
            CreateMain();
        }

        /// <summary>
        /// Gets the Main property.
        /// </summary>
        public static MainViewModel MainStatic
        {
            get
            {
                if (_main == null)
                {
                    CreateMain();
                }

                return _main;
            }
        }

        /// Gets the Main property.
        public MainViewModel Main
        {
            get
            {
                return MainStatic;
            }
        }

        /// Provides a deterministic way to create the Main property.
        public static void CreateMain()
        {
            if (_main == null)
            {
                _main = new MainViewModel();
            }
        }

		//Clean up code omitted..

    }	

As you can see, you are expected to expose a property per ViewModel that returns a singleton instance of the same – so that we can bind to the same from the View.  Of course, the MVVMLight implementation is pretty clean and neatly blendable.

Locating ViewModels by Convention – AutoViewModelLocator

I was a bit lazy to create a property per ViewModel in the ViewModelLocator, and thought it is nice if I get my ViewModels resolved by convention. Thus born the AutoViewModelLocator. Have a look at the source code first.

 public class AutoViewModelLocator
    {
        private static List<object> _viewModels = new List<object>();

        /// <summary>
        /// Return the view model based
        /// </summary>
        /// <param name="name"></param>
        /// <returns></returns>
        public object this[string name]
        {
            get
            {
                //Need to have a cleaner way of doing this
                var type = typeof(AutoViewModelLocator).Assembly.GetTypes().First
                 (t => t.IsClass && t.Name.EndsWith(name + "ViewModel"));

                var obj = _viewModels.Find(vm => vm.GetType() == type);

                if (obj != null)
                {
                    return obj;
                }
                else
                {
                    obj = Activator.CreateInstance(type);
                    _viewModels.Add(obj);
                    return obj;
                }
            }
        }

        /// <summary>
        /// Cleans up all the resources.
        /// </summary>
        public static void Cleanup()
        {
            foreach (var vm in _viewModels)
            {
                //Cleaup here
            }
        }
    }

Nothing big there. As you can see, we are instantiating the view models based on reflection. In actual implementation, you may use a better resolution method, probably using an Container or so.

Anyway, now you can use the AutoViewModelLocator much like we explained earlier – by creating it as a global resource in App.xaml, and then binding to the same from the View. How ever, please note that in the View, we should bind to the Indexer from Xaml (Please have a look at the source code attached).

Let us test our Locator via a simple ViewModel and a View.

Our Minimal View Model

 //Our minimal view model
 public class MainViewModel
    {

        public string Data
        {
            get
            {
                return "Hello via AutoViewModelLocator";
            }
        }
    }

Binding the View

Note that we are binding the data context of the control to the Indexer of our AutoViewModelLocator. And we have a text box that binds to our above Data property. Here is how that looks like in Visual Studio.

And in Expression Blend 4.0

Happy Coding!!

[+] Download Related Source Code

 

There are more interesting reads here, make sure you read about

• 4 .NET 4.0 Libraries You *Should* Know Better – MEF, Reactive, Tasks and Dynamic
• Developing for Multicore machines. Tasks in .NET 4.0 – Why/What/How?

Advertisement

Posted in: .NET 4.0, CSharp, MVVM, Silverlight, WPF