MVVM est inutile ?

Question

Est orthodoxe MVVM mise en œuvre inutile? Je suis en création d'une nouvelle application et je l'ai considéré comme Windows Forms et WPF. J'ai choisi WPF parce que c'est l'avenir et offre beaucoup de flexibilité. Il y a moins de code et plus facile d'apporter des modifications importantes à votre INTERFACE utilisateur à l'aide de XAML.

Depuis le choix de WPF est évident, j'ai pensé que je peut tout aussi bien aller tout le chemin en utilisant MVVM que mon architecture de l'application, car il propose des blendability, la séparation des préoccupations et de l'unité de la testabilité. Théoriquement, il semble belle comme le saint-graal de l'INTERFACE de programmation. Cette brève aventure; cependant, s'est transformé en un véritable casse-tête. Comme prévu dans la pratique, je suis la recherche que j'ai troqué un problème à un autre. J'ai tendance à être un trouble obsessionnel-programmeur que je veux faire les choses de la bonne façon pour que je puisse obtenir les résultats de la droite et de la possibilité de devenir un meilleur développeur. Le modèle MVVM juste raté mon test sur la productivité et a tout simplement transformé en un gros dégoûtant hack!

Le cas typique est l'ajout du support pour une boîte de dialogue Modale. La manière correcte est de mettre en place une boîte de dialogue et l'attacher à un modèle de vue. L'obtention de ce travail est difficile. Afin de bénéficier de la pattern MVVM, vous devez distribuer le code à plusieurs endroits à travers les couches de votre application. Vous devez également utiliser ésotérique de la programmation des constructions comme les modèles et les lambda expressions. Des trucs qui vous fait regarder l'écran de rayer votre tête. Cela facilite la maintenance et le débogage d'un cauchemar en attente de se produire comme je l'ai découvert récemment. J'ai eu une boîte de travailler bien jusqu'à ce que j'ai eu une exception la deuxième fois que je l'invoque, en disant qu'il ne pouvait pas afficher la boîte de dialogue nouveau une fois qu'il est fermé. J'ai dû ajouter un gestionnaire d'événement pour la fin de la fonctionnalité de la fenêtre de dialogue, un autre dans le IDialogView mise en œuvre et, enfin, un autre dans le IDialogViewModel. Je pensais que MVVM allait nous sauver de ces extravagantes hackery!

Il y a plusieurs gens là-bas avec des solutions à ce problème et ils sont tous les hacks et de ne pas fournir un environnement propre, facilement réutilisables, solution élégante. La plupart des MVVM boîtes à outils brillant sur les dialogues et quand elles portent sur eux, ils sont juste des boîtes d'alerte qui ne nécessitent pas des interfaces personnalisées ou afficher les modèles.

Je vais la donner sur le MVVM modèle d'affichage, au moins orthodoxes mise en œuvre. Qu'en pensez-vous? Est-il en vaut la peine pour vous, si vous aviez des? Je suis juste un incompétent programmeur ou ne MVVM pas ce que c'est "hype" à l'être?

Answer 1

Désolé si ma réponse est devenu un peu lenghty, mais ne me blâmez pas! Votre question est très long. :P Tout d'abord, MVVM n'est pas inutile.

Le cas typique est l'ajout d' soutien pour une boîte de dialogue Modale. L' bonne façon est de mettre en place une boîte de dialogue et de l'attacher à un modèle d'affichage. Arriver ce travail est difficile.

Oui, il est vraiment.
Cependant, MVVM vous permet de séparer l'INTERFACE utilisateur de l'apparence de ses logiques. Personne ne vous oblige à l'utiliser partout, et personne ne se tenant un pistolet contre votre front pour vous faire de la création d'un ViewModel pour tout.

Voici ma solution pour cet exemple particulier:
Comment l'INTERFACE utilisateur manipule un certain d'entrée n'est rien de le ViewModel. Je voudrais ajouter du code à la Vue .xaml.cs fichier, qui instancie la boîte de dialogue et définit le même ViewModel instance (ou quelque chose d'autre, si nécessaire) comme son DataContext.

Afin de bénéficier de la pattern MVVM, vous devez distribuer le code à plusieurs endroits à travers les couches de votre application. Vous devez également utiliser ésotérique de la programmation des constructions comme les modèles et les lambda expressions.

Eh bien, vous n'avez pas à l'utiliser à plusieurs endroits. C'est comment je pourrais le résoudre:

• Ajoutez le code XAML de la Vue, et rien dans la .xaml.cs
• Écrire toutes les applications de la logique (sauf les trucs susceptibles de fonctionner avec des éléments de l'INTERFACE utilisateur) à l'intérieur d'un ViewModel
• Tout le code qui doit être fait par l'INTERFACE utilisateur, mais n'a rien à voir avec la logique d'entreprise va dans les .xaml.fichiers cs

Je pense que le but de MVVM est principalement à séparer la logique de l'application et le béton de l'INTERFACE utilisateur, permettant de légères modifications (ou le remplacement complet) de l'INTERFACE utilisateur.
J'utilise le principe suivant: le point de Vue de connaître et d'assumer tout ce qu'il veut à partir de ce Dernier, mais le ViewModel peut RIEN connaître au sujet de la Vue.
WPF fournit un bon modèle de liaisons que vous pouvez utiliser pour obtenir exactement que.

(BTW, les modèles et les expressions lambda ne sont pas ésotérique, si elle est utilisée à droite. Mais si vous ne voulez pas, ne les utilisez pas.)

Des trucs qui vous fait regarder l'écran de rayer votre tête.

Ouais, je connais ce sentiment. Exactement ce que j'ai ressenti lorsque j'ai vu la première MVVM.

J'ai eu un sujet la boîte fonctionne très bien ...

Pourquoi voudriez-vous mettre un ViewModel derrière une box? Pas de point.

La plupart des MVVM boîtes à outils brillant sur les dialogues et quand elles portent sur eux, ils sont juste des boîtes d'alerte qui ne nécessitent pas des interfaces personnalisées ou afficher les modèles.

Oui, parce que le fait même qu'un élément de l'INTERFACE utilisateur est dans la même fenêtre, ou d'une autre fenêtre, ou est orbitting Mars est à l'heure actuelle aucun des ViewModels " préoccupation.
La séparation des Préoccupations

EDIT:

Voici une très belle vidéo dont le titre est de Construire votre propre framework MVVM. Il vaut la peine de regarder.

Answer 2

L'obtention de ce travail est difficile. Dans afin de bénéficier de la MVVM motif, vous devez distribuer le code en plusieurs endroits tout au long de l' les couches de votre application. Vous aussi utiliser ésotérique de programmation des constructions comme les modèles et les lamba les expressions.

Pour une banale boîte de dialogue modale? Vous êtes certainement fait quelque chose de mal là - MVVM mise en œuvre n'a pas à être complexe.

Vu que vous êtes nouveau à la fois et WPF MVVM, il est probable que vous êtes en utilisant des solutions sous optimales partout et compliquer inutilement les choses - au moins je l'ai fait quand je suis allé WPF. Assurez-vous que le problème est vraiment MVVM et pas votre mise en œuvre avant d'abandonner.

MVVM, MVC, Affichage de documents, etc. est une vieille famille de modèles.. Il y a des inconvénients, mais aucune failles fatales du type que vous décrivez.

Answer 3

Je traite avec les boîtes de dialogue en question par la tricherie. Mon MainWindow met en œuvre un IWindowServices interface qui expose toutes les applications spécifiques des boîtes de dialogue. Mes autres Viewmodel peut ensuite importer les services de l'interface (j'utilise la MEF, mais vous peut facilement passer de l'interface par des constructeurs manuellement) et de l'utiliser pour accomplir ce qui est nécessaire. Par exemple, voici ce que l'interface ressemble à un petit utilitaire application de la mine:

//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 tous de la boîte de Dialogue des exécutions en un seul endroit et il peut être facilement supprimée pour les tests unitaires. J'ai suivi le modèle que le client de la boîte de dialogue pour créer des ViewModel, qu'ils peuvent ensuite configurer en tant que de besoin. L'appel d'Exécution des blocs et par la suite, le client peut consulter le contenu de ce Dernier pour voir la boîte de Dialogue résultats.

Un plus "pure" MVVM conception peut être important pour une grande application, où vous avez besoin de nettoyant pour l'isolation et la plus complexe de la composition, mais pour les petites et moyennes applications, je pense qu'une approche pratique, avec des services appropriés pour s'exposer nécessaire crochets, est tout à fait suffisant.

Answer 4

Je suis dans le milieu d'une assez complexe MVVM de développement à l'aide de PRISM, donc j'ai déjà eu à faire face à ce genre de préoccupations.

Mes conclusions personnelles:

MVVM vs MVC /PopUps & co

• MVVM est vraiment un super rythme et dans la plupart des cas, il remplace complètement MVC grâce à la puissance de la liaison de données dans WPF
• L'appel de votre couche de service directement à partir de la présentatrice est une application légitime dans la plupart des cas
• Même assez complexe de la Liste /Détail scénarios peuvent être mis en œuvre par pure MVVM grâce à l' {Binding Path=/} syntaxe
• Néanmoins, quand les complexes de coordination entre de multiples points de vue doivent être mis en œuvre, un contrôleur de gestion obligatoires
• Les événements peuvent être utilisés; l'ancien modèle qui implique le stockage de IView (ou AbstractObserver) des cas dans le contrôleur est obsolète
• Le contrôleur peut être injecté dans chaque Presenter par conteneur IOC
• Du prisme de IEventAggregator service est une autre solution possible si la seule utilisation de la manette est l'événement dispatching (dans ce cas, il peut complètement remplacer le contrôleur)
• Si les vues sont créées dynamiquement, c'est très bien adapté pour l'emploi contrôleur (dans le prisme le contrôleur d'obtenir injecté (CIO) d'un IRegionManager )
• Les boîtes de dialogue modales sont pour la plupart obsolètes, moderne, applications composites, à l'exception des opérations de blocage comme obligatoire confirmations; dans ces cas modal activation peut être réduit à un service appelé à l'intérieur de la manette, et mis en œuvre par une classe spécialisée, qui permet également avancée de la présentation des tests unitaires. Le contrôleur, par exemple, appeler IConfirmationService.RequestConfirmation("êtes-vous sûr") qui sera le déclencheur d'une boîte de dialogue modale de l'affichage lors de l'exécution et peut facilement être moqué pendant le test unitaire

Answer 5

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

Modèles de conception n’ont jamais voulus être suivi de façon dogmatique.