I can see two ways to hook up the ViewModel to the View. One is in XAML and the other thru dependancy injection in the code behind.
Which method is more preferable? I prefer the xaml method because I don't want any code in the code behind at all, but is there any issues with one over the other?
<navigation:Page x:Class="MyNamespace.MyViewModel"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:ViewModel="clr-namespace:MyNameSpace.MyViewModel"
xmlns:navigation="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Navigation"
Title="ViewModel Page" >
<navigation:Page.Resources>
<ViewModel:MyViewModel x:Key="ViewModel"></ViewModel:MyViewModel>
</navigation:Page.Resources>
<Grid x:Name="LayoutRoot" Background="White"
DataContext="{StaticResource ViewModel}">
</Grid>
</navigation:Page>
OR
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.Windows.Navigation;
namespace MyNamespace
{
public partial class MyView : Page
{
public MyView()
{
InitializeComponent(MyViewModel viewModel);
this.DataContext = viewModel;
}
}
}
I use a class I dub a "Screen" that handles the MVVM triad. I started out iwth a V being inject into a VM, then a VM as a resource in a V, but in the end the Screen concept worked best for me. It allows me to use a V and a VM without being coupled to each other. It also abstracts away other functionality in my overall presentation framework. Here is the constructor for my Screen class as an example:
public CatalogItemScreen(IUnityContainer container) : base(container)
{
this.ViewModel = Container.Resolve<ICatalogItemViewModel>();
this.View = Container.Resolve<CatalogItemView>();
this.View.DataContext = this.ViewModel;
}
Notice that VM is created in the Screen, the V is created here, and the 2 are bound to each other. This sample uses Unity and Prism, but it is not necessary to achieve this.
Shawn has a good post on View or ViewModel first. Having the VM in the XAML gives you Blendability (seeing sample data in Blend) which is cool, but the price is having to push info back into the View. John Papa has moved away from this approach for this reason.
I'm using Shawn's Marriage idea (see the link above).
HTH -Erik
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With