Quels sont les avantages et les inconvénients de View-first par rapport à ViewModel-first dans le modèle MVVM?

Question

Je suis en train de faire une présentation sur l'utilisation de MVVM dans les applications du monde réel et je suis, y compris une section sur les guerres de religion , les décisions de conception impliqués lors de l'utilisation de MVVM comme un modèle dans votre application. Dans une application MVVM il y a deux façons principales (que je connais) pour instancier un nouveau point de Vue/ViewModel paire:

1. Vue-Première dans lequel vous créez un point de vue et il crée son propre ViewModel et il définit à son DataContext.
2. ViewModel-Première dans lequel vous créez de nouveaux modèles de vue et de créer de nouveaux points de vue en réponse à des changements dans le ViewModel propriétés, généralement avec ItemsControls et/ou DataTemplates.

Dans votre expérience, quels sont les avantages et les inconvénients de chaque méthode? Ce que permettent-elles et quels sont les problèmes que vous avez avec chaque?

Sommaire Des Résultats

---

• D'Abord La Vue - Des Pros
  • Facile de suivre le ViewModel est utilisé par une Vue
• D'Abord La Vue Ci - Contre
  • Ne permettent pas à une seule Vue pour être facilement utilisé avec plusieurs Viewmodel
  • Nécessite des événements supplémentaires pour gérer la communication entre les Vues et les ViewModels
• ViewModel Premier - Pros
  • Permet plus complet des tests de logique pour ouvrir de nouveaux points de Vue et Viewmodel
  • A tendance à être sèche-linge applications deviennent de plus en plus
  • Vue et ViewModel sont de plus en plus indépendante et peut être travaillé séparément plus facilement
• ViewModel Premier - Cons
  • Plus difficile à mettre en place dans Silverlight sans DataTemplateSelector et tapé les DataTemplates.

Answer 1

Étant donné les modèles de Données fonctionnalité dans WPF, je me sens ViewModel-le Premier est le WPF a été prévu pour être utilisé.

Je vais préciser cette affirmation: les modèles de Données vous permet de ne jamais instancier vue sur le ViewModel. Si fait correctement, votre point de Vue et Viewmodel pourrait être conservés dans divers projets qui NE font PAS référence les uns des autres. En outre, le ViewModel projet ne devrait même pas référence à un PresentationFramework assemblées, ce qui rend votre Viewmodel consommable par tous les utilisateurs.

Answer 2

J'ai tendance à préférer d'abord le modèle View, simplement parce que j'estime qu'il suit le mieux la règle DRY. Lorsque vous commencez à créer des applications à plus grande échelle, je trouve que cela facilite également les tests, dépassant ainsi le peu de mal de tête initial que vous devez gérer lors de la configuration de l'application.

Answer 3

Mise en garde - je utiliser WPF pas Silverlight.

Par la VM de l'instanciation de la V (qui est la façon dont je le fais) le point de vue est indépendant et peut être utilisé indépendamment de la machine virtuelle (par exemple dans une designer)

Personnellement, je suis un virage vers un MVVMC (modèle, Vue, ViewModel, Contrôleur) où j'ai un contrôle de classe qui instancie Viewmodel et de points de Vue et 'se joint à eux". Le C prend alors en charge l'obtention de données (et la mise en cache, etc.) et toute la communication entre VM et Vs (e.g si V est instancié, itinéraires d'une commande à son VM pour effectuer une action, la VM va probablement demander la C pour effectuer l'action en son nom; C peut alors soulever des événements qui les autres machines virtuelles peut gérer

Si (si l'utilisation d'un contrôleur ou pas) j'ai besoin d'une machine virtuelle pour parler à une autre machine virtuelle, il est plus difficile de le faire si la V instancie un VM - parce que non, je n'ai pour exposer la machine virtuelle dans le V (ou tout au moins de certains d'interface disponibles donc le 2ème VM pouvez parler à la 1ère).

Answer 4

Nous avons d'abord utilisé ViewModel, mais lorsque l'impartition est arrivée et que l'utilisation de la fusion est devenue la chose la plus importante, mon patron a déclaré que View-first était meilleur que Viewmodel-first. de votes ;-)), parce que maintenant nous avons quelques liens étranges avec des événements de vue en code derrière. Maintenant, je suis sur le point de ne pas revenir et je me suis retrouvé coincé dans certains contrôles personnalisés - à cause du changement.

Answer 5

J'utilise à la Vue de la première (sorte de) approche. J'définir l'Affichage en collaboration avec mes clients avec un mannequin viewmodel avec des données de test. Lorsque nous sommes satisfaits, je procéder pour extraire une interface à partir de la "crétin" et de mettre en œuvre le réel ViewModel. J'ai trouvé cette approche, la plus attractive pour les raisons suivantes:

• Il est rapide comme le prototypage est peu coûteux sur le plan du temps et j'ai souvent droit (ish) dans la quatrième ou la cinquième essai.
• Viewmodel ont tendance à être facile (plus facile) à mettre en œuvre lorsque j'ai une interface à respecter.

Je travaille dans WPF, mais je pense qu'il ne devrait pas être trop différent dans SL. Aussi, je n'ai jamais passer du temps sur le test des points de vue qui peuvent attribut de mon choix de l'approche.