MVVM:Se un oggetto VM esporre un M oggetto direttamente, o solo attraverso getter delega a M getter?

Question

il modo migliore per spiegare con un esempio così:

questo è il modello

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

questo è il modello di visualizzazione

public class PersonVM
{    
}

la mia domanda è:
dovrebbe vm esporre la persona per il modello di dati o incapsulare le proprietà del modello, con le sue proprietà?

Answer 1

Il modello di visualizzazione deve dichiarare le sue proprietà e nascondere le specifiche del modello da vista.Questo vi dà una maggiore flessibilità, e aiuta a mantenere il modello di visualizzazione dei problemi di tipo fuoriuscita nel modello di classi.Di solito il vostro modello di visualizzazione classi di incapsulare il modello di delega.Per esempio,

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;
    }
}

Ricordate:il modello non deve sapere nulla circa il modello di visualizzazione che è il consumo, e il modello di visualizzazione non deve sapere nulla circa il punto di vista che è il consumo.La vista deve sapere nulla circa i modelli in agguato.Così, incapsulare il modello dietro le proprietà del modello di visualizzazione.

Answer 2

Non c'è un accordo generale su tale questione.Per esempio è stata una delle domande aperte su MVVM formulata dal Rione Campana qui:

È il VM permesso di offrire il V da scartare M-oggetto (ad esempio, il raw Dipendente) ?Oppure il M-oggetto proprietà (se è ancora consentito hanno proprietà!) essere esposti esclusivamente attraverso la superficie di un VM wrapper?

Il principale vantaggio di non esporre direttamente il Modello in VM sono:

• si può usare come un "convertitore on steroids", formattare i valori del modello in un modo comodo per la vista

• si può iniettare altre funzionalità relative all'interfaccia utente, come dati i messaggi di convalida, annulla e ripeti,..

I contro sono:

• sarà necessario duplicare un sacco di codice per esporre tutti i modelli di proprietà nel viewmodel.

• se si associa il controllo di visualizzazione per il viewmodel proprietà, si invierà il propertyChanged eventi dal viewmodel.Ma cosa succede se i modelli di modifica di proprietà da altre fonti diverse dal viewmodel setter?Poi deve notificare il viewmodel in modo che si concluderà con 2 OnPropertyChanged, uno nel modello e uno nel viewmodel...abbastanza complesso!

Quindi per me la risposta corretta è:dipende dalle tue esigenze.

Answer 3

Una soluzione interessante per questo è stato proposto da Robert McCarter in MSDN volume 25.

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

Egli utilizza una dinamica del Modello di Visualizzazione per fornire un livello sulla parte superiore del Modello, evitando l'inoltro di tutte le proprietà del Modello.

Se il vostro problema di spazio non richiedono alte prestazioni (dinamica comporta un calo di prestazioni), questa è un'ottima soluzione.Non è necessario conoscere il Modello, ma il Modello di Visualizzazione non sono di proprietà del proxy che vengono forniti "come sono". In qualsiasi momento è possibile aggiungere proprietà per il Modello di Visualizzazione per avvolgere le proprietà del Modello senza modificare la Vista o il Modello.Leggi l'articolo per ulteriori dettagli.

Answer 4

Con un ViewModel per qualsiasi Modello potrebbe essere peggio.Che cosa succede se si dispone di una struttura gerarchica di un Modello, o anche una semplice collezione?In questo caso dovrete scorrere tutti i modelli e costruire un ViewModel istanza per ogni modello, e anche per registrare notifica eventi di modifica o di altri eventi.IMHO, questo è completamente pazzo, e irragionevole.Come DaniCE detto, vi ritroverete con un sacco di codice e un gran mal di testa.