MVVM: un objet VM doit-exposer un objet M directement, ou seulement par getters déléguant aux apporteurs de M?

Question

la meilleure façon d'expliquer est par exemple si:

est le modèle

public class Person 
{
    public int age;
    public string name;
}

est le modèle de vue

public class PersonVM
{    
}

ma question est:
si le vm exposer la personne au modèle de données ou encapsuler les propriétés du modèle avec ses propres propriétés?

Answer 1

Le modèle de vue doit déclarer ses propres propriétés et masquer les spécificités du modèle de la vue. Cela vous donne la plus grande flexibilité et permet de garder voir les numéros de type modèle de fuite dans les classes de modèle. Habituellement, votre vue classes de modèle encapsulent le modèle par délégation. Par exemple,

class PersonModel {
    public string Name { get; set; }
}

class PersonViewModel {
    private PersonModel Person { get; set;}
    public string Name { get { return this.Person.Name; } }
    public bool IsSelected { get; set; } // example of state exposed by view model

    public PersonViewModel(PersonModel person) {
        this.Person = person;
    }
}

Souvenez-vous: le modèle ne doit pas savoir quoi que ce soit sur le modèle de vue qui consomme, et le modèle de vue ne doit pas savoir quoi que ce soit au sujet de la vue qui est de la consommer. La vue ne devrait rien savoir sur les modèles tapi dans l'arrière-plan. Ainsi, le modèle derrière encapsuler propriétés dans le modèle de vue.

Answer 2

Il n'y a pas d'accord général sur cette question. Par exemple, il a été l'une des questions ouvertes sur MVVM formulées par Ward de Bell ici :

  

est la machine virtuelle permet d'offrir un V   non emballé M-objet (par exemple, le brut   Employé)? Ou doit-M objet de   propriétés (si elle est même autorisé à   ont des propriétés!) être exposés   exclusivement à travers la surface d'un   wrapper VM?

Les principaux avantages de ne pas exposer directement le modèle dans la machine virtuelle sont:

• vous pouvez l'utiliser comme un « convertisseur sur les stéroïdes », formating les valeurs du modèle d'une manière pratique pour la vue

• vous pouvez injecter d'autres fonctionalité liés à l'interface utilisateur, comme messages de validation de données , redo annuler, ..

Les inconvénients sont:

• vous devrez dupliquer beaucoup de code pour exposer toutes les propriétés des modèles dans le viewmodel.

• si vous liez le contrôle en vue de la propriété viewmodels, vous enverrez les événements PropertyChanged du viewmodel. Mais ce qui se passe si les modèles de changement propriété d'une autre source différente de la setter viewmodel? Ensuite, il doit en aviser le viewmodel si vous vous avec 2 OnPropertyChanged, l'un dans le modèle et un dans le viewmodel ... assez complexe!

Donc pour moi la bonne réponse est:. Cela dépend de vos besoins

Answer 3

Une solution intéressante à cela a été proposé par Robert McCarter dans le volume MSDN 25.

http://msdn.microsoft.com/en-us/magazine/ ff798279.aspx

Il utilise une vue dynamique modèle pour fournir une couche sur le dessus du modèle tout en évitant mandatement toutes les propriétés du modèle.

Si votre problème d'espace ne nécessite pas de hautes performances (dynamique encourent un coup de performance), c'est une excellente solution. Le point de vue n'a pas besoin de savoir quoi que ce soit sur le modèle, mais la vue modèle n'a pas à propriétés proxy qui sont fournis « tels quels ». A tout moment les propriétés peuvent être ajoutées à la vue Modèle pour envelopper les propriétés du modèle sans modifier la vue ou le modèle. Lire l'article pour plus de détails.

Answer 4

Avoir un ViewModel pour tout modèle pourrait être pire que cela. Que faire si vous avez une structure hiérarchique d'un modèle, ou même une simple collection? Dans ce cas, vous devrez parcourir tous les modèles et construire une instance ViewModel par modèle, et aussi d'enregistrer les événements notify-changement ou d'autres événements. À mon humble avis, cela est complètement fou et déraisonnable. Comme l'a dit Danice, vous vous retrouverez avec beaucoup de code et un gros mal de tête.