dans le motif MVP, un présentateur a une interface de vue afin que le présentateur puisse appeler iview.dosomething () .. Qu'en est-il du modèle MVVM?
Selon le diagramme UML John Gossman's UML http: // blogs. msdn.com/johngossman/archive/2006/04/13/576163.aspx , viewModel n'a pas d'interface de vision. Donc, on dirait que le point de vue et la vue devraient être communiqués via une liaison uniquement. (ou utiliser un comportement de propriété ou de mélange connecté ou etc.).
Qu'est-ce que vous pensez?
4 Réponses :
L'ensemble des objectifs de MVVM est de réduire considérablement la quantité de code dans votre classe de code de code de votre formulaire WPF ou de votre contrôle utilisateur. L'idée est que tout ce qui serait traité à la vue du classique MVC / MVP peut être traduit par la machine virtuelle à l'aide d'une combinaison de liaison et / ou de commandes de données. Dans mon usage général de MVVM, j'ai réussi à supprimer complètement tout le code-derrière dans mes formulaires / contrôles utilisateur et que la machine virtuelle n'a aucune connaissance directe de la vue qu'il contrôle. Si vous avez une situation qui ne peut vraiment pas être traitée par la liaison de données ou une commande, veuillez élaborer votre question initiale et i (ou l'un des nombreux plus talentueux MVVM'ers ici) tenterons de vous diriger dans la bonne direction .
Merci. La question est de savoir si vous pensez avoir une interface de vue dans ViewModel enfreint le motif MVVM? Exemple: iPersonView, PERSONView and PERSONVIEWMODEL .. PERSONVIEWMODEL DANS IPERSONVIEW ...
Salut désolé raté le commentaire et vous voit que vous avez accepté Stians Répondre, mais une complétude ici est ma réponse. Je pense que cela viole le motif MVVM (dans ma compréhension) et que cela a maintenant mentionné à l'aide de la liaison des données via des propriétés exposées est le moyen de mettre à jour la vue. Content que tu as une réponse cependant :)
Merci, mec ... En fait, votre message m'a répondu aussi bien que le problème ici est que je ne peux pas marquer plus d'un poste tel que répondu. Comme il n'y a pas de règle standard et qu'aucun propriétaire / créateur de MVVM modèle, nous devons demander à tous que nous sommes tous d'accord sur cela ou non .. :) C'est pourquoi je pose la question à propos de MVVM dans différentes communautés et écrivez les informations résumées. Dans l'un de mes post ..
Je suis d'accord avec John Gossman. La manière dont le point de vue "parle" à la vue se fait par des liaisons seulement. En fait, la viewModel ne devrait pas se soucier de la vue du tout. Il devrait simplement effectuer des données disponibles via des propriétés, et il appartient à la vue de décider de ce qu'elle se liera de manière dynamique dans les menuisiers. Si le point de vue veut dire à la vue, cela devrait se produire implicite à travers des fixations.
Une question similaire a été posée il y a une heure - ici .
Merci beaucoup. J'ai accepté avec ça aussi. Quand j'écris ce post Michaelsync.net/2010/02/03/RULES- de-MVVM , certains ont dit qu'il est normal d'avoir l'interface de la vue dans ViewModel. Je leur ai dit que ce sera un modèle MVP. Bien sûr, nous pouvons mélanger les modèles, mais je pense avoir une interface de vision dans VM enfreignant le motif MVVM .. Merci de votre réponse .. Je l'apprécie vraiment.
On dirait que vous êtes sur la bonne voie. Heureux d'avoir pu aider. Va vérifier votre poteau de blog! :-)
Merci. S'il vous plaît laissez-moi savoir si vous avez un commentaire ou une suggestion pour ce post .. :)
Nice post :-) Une chose que j'aime est que je puisse avoir les classes de modèle tout propre - ne pas ajouter de choses là-bas simplement parce que cela est nécessaire à la vue. Par exemple. Je n'ai pas besoin de garder une liste triée juste parce que la vue veut qu'il soit triée - c'est le point de conduire. Mais vous avez couvert cela en disant que le modèle peut être clair DTO.
Merci, tache .. la plupart des gens ont convenu avec tous les faits (sauf un) que j'ai mentionné à propos de MVVM dans ce poste .. la seule chose que les gens ne sont pas d'accord pour dire que certaines personnes pensent qu'ils peuvent avoir une interface de vue dans ViewModel.
Cela fait généralement - à travers des événements sur InotifyProperty a changé, si rien d'autre.
Je suis désolé. Je ne vous ai pas eu .. Parlez-vous d'avoir une interface de vision dans la machine virtuelle?
En supposant que vous parliez C #, les événements exposés à l'interface inotifypropertychanged sont généralement écoutés (via une liaison de données) par la vue. La liaison de données n'est pas vraiment magique - il suffit de connecter des gestionnaires à des événements sur InotifyPropertychangned et inotifyCollectionChanganed. Mais oui, je dirais que, typiquement, le VM parle à la vue, pour l'informer des modifications de données. Cela a une idée d'une vue abstraite et non d'une mise en œuvre particulière - sa communication devrait être limitée à "Ceci changé" et non "alors changez ce contrôle"
Oui .. donc, "cela a changé" limitation = reliure de données, non? :)
Ouais :) Mais je ne vois pas vraiment de problème avec d'autres types de communication, tant que c'est essentiellement envoyé des données, et aucune connaissance de la vue fuit. D'autres peuvent être plus puristes que moi :)
Un point de vue peut-il parler à la vue dans le motif MVVM?
Oui, mais d'une manière découplée. Il est permis d'introduire une interface iview pour la communication.
Le motif MVVM est sur le point de déplacer la logique de la vue dans la vue de la vue. De cette façon, nous sommes en mesure de tester cette logique.
J'ai regardé WAF Long Time Retour. J'ai vu que le créateur de WAF a défini le mot de passe dans le code derrière en démo. Je ne sais pas pourquoi il fait ça. >> Oui, mais d'une manière découlette. Alors, quelles seraient les différences entre le modèle MVP et MVVM? Nous pouvons également déplacer la logique au présentateur en MVP. Pensez-vous que c'est bien de définir iview.Doshanging de ViewModel?
Du point de vue du découplage et de la testabilité, il est définitivement autorisé à appeler iview.Dosomething de la vue de la vue. Si vous utilisez plutôt une liaison, vous définissez une propriété de la vue. Donc, la vue connaît la propriété de la viewModel. C'est juste que la reliure utilise la réflexion (pas de type sécuritaire) mais le couplage est identique.
Pour découplage et testabilité, nous n'avons même pas besoin d'utiliser le motif MVVM. Mvc ou mvp ou etc sont aussi testables. J'ai encore deux questions. 1) Si vous avez dit qu'il est normal d'avoir une interface de vision dans ViewModel. Pouvez-vous me dire les différences entre MVP ou MVVM? Vous pouvez également lire ma discussion avec Glenn dans ce lien groups.google.com / Groupe / WPF-Disciples / BrowseSe_thread / Filetage / ... aussi. 2) Pensez-vous que ça va de faire ((ViewModel) this.datacontext) .Dother () en vue aussi?
1) Pour moi, MVVM est identique au motif de présentationModel ( martinfowler.com/eaadev/presentationModel.html) qui est également l'opinion de l'équipe Microsoft P & P ( msdn.microsoft. com / fr-nous / bibliothèque / cc707885.aspx ). 2) Oui, je crois que c'est bien de faire: ((ViewModel) this.datacontext) .DOTHAT (). La vue est autorisée à connaître sa vue associéemodel.
Mvvm = présentationModel. mais si on peut faire ((ci-après), cela.datacontext) .DOTHAT () alors pourquoi les gens créent la propriété ci-jointe ou le blende Behivor. Si vous regardez la réponse des autres, la plupart des gens croient que la communication entre View et VM est Binding Overnly ..
C'est le but. Beaucoup de gens croient que MVVM est environ zéro lignes de code dans le fichier de code-derrière. Cela pourrait avoir des avantages pour le flux de travail des concepteurs / développeurs. Cependant, si vous ne vous souciez que de couplage et de test de test de test, alors "var nom = ((((ViewModel) this.datacontext.name" est le même que "{chemin de liaison = nom}". La liaison récupère également la propriété de DataContext - Pourquoi cela devrait-il sois différent?
Les différences entre le motif MVP et MVVM sont que la vue et la viewModel parlent par liaison. C'est la raison principale pour laquelle ils ont ajouté la propriété attachée ou le comportement de mélange dans le cadre. Sinon, nous n'avons même pas besoin de MVVM. Nous pouvons simplement coller avec MVP. J'ai travaillé avec des frameworks de taxi et de SCSF pendant des années. Je suis sûr que le modèle MVP fonctionne très bien. Mais nous devons synchroniser les données entre V et P. Nous ne voulons pas cela. Ainsi, la liaison est la solution pour éliminer la synchronisation manuelle.
Salut Skaffman, merci .. Qu'avez-vous édité? :)
Il a ajouté l'étiquette des motifs design. Vérifiez l'historique de modification en cliquant sur le texte "modifié".
Merci ... super ... je n'ai pas vu ce texte "édité" .. Je ne vois que "Edit | Rollback | Supprimer | Drapeau". Quoi qu'il en soit, merci d'avoir ajouté une autre tag pour mon post ...