J'ai entendu beaucoup de battage publicitaire à propos de MVVM pour WPF.
Quand l'utilisons-nous?
est-il une utilisation pour tout ou que cela n'a-t-il que des utilisations spécifiques?
est-il en vaut la peine pour chaque projet?
6 Réponses :
Je l'ai trouvé utile, même dans des projets relativement petits, si je fais beaucoup d'utilité de Databindinging et un modèle de données d'objet / modèles.
en termes de WPF et de Silverlight?
en théorie pour tout - chaque projet non trivial (et éventuellement alors). Sa part d'un processus plus large (cela crée une séparation des préoccupations et permet des tests et d'autres belles choses). Fondamentalement, si vous allez le faire (et je pense que vous voulez probablement, j'ai certainement l'intention de recevoir de nouveaux projets), vous devriez le faire à peu près au tableau.
Si vous ne l'avez pas déjà fait, allez regarder la vidéo liée à partir d'ici: http: // blog. Lab49.com/archives/2650 - J'ai trouvé très utile pour obtenir mes idées droites.
Il peut être utile dans n'importe quel projet, mais je trouve cela particulièrement utile dans des situations permettant une séparation claire entre la logique commerciale, la logique d'interaction et l'interface utilisateur est requise (applications importantes ou applications impliquant plusieurs développeurs / concepteurs).
modèle = logique commerciale
Il y a sans aucun doute de nombreuses autres utilisations pour MVVM, mais ce scénario particulier est celui que j'ai trouvé comme le plus utile dans ma propre expérience de développement du WPF.
Mieux vaut demander: quand ne devrait pas vous l'utilisez? L'exemple le plus évident est que la liaison des données n'est pas appropriée et que vous devez manipuler des éléments de la vue directement dans le code - si, par exemple, votre application doit mettre à jour l'état visuel des centaines ou des milliers d'éléments visuels en temps réel que vous pouvez ne pas être capable de donner la surcharge de la liaison de données.
Je travaille actuellement sur un grand projet, où nous implémentons MVVM, CAL (Guide de l'application composite) à Silverlight. Bien entendu, le niveau de séparation des préoccupations est très élevé .. mais
1) Le code devient trop robuste.
2) MVVM a superbe de petits projets (tous ces échantillons de bonjour mondial sur Internet), mais il réduit vos opportunités: par exemple, des événements routés (grand instrument) sont toujours des événements, mais comme vous le savez, c'est Strictement interdit de les utiliser directement, dès que ceci est code-derrière) si vous souhaitez suivre MVVM.
3) La liaison de commande ne fonctionne toujours pas correctement dans Silverlight (.NET4.0, VS2010). C'est une longue histoire, gardez simplement cette surprise à l'esprit lorsque votre délégué Canexecute n'entrera pas au début de l'application.
Une bonne réponse à votre question est "MVVM est bon pour des projets avec une logique UI simple".
Merci, Ilya.
Chaque fois que je commence à un projet simple et que je pense que "c'est tellement simple, MVVM serait surpeuîner", environ 8 heures plus tard, je vais à un point où je réalise que l'utilisation de MVVM ferait des choses beaucoup plus simple.
Donc, je dirais que la plupart du temps à l'aide de MVVM simplifie réellement votre logique d'assurance-chômage, même si vous pensez initialement que cela sera surchargé. Les projets ont l'habitude de devenir plus complexes au fil du temps et de la séparation de la logique d'entreprise et de la logique de la logique appliquée par MVVM permet au projet de se développer de manière beaucoup plus contrôlée que de vous avoir une logique d'entreprise et de l'interface utilisateur.