Pourquoi mettre en œuvre une interface sur le viewmodel et les afficher dans mvvm
Je suis assez nouveau dans le pattern MVVM, de sorte s'il vous plaît garder avec moi. J'ai vu implemnentations dans wpf +mvvm + prisme où tous les points de vue ont tendance à avoir un IView que tout en haut de l'interface. Ensuite, les points de vue dans les différents modules ont un point de vue spécifique de l'interface comme IViewA, IViewB etc qui mettent en œuvre les IView interface. Même le viewmodel a IViewModel en haut de l'interface et de la suite des modules ont IViewAViewModel , IViewBViewModel etc qui héritent de la IViewmodel. IViewmodel a une référence à Iview et le Iview a une référence à IViewModel.
namespace xxx.xxx.infrastructure
{
public interface IView
{
IViewModel ViewModel {get;set;}
}
public interface IViewModel
{
IView View {get;set;}
}
public abstract class ViewModelBase : IViewModel, INotifyPropertyChanged
{
public IView View {get;set;}
public ViewModelBase(IView view)
{
View = view;
View.ViewModel = this;
}
//INotifyPropertyChanged left out
}
}
namespace xxx.xxx.Modules.Customer
{
public interface ICustomerDetailsView : IView
{
}
public partial Class CustomerDetailsView : UserControl, ICustomerDetailsView
{
public CustomerDetailsView ()
{
InitializeComponent();
}
//Is this implementation acceptable?The view is supposed to have zero code in the code behind.....
public IViewModel ViewModel
{
get
{
return (ICustomerDetailsViewViewModel)DataContext;
}
set
{
DataContext = value;
}
}
}
public interface ICustomerDetailsViewViewModel : IViewModel
{
string Message {get;set;}
}
public class CustomerDetailsViewViewModel : ViewModelBase, ICustomerDetailsViewViewModel
{
//Will be injected by unity as i have set up mappings in module initilize.
public CustomerDetailsViewViewModel(ICustomerDetailsView view)
:base(view)
{
}
public string Message
{
//INotifyPropertyChanged left out for brevity
get;set;
}
}
J'ai quelques questions.
1.)Ce n'est pas une violation de MVVM en tant que fichier code-behind, est censé avoir zéro code?
2.)dans MVVM modèle de vue ne devrait pas s'inquiéter de la vue ou de son contrat?Ne marche pas au-dessus de la mise en œuvre de la casser?
3.)Je ne comprends pas qu'est-ce que l'utilisation de cette mise en œuvre. En fait, c'frontières sur le titre de MVP et beaucoup de code est nécessaire.
4.)Si c'est une façon acceptable de mettre en œuvre, ai-je besoin d'avoir des interfaces pour tous les points de vue et viewmodel dans tous mes modules.?
Sa en fait pas la mise en œuvre concrète de la vue, mais seulement une interface de la vue. Je peux argumenter en disant que cela satisfait MVVM parce que la VM n'a aucune idée à propos de la Fenêtre/Page qui implémente IView
Oui, mais encore le point de vue du modèle doit savoir sur le contrat de la vue. Ce qui signifie plus d'accouplement qu'avec un indépendant ViewModel. Pourquoi avez-vous besoin que lorsque les liaisons bidirectionnelles sont en place? Imaginez quand vous avez besoin de plusieurs points de vue à partager le même modèle de vue (par exemple, étroitement liées à de multiples composants de l'INTERFACE utilisateur dans la même fenêtre).. Ne sais pas comment ça fonctionne en WPF, mais je n'ai utilisé que comme une pratique puissante en Javascript frameworks MVVM.
un "Modèle de Vue" n'est pas le modèle; il s'agit plus d'un "contrôleur" ou "présentateur" qui découple la vue à partir du modèle réel. Bien sûr, un vrai modèle est facultative et dans de nombreuses situations de la VM agit en tant que modèle...
Absolument d'accord avec vous, pas besoin d'injecter tout IView dans le ViewModel. MVVM basé sur le modèle de Modèle de Présentation, de sorte que la Vue de soucis de synchronisation de l'état avec Vue(Présentation)Modèle. ViewModel juste besoin de lever de l'événement qu'il a été modifié et d'Afficher sinchronize (via un événement d'abonnement ou de liaison). Si IView injecte dans le ViewModel, cela signifie que le ViewModel de soucis de synchronisation avec les états-elle, et la regarde comme MVP de la Supervision du Contrôleur.
OriginalL'auteur Hari Subramaniam | 2012-07-13
Vous devez vous connecter pour publier un commentaire.
Fondamentalement, nous avons besoin des interfaces pour les injections. Il y a 2 façons:
Cela signifie que ce Dernier n'a plus aucune référence à la Vue. Cela signifie que lors de tests unitaires le ViewModel vous n'avez pas besoin d'un simulacre de vue. En outre, il rend le code plus propre, en ce que dans le constructeur de la Vue, il suffit simplement de définir le DataContext de la ViewModel qui a été injecté.
Il évite de garder une logique de workflow dans la couche de Présentation. Cela signifie que l'Application de la couche de garde responsable de l'application de flux de travail.
De cette façon, la logique de workflow est très couplé avec le point de Vue et il est donc tout à fait impossible d'écrire le test unitaire pour cela.
OriginalL'auteur Alex Klaus
tout d'abord un très beau commentaire de Rachel concernant viewmodel première:
1) IView est une violation de MVVM pour moi, mais le code-behind est bien sûr autorisé pour des éléments d'interface utilisateur. viewmodel faut juste ne fait aucune référence à la vue. voir le 1er commentaire de Hasith
2) voir mon blockquote
3) je suis avec vous, je n'ai jamais utiliser quelque chose comme ça dans mes projets
4) pls ne MVVM le moyen le plus facile - pas de couplage, utilisez di, cio, les commandes, les comportements et pour moi le plus important: viewmodel premier:)
OriginalL'auteur blindmeis