Fractionnement maître-détail entre deux modèles de vue: Où mettre la logique de commande d'annulation?

Question

La section principale de la fenêtre contient un DataGrid. La section Détails affiche un formulaire permettant de modifier l'enregistrement actuellement sélectionné dans DataGrid du maître. Le SelectedItem de la grille est lié au maître vm. Lorsque cette propriété change, le maître vm crée un nouveau EditViewModel, l'exposant via une propriété. La section de détails de la vue utilise cette propriété en tant que DataContext.

Lors de l'implémentation de commandes telles que cancel, les placeriez-vous dans le modèle de vue maître ou de détails?

Le modèle de vue détaillée est responsable des interactions de l'utilisateur avec un enregistrement. On pourrait soutenir que cette responsabilité inclut la suppression. D'un autre côté, on pourrait soutenir que la vue principale est responsable des interactions de l'utilisateur avec la collection, et, puisque la suppression modifie la collection, la fonctionnalité de suppression devrait y être placée.

Merci,
Ben

Modifier: Précision - par "la mise en œuvre des commandes," je veux dire la mise en œuvre du code qui demande la couche de service pour effectuer l'action demandée.

Answer 1

Je pense que votre deuxième argument est beaucoup plus fort que le premier.

Juste un avis personnel, mais il me semble que la suppression est une préoccupation de la collection, pas un enregistrement individuel.

Answer 2

Je suis d'accord avec la réponse de Ian, mais j'ajouterais que je pense personnellement que la distinction entre la logique de l'interface utilisateur et la logique du modèle est importante. Donc, si la suppression est à ce stade principalement à partir de la liste d'interface utilisateur, alors mettre la suppression dans la collection VM a beaucoup de sens.

Dès que vous commencez à parler de travailler avec le modèle (suppression des enregistrements d'une base de données par exemple) alors les enregistrements sont probablement l'endroit approprié pour cette logique. De plus, je dirais que ce type de logique affectant le modèle devrait ensuite être déplacé dans le modèle de domaine et hors du modèle de vue, laissant les machines virtuelles uniquement responsables de la logique UI autant que possible, tandis que le modèle de domaine se développe dans une riche expression de la logique métier.

Answer 3

Chaque enregistrement ne connaît que lui-même. Il ne devrait même pas réaliser que cela fait partie d'une collection, c'est une entité en soi. La machine virtuelle maître a une collection d'enregistrements, elle devrait donc être en charge des modifications. Je suis également d'accord avec David pour séparer la logique de l'interface utilisateur et la logique métier, rester à l'écart du code spaghetti car si votre business model change, il casse le code de votre modèle de vue et conserve le principe DRY.