2010-05-05 8 views
4

Je suis nouveau dans le monde Mvvm & Wpf, mais j'ai trouvé quelques exemples et juste trouvé qu'il existe une façon différente d'instancier le modèle. Je voudrais savoir la meilleure façon de le faire. les deux façons utilisent l'unitéWPF + MvvM + Prism

Ce que j'ai Foud:

var navigatorView = new MainView(); 
navigatorView.DataContext = m_Container.Resolve<INavigatorViewModel>(); 
m_RegionManager.Regions["NavigatorRegion"].Add(navigatorView); 

Ce que je l'ai fait:

var navigatorView = m_Container.Resolve<MainView>; 
m_RegionManager.Regions["NavigatorRegion"].Add(navigatorView); 

et j'ai changé le constructeur pour recevoir viewmodel je peux pointer le datacontext à lui:

public MainView(NavigatorViewModel navigatorViewModel) 
{ 
this.DataContext = navigatorViewModel; 
} 

D'autres exemples que j'ai trouvé une autre façon comme:

...vm = new viewmodel 
...m = new model 
v.model = vm; 

get/set DataContext

acclamations

Répondre

0

Qu'est-ce que vous avez là un sens et dans les deux cas est une vue première approche de la création d'un viewmodel. C'est à dire. la vue crée le ViewModel. Dans l'exemple original, le viewmodel est créé en dehors de la vue (et est parfois appelé marriage pattern), mais en ce qui me concerne c'est la même chose - la création de la vue crée le ViewModel.

Si cela vous convient, respectez-le. Une autre approche que vous pourriez regarder dans est ViewModel d'abord où le viewmodel prend une dépendance à la vue comme ceci:

//In the bare-bones(i.e. no WPF dependencies) common interface assembly 

interfac IView { 
    void ApplyViewModel(object viewmodel); 
}  

interface IMainView : IView { 
    //this interface can actually be empty. 
    //It's only used to map to implementation. 
} 

//In the ViewModel assembly 

class MainViewModel { 
    public MainViewModel(IMainView view) { 
    view.ApplyViewModel(this); 
    } 
} 

public partial class MainView : UserControl, IMainView { 
    void ApplyViewModel(object viewmodel){ 
    DataContext = viewmodel; 
    } 
} 

Ensuite, vous pouvez injecter ce point de vue comme ceci:

IRegion region = regionManager.Regions["MainRegion"]; 

//This might look strange as we are resolving the class to itself, not an interface to the class 
//This is OK, we want to take advantage of the DI container 
//to resolve the viewmodel's dependencies for us, 
//not just to resolve an interface to the class. 
MainViewModel mainViewModel = container.Resolve<MainViewModel>(); 

region.Add(mainViewModel.View, "MainView"); 
region.Activate(ordersView.View); 
8

J'aime la suggestion d'Igor, mais sans que le viewmodel ait connaissance de la vue. Je préfère mes dépendances pour aller dans une direction (View -> ViewModel -> Model).

Ce que je fais est ViewModel-First et juste DataTemplate le viewmodel. Donc, je fais ceci:

MainViewModel mainViewModel = container.Resolve<MainViewModel>(); 

region.Add(mainViewModel, "MainView"); 
region.Activate(mainViewModel); 

Avec l'ajout de la ViewModel -> Voir la cartographie fait avec un DataTemplate WPF (je ne pense pas que cette approche est possible avec Silverlight, cependant)

App.xaml:

<Application.Resources> 
    <DataTemplate DataType="{x:Type viewModels:MainViewModel}"> 
      <views:MainView /> 
    </DataTemplate> 
</Application.Resources> 

C'est tout! J'aime cette approche. J'aime la sensation magique. Il présente également les avantages suivants:

  • Ne pas avoir à modifier les constructeurs en fonction de la cartographie
  • Ne devez vous inscrire pour le type IMyViewModel dans le récipient ... vous pouvez travailler avec des types concrets. J'aime garder mes inscriptions aux services d'application comme IViewRegistry ou ILogger ...ce genre de choses
  • Vous pouvez modifier le mappage en utilisant des ressources limitées à une vue particulière d'une région (cela est pratique si vous souhaitez réutiliser vos ViewModels mais souhaitez qu'elles soient différentes dans les différentes zones de l'application)
+3

C'est l'approche que la plupart des développeurs MVVM "traditionnels" utilisent ... le problème de l'utilisation de DataTemplate lors de l'introduction de PRISM a été très négligé ou rendu confus avec l'utilisation d'exemples MVP. –