commandes MVVM et Stateful - Bonne ou mauvaise idée?

Question

Je pensais que je poste ici dans l'espoir que peut-être quelqu'un avec une expertise MVVM serait en mesure d'offrir des avis sur si ce qui suit est une bonne idée:

J'utilise le cadre Cinch MVVM de Sacha Barber, qui comprend la classe SimpleCommand de Marlon Grech.

Une chose cette classe n'a pas d'autres alternatives que certains ont est une propriété de texte, qui peut être couramment utilisé pour lier des éléments de l'interface utilisateur au « titre » de l'opération de commande. Par conséquent, j'ai écrit une extension de cette classe, qui expose une propriété Text.

Maintenant, ce que j'ai rencontré est un cas d'utilisation où je suis à l'aide d'une commande pour activer la connectivité à un appareil. Il y a un tas de façons différentes que je pourrais mettre en œuvre ce (ne sont pas toujours là - c'est un logiciel). Un moyen serait d'exposer des objets de commande plusieurs de mes ViewModel - un pour « Disconnect » et un pour « Connect; ont le modèle de vue d'exposer une propriété qui indique l'état de connexion (IsConnected) et ont la vue lie conditionnelle soit à la commande de connexion ou de déconnexion de commande. Ma réaction à cette option si, est ... beurk!

Qu'est-ce que j'ai d'abord commencé à regarder à la place était non seulement fournir une propriété de texte, mais aussi avoir l'objet de commande mettre en œuvre INotifyPropertyChanged afin que la propriété de texte peut être modifié dynamiquement par le viewmodel à « Connect » ou « Déconnecter » selon l'état du système. Faire cela, je peux éviter d'avoir plusieurs commandes et juste exposer un seul objet de commande « ToggleConnection ».

A partir sur ce chemin bien, il me vient qu'il peut y avoir d'autres variantes de ce modèle dans lequel l'interface utilisateur doit être modifiée en fonction de l'état de la commande. Par exemple, en plus de modifier le texte de la commande selon l'état de connexion, vous pouvez avoir des endroits où une icône doit changer selon l'état de connexion. Donc, je commence à écrire une classe « Stateful » qui met en œuvre INotifyPropertyChanged, et expose deux propriétés - « Texte » et « Etat ». Je l'ai fait la classe générique afin que le type d'Etat peut être défini par l'utilisateur (je préfère généralement ne pas utiliser « objet » où évitable).

La question que j'est ... Pensez-vous que cela est une bonne ou mauvaise idée? Il peut diverger de l'intention / conception originale de commandes; D'après ce qu'ils sont les « verbes » du système que je l'ai vu peut en général être le cas cette commande des objets étaient destinés à être apatride. Avec les commandes routés, si je comprends les choses correctement que la cible de la commande serait normalement devrait avoir l'état. D'autant plus que la même commande pourrait être acheminé vers différents gestionnaires en fonction de l'endroit où les liaisons de commande sont déclarés.

Alors, je pense que au moins avec des commandes routés, l'état ne serait pas logique.

Cependant, je ne suis pas traiter avec des commandes routés - Je traite spécifiquement des commandes MVVM. Dans ce cas, il n'y a pratiquement pas de routage conditionnel des commandes -. Les vues MVVM se lient directement à un des objets de commande de ViewModel particulier et il est l'exécution et les gestionnaires de CanExecute

Dans ce cas, est-il logique?

J'ai joint une copie du code en question, dans le cas où il est d'usage / intérêt.

Merci, Phil

Answer 1

Il est vraiment à vous ce que vous pensez serait plus facile de travailler avec.

Personnellement, je ne mets pas la propriété .Text sur mes commandes simplement parce que je ne reçois pas la réutilisation de ces commandes. Il est différent avec les RoutedUICommands fournis dans le cadre (ou similaire commandes statiques sur mesure), car ils sont réutilisés partout et si la traduction de « Exit » devait changer sur cette commande, il se répercuterait dans toute l'application. Ce n'est pas le cas dans votre exemple -. Tout serait unique

Dans votre cas, ce texte de votre texte du bouton est vraiment découplée de votre commande (même si l'un affecte l'autre) et il va probablement finir par être plus facile et un peu moins de code pour les découpler, mais l'ISN différence » t va être beaucoup et il finira par être une question de goût plus que tout.

Je suis certainement avec vous sur les 2 commandes chose - Blech. La plupart des boutons délégués que vous écrivez devront réagir à l'état d'une certaine façon (le service que vous parlez est en baisse, ces données doit être peuplé de cette façon si l'utilisateur a sélectionné cela, etc), donc je ne pense pas vraiment que ce qui ne va pas avoir le délégué adapter à l'information stateful sur le ViewModel.

Quoi qu'il en soit, c'est un peu verbeux ... l'emporter est « faire tout ce qui est à l'aise ».

Answer 2

Comme la dernière affiche dit: « Quel que soit le sent à l'aise. »

Dans mon cas, je l'habitude d'utiliser quelque chose comme le DelegateCommand . Si je dois lier à certaines données, je lie à la machine virtuelle. Lorsque la commande est exécutée, son exécution dans mon VM (via le délégué fourni au DelegateCommand à init). Ensuite, le délégué peut exécuter / maynot exécuter un code réutilisable pour répondre à la commande.

On dirait que vous voulez utiliser la commande comme sa propre machine virtuelle. Je ne ai jamais pensé à faire ça avant moi, mais si elle se sent bien à vous, faites-le! :)