MVVM dans WPF est-il obsolète? [fermé]


18

J'essaie actuellement de faire tourner la tête MVVM pour WPF - je ne veux pas dire mettre la tête autour du concept, mais autour des écrous et boulons réels de faire quoi que ce soit qui soit plus hors des sentiers battus que CRUD stupide.

Ce que j'ai remarqué, c'est que beaucoup de frameworks, et la plupart / tous les articles de blog datent d'âges.

Est-ce parce que c'est désormais un vieux chapeau et que les blogueurs sont passés à la Next Big Thing, ou simplement parce qu'ils ont tout dit?

En d'autres termes, y a-t-il quelque chose qui me manque ici?


1
MVVM Frameworks for WPF a continué d'être mis à jour. Le nouveau sujet de programmation réactive [google it!] Est disponible en tant que MVVM via ReactiveUI . 3 des 10 meilleurs téléchargements de pépites wpf sont des frameworks MVVM: Prism.WPF, MvvmCross, Caliburn.Micro. AFAIK, tous ces éléments prennent également en charge Xamarin.Forms et UWP, donc seront pertinents pour les années à venir.
ToolmakerSteve

Réponses:


6

MVVM n'est pas obsolète, mais il a été surestimé pour commencer. Je ne l'ai jamais aimé et cela m'a gardé trop longtemps dans WinForms; à défaut de voir la forêt pour les arbres, j'ai jeté le bébé avec l'eau du bain. Je reçois WPF maintenant, et j'ai l'idée de ne pas vouloir mélanger le code avec le balisage, mais je préfère le style Android de coller le balisage en un seul endroit et de le déréférencer avec des transtypages dans mon code (ce que vous pouvez également faire dans WPF, même bien qu'il n'ait jamais été tendance à le faire pour une raison quelconque).

De cette façon, vous gagnez un contrôle plus fin et vous n'avez pas à vous soucier de toute la manipulation "inchangée" partout. Je pense que c'est en fait plus testable parce que les tests ne l'attraperont pas toujours si vous manquez un événement "onchanged".

Vous perdez un peu de "déclarative", ce qui semble être une tendance de nos jours (par exemple, si deux widgets sont mappés à la même valeur, dans MVVM, vous pouvez simplement le faire, alors qu'avec le code impératif, vous devez définir les deux individuellement) . Mais même avec MVVM, cela ne fonctionne que dans le cas subalterne. Si un widget doit afficher le journal d'un autre widget, vous devez écrire un autre gestionnaire et un autre événement "onchanged" et vous finirez par avoir à étirer la définition de "déclarative" pour dire qu'il en est ainsi.

Mise à jour 2015

WPF MVVM était (r) évolutif pour l'époque. Tout comme WPF. Mais ils avaient tous les deux leurs verrues. Plain WPF en avait trop intégré (en plus il était construit sur XML), et c'était une sorte de douleur à gérer. (Vraiment, si WPF venait d'adopter une approche plus "bibliothèque" plutôt qu'une approche "framework", cela aurait pu se transformer en quelque chose de vraiment cool et tout l'univers technologique pourrait être entièrement différent maintenant). L' idée de MVVM était géniale, mais essayer d'intégrer un MVVM dans WPF était quelque peu hacky car 1) C # ne pouvait pas vraiment l'exprimer sans beaucoup de passe-partout, et 2) les reliques WinForms comme les popups modaux étaient toujours répandues idéologiquement mais ne pouvaient pas être facilement représenté dans MVVM. Ainsi, tout était nul.

Cela dit, c'est toujours la seule option réaliste sur Windows lorsque vous avez besoin de transparence ou de GPU pour les applications LOB.

React a bien sûr rendu MVVM obsolète. J'ai été déçu que VS2015 n'ait pas de compteur natif à cela. Pour l'instant, nous sommes toujours bloqués à l'aide de WPF brut (ce qui est OK, mais semble vieux (se sent vraiment aussi vieux que winforms maintenant), et n'a pas une tonne de fonctionnalités intégrées (ressemble à un projet cool mais abandonné) ou avec-MVVM, qui à ce stade se sent comme beaucoup de frais généraux pour rien, car même un bon MVVM (angulaire 1) a été exposé pour ses lacunes.

J'éviterais WPF MVVM. C'est une couche supplémentaire, et personne ne s'en soucie plus.


3
Hmm .. Je me rends compte que c'est en partie une question de religion, mais j'ai commencé avec MVVM dans WPF en utilisant Cinch en arrière. Mmm. 2010? Et je l'ai beaucoup aimé. Depuis lors, je suis passé à Caliburn.Micro et Angular et j'adore toujours - évidemment, il y a beaucoup de lacunes dans MVVM comme vous l'avez dit (sensiblement pas de manière non hacky pour faire des dialogues). MVVM peut sembler assez verbeux, mais la lisibilité globale et l'écart explicite de conception / implémentation d'interface utilisateur en valent toujours la peine pour moi.
cwap

4
"React a bien sûr rendu MVVM obsolète" - pourtant la plupart des industriels utilisent Angular.
Den

Trop jusqu'à ce que vous décidiez de déplacer votre application de bureau sur le Web et tout ce que vous avez est une tonne de code derrière tous liés aux contrôles WPF.
CAD bloke

1
Alors, React and Angular n'est-il pas un environnement JavaScript? Qu'est-ce que cela a à voir avec WPF? Ou est-ce que je manque quelque chose.
Berin Loritsch

1
@BerinLoritsch - vous ne manquez rien. Ce paragraphe n'est pas pertinent pour cette Q&R; apparemment, Dax est "passé" de WPF à la programmation Web. Pommes et oranges.
ToolmakerSteve

2

Tout compte fait, il y a une limite à ce que vous pouvez faire avec un framework MVVM.

Ils sont "terminés" car WPF n'a pas évolué depuis que Microsoft l'a publié. S'il y avait des mises à jour de la technologie, les bibliothèques auraient également besoin d'une mise à jour. Cela ne s'est pas produit.


C'est donc WPF qui est «obsolète»? Concernant votre première phrase: est-ce que dans la vraie vie, l'interface utilisateur et le code sont tout simplement trop entrelacés pour en faire une proposition réaliste, ou est-ce que quelques ajustements dans WPF auraient pu en faire le Saint Graal (ou presque?)
Benjol

3
@Benjol - Il semble que Microsoft ait abandonné WPF (ou du moins, ne met plus à jour la technologie). Mon point sur les frameworks MVVM est juste que pour leurs objectifs, il y a peu de choses à continuer et à étendre sur une plateforme périmée. Je ne sais pas pourquoi Microsoft a cessé de mettre à jour WPF, mais je doute que ce soit ce que vous suggérez - il est plus probable que Windows 8 et RT aient retiré les ressources de WPF.
Odé

18
Ce n'est pas vrai. WPF a été mis à jour plusieurs fois, plus récemment dans .NET 4.5: msdn.microsoft.com/en-us/library/bb613588.aspx
17 du 26

3
Il convient également de noter que MS prend en charge leurs technologies de développement pour toujours. MFC, publié en 1992, continue d'obtenir des corrections de bogues avec chaque version / service pack de Visual Studio.
17 du 26

5
J'irais même jusqu'à affirmer que le manque d'ajouts récents à WPF est une indication de sa maturité. De plus, comme @Oded le mentionne déjà, les applications de bureau, bien qu'elles aient encore leur valeur, sont désormais remplacées par des applications mobiles. Néanmoins, il convient de mentionner qu'une grande partie de ce que WPF a commencé (programmation déclarative de l'interface utilisateur, MVVM, DependencyProperties et Data Binding) se trouve désormais dans les technologies WinRT et Web (plusieurs cadres JS). Ce sont des valeurs fondamentales qui ont fait progresser le domaine de manière significative, et je pense qu'elles continueront de le faire pendant longtemps.
Sebastian
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.