Quels sont les problèmes du modèle MVVM?

Question

Model-View-ViewModel est-il le meilleur modèle à utiliser dans WPF? Y a-t-il des inconvénients?

Answer 1

Voici un petit article de blog court sur le advantages and disadvantages of MVVM, directement de John Gossman lui-même.

Ses principaux inconvénients sont:

« Pour l'interface utilisateur simple, MV-VM peut être surpuissant Dans les grandes cas, il peut être difficile de concevoir le ViewModel à l'avant afin d'obtenir la bonne quantité de généralité données.. Il est déclaratif et plus difficile à déboguer que de jolies choses impératives où vous n'avez qu'à définir des points d'arrêt "

Answer 2

Oui, c'est une surpêche pour les petites applications de style international.

Answer 3

C'est un excellent motif et franchement l'un des rares modèles d'interface utilisateur sortis pour WPF. Ce que je veux dire par là, c'est que beaucoup de gens le comprennent et l'ont adopté. Il est donc relativement facile d'obtenir de l'aide et des informations à ce sujet. Le plus grand inconvénient à mon avis est qu'il augmente le nombre de classes et de composants dans votre application, car SRP l'emporte sur DRY dans ce modèle. Cela étant dit, je pense que cela en vaut la peine.

Answer 4

Pour construire notre application, nous avons commencé avec MVVM, mais après avoir eu beaucoup de problèmes, nous avons abandonné MVVM en raison des raisons suivantes qui identifieront où ne pas utiliser MVVM.

héritage Problème

Nous programmons dans .NET, et nous utilisons C# et mieux que nous voulons que l'héritage. C# ne supporte pas l'héritage de classes multiples, donc nous ne pouvons pas avoir de classes abstraites avec une logique qui sera partiellement réutilisée dans l'interface utilisateur aussi bien que dans la logique.

La plupart du temps, nous sommes confus, comment concevoir des modèles de vue afin que nous puissions hériter et contrôler la logique.

Si nous héritons de View, nous ne pouvons pas hériter ViewModel en même temps, et si nous héritons de ViewModel, nous ne pouvons pas hériter de View en même temps. Au lieu de cela, nous devons utiliser des génériques très compliqués et, avec l'aide d'outils comme Prism et Unity, nous pouvons réussir, mais cela ne vaut pas le coup.

ViewModel à ViewModel Reliure

Eh bien la plupart de la logique métier de temps isnt aussi simple que cela comme A = B + C, l'interface utilisateur et la réponse l'assurance-chômage joue un rôle énorme. Cependant, nous pouvons lier les propriétés visuelles de l'interface utilisateur aux propriétés de données de View Model, mais la question se pose de savoir comment lier réellement un modèle de vue à un autre modèle de vue et si elles passent par deux liaisons de contrôles partagés. premier.

ViewModel n'est pas simple remplacement de CodeBehind

On suppose que ViewModel est simple remplacement des fichiers behind. Mais en créant notre application, la restriction sur l'héritage nous a appris que comme WPF/Silverlight prend en charge le style d'interface utilisateur qui peut complètement séparer l'interface utilisateur avec la logique, nous sommes juste en train de séparer la logique métier dans ViewModel.

répétée du code dans ViewModel

Nous avons finalement réalisé que nous sommes en train d'écrire même modèle de code dans chaque vue et chaque ViewModel, changement qui devient une douleur énorme, et le maintien est une douleur aussi. MVVM est plus adapté au développement piloté par les tests, mais lorsqu'il s'agit d'écrire des composants extensibles, ils ne sont pas les meilleurs candidats.

---

WPF/Silverlight vous permet de séparer déjà le code et l'interface utilisateur très bien, nous en fait maintenant avoir conçu la hiérarchie des classes très simple qui effectue la logique métier et nous donner tout ce que nous avons besoin. Nous créons maintenant toutes les propriétés de commande basées sur ICommand en tant que propriétés de dépendances de nos classes, que nous lions dans UserControl ainsi que dans Control. ICommand dans CodeBehind ou Template et Styles dans ResourceDictionary nous donne presque tous les avantages de ce que nous pouvons obtenir sur MVVM.

Answer 5

Différents modèles ont des résistances différentes. Les gens ont tendance à confondre le modèle avec la mise en œuvre. La manière dont la logique métier est organisée ou consultée influe sur le motif le plus naturel pour une application donnée. Ainsi, alors que cette question pose des questions sur WPF, il peut être utile de lire trois schémas utilisés pour implémenter le même écran trois fois dans n'importe quel cadre. Vous trouverez ci-dessous un lien vers un article java qui compare MVVM («modèle de présentation») avec MVP («passive view») et une implémentation hybride MVVMP/MVC («supervising controller»). Je crois que ceci est pertinent à cette question car il y a une section qui compare les modèles.

Implementing event-driven GUI patterns using the ZK Java AJAX framework

Il souligne la faiblesse que John Gossman fait, mais va aussi comparer les forces et les faiblesses avec deux modèles alternatifs.