MVVM est-il inutile? [fermé]

La mise en œuvre orthodoxe de MVVM est-elle inutile? Je crée une nouvelle application et j'ai envisagé Windows Forms et WPF. J'ai choisi WPF car il est à l'épreuve du temps et offre beaucoup de flexibilité. Il y a moins de code et il est plus facile d'apporter des modifications importantes à votre interface utilisateur à l'aide de XAML.

Étant donné que le choix de WPF est évident, j'ai pensé que je pourrais aussi bien aller jusqu'au bout en utilisant MVVM comme architecture d'application car il offre une capacité de fusion, des problèmes de séparation et une testabilité unitaire. Théoriquement, cela semble beau comme le Saint Graal de la programmation d'interface utilisateur. Cette brève aventure; cependant, est devenu un véritable casse-tête. Comme prévu dans la pratique, je constate que j'ai échangé un problème contre un autre. J'ai tendance à être un programmeur obsessionnel dans la mesure où je veux faire les choses de la bonne manière afin d'obtenir les bons résultats et éventuellement devenir un meilleur programmeur. Le modèle MVVM vient de faire échouer mon test de productivité et vient de se transformer en un gros hack dégueulasse!

Le cas clair est l'ajout de la prise en charge d'une boîte de dialogue modale. La méthode correcte consiste à créer une boîte de dialogue et à la lier à un modèle de vue. Faire fonctionner cela est difficile. Pour bénéficier du modèle MVVM, vous devez distribuer le code à plusieurs endroits dans les couches de votre application. Vous devez également utiliser des constructions de programmation ésotériques telles que des modèles et des expressions lamba. Des trucs qui vous font regarder l'écran en vous grattant la tête. Cela fait de la maintenance et du débogage un cauchemar qui attend de se produire, comme je l'ai récemment découvert. J'avais une boîte à propos qui fonctionnait bien jusqu'à ce que j'obtienne une exception la deuxième fois que je l'ai invoquée, en disant qu'elle ne pouvait plus afficher la boîte de dialogue une fois qu'elle était fermée. J'ai dû ajouter un gestionnaire d'événements pour la fonctionnalité de fermeture à la fenêtre de dialogue, un autre dans l'implémentation IDialogView de celui-ci et enfin un autre dans IDialogViewModel. Je pensais que MVVM nous sauverait d'un piratage aussi extravagant!

Il existe plusieurs personnes avec des solutions concurrentes à ce problème et ce sont tous des hacks et ne fournissent pas une solution propre, facilement réutilisable et élégante. La plupart des boîtes à outils MVVM passent sous silence les boîtes de dialogue et lorsqu'elles y répondent, ce ne sont que des boîtes d'alerte qui ne nécessitent pas d'interfaces personnalisées ou de modèles d'affichage.

Je prévois d'abandonner le modèle de vue MVVM, du moins son implémentation orthodoxe. Qu'est-ce que tu penses? Cela a-t-il valu la peine pour vous si vous en aviez? Suis-je juste un programmeur incompétent ou MVVM n'est-il pas ce qu'il veut être?

Désolé si ma réponse est devenue un peu longue, mais ne me blâmez pas! Votre question est également longue.

En résumé, MVVM n'est pas inutile.

Le cas clair est l'ajout de la prise en charge d'une boîte de dialogue modale. La méthode correcte consiste à créer une boîte de dialogue et à la lier à un modèle de vue. Faire fonctionner cela est difficile.

Oui, c'est vraiment le cas.
Cependant, MVVM vous permet de séparer l'apparence de l'interface utilisateur de ses logiques. Personne ne vous oblige à l'utiliser partout, et personne ne tient un pistolet contre votre front pour vous faire créer un ViewModel distinct pour tout.

Voici ma solution pour cet exemple particulier: la
façon dont l'interface utilisateur gère une certaine entrée n'est pas l'affaire de ViewModel. J'ajouterais du code au fichier .xaml.cs de View, qui instancie la boîte de dialogue et définit la même instance de ViewModel (ou autre chose, si nécessaire) que son DataContext.

Pour bénéficier du modèle MVVM, vous devez distribuer le code à plusieurs endroits dans les couches de votre application. Vous devez également utiliser des constructions de programmation ésotériques telles que des modèles et des expressions lamba.

Eh bien, vous n'êtes pas obligé de l'utiliser à plusieurs endroits. Voici comment je le résoudrais:

• Ajoutez le XAML à la vue, et rien dans le .xaml.cs
• Écrivez chaque logique d'application (à l'exception de ce qui fonctionnerait directement avec les éléments de l'interface utilisateur) dans un ViewModel
• Tout le code qui devrait être fait par l'interface utilisateur mais qui n'a rien à voir avec la logique métier va dans les fichiers .xaml.cs

Je pense que le but de MVVM est avant tout de séparer la logique de l'application et l'interface utilisateur concrète, permettant ainsi des modifications faciles (ou un remplacement complet) de l'interface utilisateur.
J'utilise le principe suivant: la vue peut connaître et assumer tout ce qu'elle veut du ViewModel, mais le ViewModel ne peut rien savoir de la vue.
WPF fournit un joli modèle de liaison que vous pouvez utiliser pour y parvenir.

(BTW, les modèles et les expressions lambda ne sont pas ésotériques s'ils sont utilisés correctement. Mais si vous ne le souhaitez pas, ne les utilisez pas.)

Des trucs qui vous font regarder l'écran en vous grattant la tête.

Ouais, je connais le sentiment. Exactement ce que je ressentais quand j'ai vu MVVM pour la première fois. Mais une fois que vous aurez compris, cela ne vous fera plus de mal.

J'avais une boîte à propos qui fonctionnait bien ...

Pourquoi mettriez-vous un ViewModel derrière une boîte à propos? Cela ne sert à rien.

La plupart des boîtes à outils MVVM passent sous silence les boîtes de dialogue et lorsqu'elles y répondent, ce ne sont que des boîtes d'alerte qui ne nécessitent pas d'interfaces personnalisées ou de modèles d'affichage.

Oui, parce que le fait même qu'un élément de l'interface utilisateur soit dans la même fenêtre, ou dans une autre fenêtre, ou soit en orbite autour de Mars pour le moment n'est pas la préoccupation des ViewModels.
Séparation des préoccupations

ÉDITER:

Voici une très belle vidéo dont le titre est Construisez votre propre framework MVVM . Ça vaut le coup de regarder.

Faire fonctionner cela est difficile. Pour bénéficier du modèle MVVM, vous devez distribuer le code à plusieurs endroits dans les couches de votre application. Vous devez également utiliser des constructions de programmation ésotériques telles que des modèles et des expressions lamba.

Pour une boîte de dialogue modale courante? Vous faites certainement quelque chose de mal là-bas - l'implémentation MVVM n'a pas à être si complexe.

Étant donné que vous êtes nouveau à la fois dans MVVM et WPF, il est probable que vous utilisiez des solutions sous-optimales partout et que vous compliquiez inutilement les choses - du moins je l'ai fait lorsque je suis passé à WPF. Assurez-vous que le problème est bien MVVM et non votre implémentation avant d'abandonner.

MVVM, MVC, Document-View, etc. est une vieille famille de modèles. Il y a des inconvénients, mais pas de défauts fatals du type que vous décrivez.

Je suis au milieu d'un développement MVVM assez complexe utilisant PRISM donc j'ai déjà dû faire face à ce genre de soucis.

Mes conclusions personnelles:

MVVM vs MVC / PopUps & co

• MVVM est vraiment un excellent modèle et dans la plupart des cas, il remplace complètement MVC grâce à la puissante liaison de données dans WPF
• L'appel de votre couche de service directement depuis le présentateur est une implémentation légitime dans la plupart des cas
• Même des scénarios List / Detail assez complexes peuvent être implémentés par MVVM pur grâce à la syntaxe {Binding Path = /}
• Néanmoins, lorsqu'une coordination complexe entre plusieurs vues doit être mise en œuvre, un contrôleur
• Des événements peuvent être utilisés; l'ancien modèle qui implique le stockage des instances IView (ou AbstractObserver) dans le contrôleur est obsolète
• Le contrôleur peut être injecté dans chaque présentateur par conteneur IOC
• Le service IEventAggregator de Prism est une autre solution possible si la seule utilisation du contrôleur est la distribution d'événements (dans ce cas, il peut remplacer complètement le contrôleur)
• Si les vues doivent être créées dynamiquement, c'est un travail très bien adapté pour le contrôleur (en prisme, le contrôleur recevra un IRegionManager injecté (IOC))
• Les boîtes de dialogue modales sont pour la plupart obsolètes dans les applications composites modernes, à l'exception des opérations vraiment bloquantes comme les confirmations obligatoires; dans ces cas, l'activation modale peut être abstraite en tant que service appelé à l'intérieur du contrôleur et implémentée par une classe spécialisée, ce qui permet également des tests unitaires avancés au niveau de la présentation. Le contrôleur appellera, par exemple, IConfirmationService.RequestConfirmation («êtes-vous sûr») qui déclenchera un affichage de boîte de dialogue modale au moment de l'exécution et peut être facilement simulé pendant les tests unitaires

Je gère le problème des dialogues en trichant. My MainWindow implémente une interface IWindowServices qui expose toutes les boîtes de dialogue spécifiques à l'application. Mes autres ViewModels peuvent ensuite importer l'interface des services (j'utilise MEF, mais vous pouvez facilement passer l'interface manuellement par les constructeurs) et l'utiliser pour accomplir ce qui est nécessaire. Par exemple, voici à quoi ressemble l'interface pour une de mes petites applications utilitaires:

//Wrapper interface for dialog functionality to allow for mocking during tests
public interface IWindowServices
{
    bool ExecuteNewProject(NewProjectViewModel model);

    bool ExecuteImportSymbols(ImportSymbolsViewModel model);

    bool ExecuteOpenDialog(OpenFileDialog dialog);

    bool ExecuteSaveDialog(SaveFileDialog dialog);

    bool ExecuteWarningConfirmation(string text, string caption);

    void ExitApplication();
}

Cela met toutes les exécutions de Dialog en un seul endroit et il peut être facilement remplacé pour les tests unitaires. Je suis le modèle que le client de la boîte de dialogue doit créer pour créer le ViewModel approprié, qu'il peut ensuite configurer selon les besoins. L'appel Execute bloque et le client peut ensuite consulter le contenu du ViewModel pour voir les résultats de la boîte de dialogue.

Une conception MVVM plus `` pure '' peut être importante pour une grande application, où vous avez besoin d'une isolation plus propre et d'une composition plus complexe, mais pour les applications de petite à moyenne taille, je pense qu'une approche pratique, avec des services appropriés pour exposer les crochets requis, est tout à fait suffisante .

Les modèles de conception sont là pour vous aider, pas pour vous empêcher. Une petite partie d'être un bon développeur est de savoir quand «enfreindre les règles». Si MVVM est encombrant pour une tâche et que vous avez déterminé que la valeur future n'en vaut pas la peine, n'utilisez pas le modèle. Par exemple, comme d'autres affiches l'ont commenté, pourquoi passeriez-vous par tous les frais généraux pour mettre en œuvre une simple boîte à propos?

Les modèles de conception n'ont jamais été conçus pour être suivis de manière dogmatique.

Comme le modèle lui-même, MVVM est génial. Mais la bibliothèque de contrôle de WPF livrée avec la prise en charge de la liaison de données NET 4.0 est très limitée, elle est bien meilleure que WinForm, mais ce n'est toujours pas suffisant pour MVVM pouvant être lié, je dirais que sa puissance représente environ 30% de ce qui est nécessaire pour MVVM pouvant être lié.
MVVM pouvant être lié: c'est l'interface utilisateur où ViewModel est câblé avec View uniquement en utilisant la liaison de données.
Le modèle MVVM concerne la représentation d'objet de ViewState, il ne décrit pas comment vous maintenez la synchronisation entre View et ViewModel, dans WPF, c'est la liaison de données, mais cela peut être n'importe quoi. Et en fait, vous pouvez utiliser le modèle MVVM dans n'importe quelle boîte à outils d'interface utilisateur qui prend en charge les événements \ callbacks, vous pouvez l'utiliser dans WinAPI pur dans WinForms (je l'ai fait, et cela ne fonctionne pas beaucoup plus avec les événements \ callbacks), et vous pouvez même l'utiliser dans Text Console, comme réécrire Norton Commander de DoS à l'aide du modèle MVVM.

En bref: MVVM n'est pas inutile, c'est génial. La bibliothèque de contrôle de NET 4.0 WPF est une poubelle.

Voici la simple preuve de concept ViewModel que vous ne pouvez pas lier de données de manière pure MVVM à l'aide de WPF.

public class PersonsViewModel
{
    public IList<Person> PersonList;
    public IList<ColumnDescription> TableColumns;
    public IList<Person> SelectedPersons;
    public Person ActivePerson;
    public ColumnDescription SortedColumn;
}

Vous ne pouvez pas lier les données des en-têtes de colonne DataGrid de WPF, vous ne pouvez pas lier les données des lignes sélectionnées, etc. Vous ne pouvez qu'imaginer comment les choses s'aggravent avec des ViewModels complexes.
La réponse est donc simple à moins que vous n'écriviez une application Hello World, l'utilisation de MVVM pouvant être lié dans WPF est inutile. Vous passerez la plupart de votre temps à réfléchir sur le hack pour vous lier ViewModel. La liaison de données est agréable, mais soyez prêt à revenir aux 70% du temps de l'événement.

Non, ce n'est pas inutile, mais il est difficile de comprendre même si le motif lui-même est ridiculement simple. Il y a des tonnes de désinformation là-bas et divers groupes qui se battent pour la bonne manière. Je pense qu'avec WPF et Silverlight, vous devriez utiliser MVVM ou vous serez en train de trop coder et d'essayer de résoudre des problèmes dans un nouveau modèle, la méthodologie «ancienne» des formulaires gagnants qui ne fait que vous causer des ennuis. C'est plus le cas dans Silverlight car tout doit être asynchrone (des hacks autour de cela sont possibles, mais vous devez simplement choisir une autre plate-forme).

Je suggère de lire cet article Simplifier l'arborescence WPF en utilisant le modèle ViewModel avec soin pour voir comment MVVM peut être bien implémenté et vous permettre de changer votre mentalité de formulaires gagnants pour la nouvelle façon de penser dans MVVM. En bref, lorsque vous voulez faire quelque chose, appliquez d'abord la logique au ViewModel et non à la vue. Vous souhaitez sélectionner un élément? Changer une icône? Ne parcourez pas les éléments de l'interface utilisateur, mettez simplement à jour les propriétés des modèles et laissez la liaison de données faire le plus gros.

J'ai vu le même problème avec de nombreuses implémentations MVVM en ce qui concerne les dialogues (modaux). Quand je regarde les participants du MVVM Pattern, j'ai le sentiment qu'il manque quelque chose pour construire une application cohérente.

• View contient les contrôles GUI spécifiques et définit l'apparence de l'interface utilisateur.
• ViewModel représente l'état et le comportement de la présentation.
• Le modèle peut être un objet métier de la couche domaine ou un service qui fournit les données nécessaires.

Mais il manque:

• Qui crée les ViewModels?
• Qui est responsable du flux de travail de l'application?
• Qui sert d'intermédiaire entre les ViewModels lorsqu'ils ont besoin de communiquer entre eux?

Mon approche consiste à introduire un contrôleur (de cas d'utilisation) qui est responsable des points manquants. Comment cela fonctionne peut être vu dans les exemples d'applications WPF Application Framework (WAF) .