Accrochage du ViewModel à la vue dans Silverlight

Question

Je peux voir deux façons de raccorder ViewModel à la vue. L'un est en XAML et l'autre à travers l'injection de dépendance dans le code derrière.

Quelle méthode est la plus préférable? Je préfère la méthode xaml parce que je ne veux pas du tout de code dans le code, mais y a-t-il des problèmes avec l'un sur l'autre?

<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> 

OU

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; 
     } 
    } 
} 

Answer 1

Shawn a un bon post sur View or ViewModel premier. Avoir la VM dans le XAML vous donne une Blendability (voir des exemples de données dans Blend) ce qui est cool, mais le prix à payer est de repasser les informations dans la View. John Papa s'est éloigné de cette approche pour cette raison. J'utilise l'idée de Shawn's Marriage (voir le lien ci-dessus).

HTH -Erik

Answer 2

La façon dont vous avez ici, j'irais avec XAML. Il existe d'autres façons de définir la propriété DataContext. Si vous êtes intéressé, regardez le framework Microsoft CAG pour WPF.

Answer 3

J'ai mis la machine virtuelle dans le code parce que ce test de faire de la vue beaucoup plus facile. Justin Ange a un grand message pour cela:

public partial class Page : UserControl 
{ 
    private PageViewModel _viewModel = new PageViewModel(); 

    public PageViewModel ViewModel 
    { 
     get { return _viewModel; } 
     set { _viewModel = value; } 
    } 

    public Page() 
    { 
     InitializeComponent(); 
     this.Loaded += new RoutedEventHandler(Page_Loaded); 
    } 

    void Page_Loaded(object sender, RoutedEventArgs e) 
    { 
     this.DataContext = ViewModel; 
    } 

} 

Je trouve son poste très utile pour l'apprentissage sur les intricasies des tests entourant le modèle MVVM.

http://silverlight.net/blogs/justinangel/archive/2009/02/25/silverlight-unit-testing-rhinomocks-unity-and-resharper.aspx

Answer 4

J'utilise une classe I dub un "écran" qui gère la triade MVVM. J'ai commencé avec un V injecté dans une VM, puis une VM comme ressource dans un V, mais à la fin le concept Screen a fonctionné le mieux pour moi. Cela me permet d'utiliser un V et un VM sans être couplés les uns aux autres. Il extrait également d'autres fonctionnalités de mon cadre de présentation global. Voici le constructeur de ma classe d'écran comme exemple:

public CatalogItemScreen(IUnityContainer container) : base(container) 
    { 
     this.ViewModel = Container.Resolve<ICatalogItemViewModel>(); 
     this.View = Container.Resolve<CatalogItemView>(); 
     this.View.DataContext = this.ViewModel; 
    } 

Notez que VM est créé dans l'écran, le V est créé ici, et les 2 sont liés les uns aux autres. Cet exemple utilise Unity et Prism, mais il n'est pas nécessaire d'y parvenir.