Pourquoi utiliser MVVM?

Question

Bon, j'ai été à la recherche dans le pattern MVVM, et à chaque fois j'ai déjà essayé de chercher en elle, j'ai donné pour un certain nombre de raisons:

1. Supplémentaires Inutiles De Longue Haleine De Codage
2. Pas d'avantages apparents pour des codeurs (pas de concepteurs dans mon bureau. Actuellement, seulement moi-même peu être un autre programmeur)
3. Pas beaucoup de ressources et de documentation des bonnes pratiques! (Ou du moins difficile à trouver)
4. Ne peut pas penser à un seul scénario où c'est avantageux.

Je suis sur le point de renoncer à elle encore une fois, et j'ai pensé demander à voir si quelqu'un répondre aux raisons ci-dessus.

Honnêtement, je ne peux pas voir un avantage de l'utilisation de ce pour un seul partenaire/de codage. Même dans des projets complexes avec de 10 de windows. Pour moi le jeu de données est une assez bonne vue et de liaison, comme dans la réponse Brent suivants question

Quelqu'un pourrait-il montrer un exemple d'où l'utilisation du pattern MVVM serait un gain de temps, comparativement à XAML de la liaison de données.

100% de ma liaison est fait dans le code XAML pour le moment. Et donc je ne vois pas l'intérêt de la VM comme sa juste code supplémentaire derrière que j'ai besoin d'écrire et compter.

EDIT:
Après avoir passé l'après-midi à faire des recherches sur MVVM j'ai enfin trouvé quelque chose qui m'a fait comprendre les avantages de cette réponse.

Answer 1

Je ne suis pas trop heureux avec les questions / réponses, donc je vais ajouter mon propre:

Quand évitez les motifs

Pour un niveau suffisamment simple demande à chaque modèle de conception est exagéré. Supposons que vous écrivez une application graphique qui affiche un unique bouton qui, lorsqu'il est pressé affiche "Hello world". Dans ce cas, les modèles de conception comme MVC, MVP, MVVM tous les ajouter beaucoup de complexité, tout en n'ajoutant pas de quelque valeur que ce soit.

En général, il est toujours une mauvaise décision d'introduire un modèle de conception juste parce qu'il s'adapte un peu. Les modèles de conception devraient être utilisés pour réduire la complexité, soit directement par la réduction globale de la complexité, ou par le remplacement de l'inconnu de la complexité avec des familiers de la complexité. Si le modèle de conception ne peut pas réduire la complexité dans l'une de ces 2 façons, ne l'utilisez pas.

Pour expliquer familier et non familier de la complexité, prenez les 2 séquences de caractères:

• "D.€|Ré%dfà?c"
• "CorrectHorseBatteryStaple"

Tandis que la deuxième séquence de caractères est deux fois la longueur de la première séquence, il est plus facile à lire, plus rapide à écrire, et plus facile à retenir que la première séquence, tous parce qu'il est de plus en plus familiers. Le même est vrai pour des motifs familiers dans le code.

Être conscient du fait que certains modèles peuvent ne pas être familiers à tous les développeurs qui vont travailler avec le code dans l'avenir. Dans les conditions de l'exemple précédent, la séquence suivante peut ou ne peut pas être plus facile à retenir que les séquences ci-dessus, selon les compétences individuelles de la personne à mémoriser: "3.14159265358979323846264338327950". Dans certains cas où les plus avancées des modèles de conception sont en cause, il n'a de sens que pour utiliser un modèle de conception si l'entretien développeurs sont déjà familiers avec elle.

MVVM

Cela dit, nous allons plonger dans le sujet de MVVM par le biais d'un exemple. MVVM guides sur la façon de répartir les responsabilités entre les classes dans une application graphique (ou entre les couches - plus sur cela plus tard), avec l'objectif de disposer d'un petit nombre de classes, tout en gardant un certain nombre de responsabilités par la classe de petite et bien défini.

"Bon" MVVM suppose au moins modérément complexe d'application, qui traite avec des données qu'il obtient à partir de "quelque part". Il peut obtenir les données à partir d'une base de données, un fichier, un service web, ou à partir d'un myrad d'autres sources.

Exemple

Dans notre exemple, nous avons une Vue et un Modèle, mais pas ViewModel. Le Modèle encapsule un fichier csv qui il lit sur le démarrage et l'enregistre quand l'application s'arrête, avec toutes les modifications de l'utilisateur sur les données. La Vue affiche les données du Modèle dans un tableau et permet à l'utilisateur de modifier les données.

Maintenant on nous demande de faire un changement pour notre application. Les données se compose d'un 2-dimensions de la grille qui a déjà une colonne "prix", qui contient un prix en USD. Nous avons besoin d'ajouter une nouvelle colonne qui indique les prix en Euros, en plus de ceux en USD, basés sur l'avancement du taux de change. Le format du fichier csv ne doit pas changer parce que d'autres applications de travail avec le fichier de trop.

Une solution possible est de simplement ajouter une nouvelle colonne à la classe du Modèle. Parce que le Modèle enregistre toutes les données qu'il expose à la Vue à partir d'un fichier csv, et nous ne voulons pas d'un nouveau prix en Euro colonne du fichier csv, la modification du Modèle pourrait être non négligeable. Il serait également difficile de décrire ce que le Modèle de classe.

On pourrait aussi faire le changement dans la Vue, mais actuellement, notre application utilise la liaison de données pour afficher les données directement fournies par notre Modèle de classe. Parce que notre GUI cadre ne nous permet pas d'introduire un supplément de colonne calculée dans une table si la table de données est lié à une source de données, nous aurions besoin de faire un changement significatif de la Vue pour faire ce travail, en faisant le point de Vue beaucoup plus complexe.

Il n'y a pas de ViewModel dans l'application car jusqu'à présent, le Modèle présenté les données exactement de la façon dont la Vue avait besoin. C'est une bonne chose. Parce que le Modèle ne présente plus les données dans la façon dont la Vue a besoin d'elle, nous pouvons maintenant écrire un ViewModel. La nouvelle ViewModel souscrit au Modèle, et expose les données du Modèle de la Vue avec une colonne supplémentaire indiquant le prix en Euros. La Vue ne connaît plus le Modèle, il ne connaît que le ViewModel, qui regarde la même chose pour la Vue comme le Modèle n'a avant - sauf que les exposés de données contient une nouvelle lecture seule colonne.

La prochaine demande de la clientèle est qu'il ne faut pas afficher les données sous forme de lignes dans une table, mais au lieu d'afficher les informations de chaque élément (un.k.un. ligne) comme une carte/boîte, et l'affichage de 20 cases sur l'écran dans un 4x5 grille, montrant 20 cases à la fois. Parce que nous avons gardé la logique de la Vue simple, il nous suffit de remplacer la Vue entièrement avec une nouvelle classe qui fait que les désirs de la clientèle. Si vous êtes dans cette situation avant, vous savez qu'il y a un autre client qui a préféré l'ancien point de Vue. Maintenant, vous avez besoin pour soutenir à la fois, mais parce que l'ensemble de la commune de la logique d'entreprise arrive à être dans le ViewModel qui n'est pas vraiment un problème.

La prochaine demande du client, c'est que nous tirez le taux de change de l'internet, plutôt que d'utiliser un client fourni des taux de change. C'est le point où nous revenir à ma déclaration précédente sur un "couches". Nous ne changeons pas notre Modèle de classe afin de fournir un taux de change. Au lieu de nous écrire (ou trouver) une complètement indépendante de classe supplémentaire fournit le taux de change. Cette nouvelle classe devient une partie de la couche du modèle, et notre ViewModel consolide les informations au format csv-Modèle et le taux de change de Modèle, qu'il présente ensuite à la Vue. Pour ce changement, l'ancien Modèle de la classe et de la classe de la Vue n'ont même pas à être touché.

Si nous n'avions pas introduit le ViewModel lorsque nous avons fait, mais a attendu jusqu'à maintenant pour ce faire, la quantité de travail pour introduire le ViewModel maintenant serait plus élevé parce que nous avons besoin d'éliminer une grande quantité de fonctionnalités à partir à la fois de la Vue et du Modèle, puis déplacer la fonctionnalité dans le ViewModel.

Résumé

• MVVM guides sur la façon de répartir les responsabilités entre les classes dans une application graphique.
• ViewModel projets les données à partir du Modèle dans un format qui s'adapte à la Vue.
• Pour trivial projets MVVM est unnecesary. En utilisant seulement le point de Vue est suffisante.
• Pour des projets simples, le ViewModel/Modèle split peut être inutile.
• Modèle et ViewModel n'ont pas besoin d'exister depuis le début, et peuvent être mises en place lorsqu'elles sont nécessaires.

Conclusion sur les Tests Unitaires

Le but principal de MVVM n'est pas que le code dans le Modèle et le ViewModel peut être mis sous Test Unitaire. Le but principal de MVVM est que le code est divisé en classes, avec un petit nombre de responsabilités bien définies. Un des nombreux avantages d'avoir un code composé de classes avec un petit nombre de responsabilités bien définies, c'est qu'il est plus facile de mettre le code en vertu de l'Unité de Test. Un beaucoup plus grand avantage est que le code est plus facile à comprendre, à maintenir et à modifier.

Answer 2

La mise en œuvre de modèles et les meilleures pratiques suivantes se sentent souvent comme inutile activités, mais vous allez devenir un de convertir lors des mois en bas de la route à votre patron vous demande d'ajouter ou modifier une fonctionnalité. En utilisant MVVM (et les modèles en général), vous allez réellement être en mesure de suivre votre propre code et de satisfaire à l'exigence en quelques heures ou quelques jours, au pire, au lieu de semaines ou de mois. (Ce changement est susceptible d'être à seulement quelques lignes de code plutôt que de passer des semaines à essayer de comprendre comment vous avez fait ce que vous avez fait, en premier lieu, avant même de tenter d'ajouter de nouvelles fonctionnalités.)

Suivi: les Modèles et les meilleures pratiques seront effectivement ralentir le développement initial et qui est souvent difficile à vendre pour la gestion et l'ingénierie de même. Le retour sur investissement (ROI en biz termes), c'est d'avoir bien structuré code qui est en fait maintenable, évolutif et extensible.

Par exemple, si vous suivez MVVM correctement, vous devriez être en mesure de faire des changements drastiques à la logique d'affichage, telles que la permutation d'une vue d'ensemble, sans impact sur les données et biz logique.

Une pensée à propos de l'utilisation des ensembles de données pour votre modèle: (en fait, j'ai craqué pour ça.) Ensembles de données sembler comme un bon moyen de se déplacer dans le modèle de données dans une application. Le problème vient de la manière dont vous identifier les éléments de données. Parce que vos données sont stockées dans les lignes et les colonnes que vous avez à effectuer des recherches par nom de colonne ou de l'index ainsi que d'avoir à filtre pour une ligne particulière. Ces bits de la logique veux dire d'avoir à utiliser la magie des chaînes et des nombres dans le câblage de la logique dans votre application. À l'aide d'un dataset typé permettrait d'atténuer certains de cette question, mais pas complètement. À l'aide de datasets typés vous seriez éloigner de MVVM et plus serrées de couplage entre l'INTERFACE utilisateur et la source de données.

Answer 3

Cela vous aide à distinguer l'interface graphique et la logique du programme; En les mélangeant, il peut s'avérer très difficile de maintenir les applications, en particulier lorsque votre projet évolue avec le temps.

Answer 4

À partir d' ici:

Pourquoi devriez-vous, en tant que développeur, même soins sur le Modèle model-View-ViewModel motif? Il y a un certain nombre de les avantages de ce modèle apporte à la fois WPF et Silverlight de développement. Avant de commencer, demandez-vous:

• Avez-vous besoin de partager un projet avec un designer, et ont le flexibilité pour le travail de conception et de les travaux de développement d'arriver quasi-simultanément?
• Avez-vous besoin d'complète de tests unitaires pour vos solutions?
• Est-il important pour vous d'avoir des composants réutilisables, tant à l'intérieur et à travers les projets dans votre organisation?
• Vous souhaitez disposer de plus de flexibilité pour modifier votre interface utilisateur sans avoir à refactoriser autre logique dans la base de code?

Si vous avez répondu "oui" à l'une de ces des questions, ce sont juste quelques-uns des les avantages que l'utilisation du modèle MVVM apporter pour votre projet.

Answer 5

• Il est plus facile de travailler avec des concepteurs (pas les programmeurs, juste les utilisateurs de Blend)
• Le code est testable (tests unitaires)
• Il est beaucoup plus facile de changer de vue sans jouer avec le reste du code
• Pendant que vous développez l'interface utilisateur, vous pouvez simuler le modèle et développer votre interface sans exécuter de service réel (en utilisant simplement les données simulées du modèle). Ensuite, il vous suffit d'inverser le drapeau et de vous connecter au service.