Quando si utilizza MVVM, si dovrebbero creare nuovi modelli di visualizzazione o sostituire i modelli?

Question

Quando si utilizza MVVM, si dovrebbero creare nuovi modelli di visualizzazione o sostituire i modelli?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

4

Dire che ho un visore simile a questo:

public class EmployeeViewModel
{
    private EmployeeModel _model;

    public Color BackgroundColor { get; set; }
    public Name
    {
        get { return _model.Name; }
        set
        {
            _model.Name = value;
            NotifyPropertyChanged(Name);
        }
    }
}

Quindi questo viewmodel si collega a una vista che mostra un dipendente. La cosa a cui pensare è, questo viewmodel rappresenta un dipendente, o un dipendente "visualizzabile". Viewmodel contiene alcune cose che sono specifiche della vista, ad esempio il colore di sfondo. Ci possono essere molti dipendenti, ma solo una vista dei dipendenti.

Tenendo questo a mente, quando si modifica il dipendente visualizzato, ha senso creare un nuovo EmployeeViewModel e rebindare alla vista, o semplicemente scambiare EmployeeModel. La distinzione è anche importante, o è una questione di stile?

Mi sono sempre interessato alla creazione di nuovi modelli di visualizzazione, ma sto lavorando a un progetto in cui i modellini di vista vengono creati una volta e i modelli vengono sostituiti. Non sono sicuro di come mi sento al riguardo, anche se sembra funzionare bene.

mvvm

posta ConditionRacer 01.10.2013 - 17:16

fonte

3 risposte

Leggi altre domande sui tag mvvm

Algoritmo adatto per l'unione di record da più database Test runner di test per casi di test parametrizzati

score 1 · Answer 1

Penso che la domanda ruota attorno alla possibilità di creare una nuova vista o meno.

Se hai specificato più schede, ognuna ha una vista dipendente e un modello di visualizzazione corrispondente. quando apri una nuova scheda, installi una nuova vista e un nuovo modello

Se hai una singola pagina, con i pulsanti "next / prev employee", probabilmente hai una singola vista e dovresti restare con un modello a vista singola e cambiarne le proprietà.

Se si spegne un viewmodel da una vista, si rischia di danneggiare i collegamenti tra i due. ad esempio NotifyPropertyChanged come @konrad cita

Ho visto app che creano una nuova vista ogni volta che tipo di opere hai un controller di navigazione o simili. Ma l'approccio più moderno sembra essere quello di avere un singolo albero viewmodel per l'app in cui le sue proprietà cambiano gli straordinari.

L'approccio a più viste può risentire di problemi di memoria se si perde traccia delle proprie visualizzazioni mentre si naviga. Inoltre, se si sta vincolando a un mediatore oa qualche altro oggetto di eventi globali, è possibile scoprire che si stanno attivando eventi su tutte le visualizzazioni quando in realtà si desidera attivare solo l'evento attivo.

score 0 · Answer 2

Poiché i requisiti cambiano, il tuo modello di visualizzazione dovrà adattarsi a questi requisiti.

Potrebbe essere il caso in cui desideri mostrare dipendenti in più schermi. In tal caso, utilizzerei nuovamente lo stesso modello di visualizzazione. Potresti voler rinominare questo modello di vista in DisplayEmployeeViewModel , che è perfettamente a posto.

In seguito potresti dover creare UpdateEmployeeViewModel e RemoveEmployeeViewModel .

Da una nota a margine, avere una BackgroundColor nel modello di visualizzazione potrebbe non essere una buona idea. Qualsiasi cosa abbia a che fare con la presentazione (colori, visibilità, dimensione del font, ecc.) Normalmente vive nella vista.

Per quanto riguarda lo scambio di modelli di visualizzazione, di solito cambio i modelli. Ad esempio, ho un modello di visualizzazione che elenca potenziali destinatari della posta. Quando il destinatario è selezionato, lo memorizzo nella proprietà SelectedRecipient (che è un modello). In nessun momento rinnovo il modello di visualizzazione.

score 0 · Answer 3

Suggerirei di utilizzare un BaseViewModel generico e quindi di avere ViewModels successivi ereditati da quello. Per far funzionare BaseViewModel, dovresti usare la reflection.

public class BaseViewModel<T> : IViewModel
where T: new(), class
{
    // I handle most of the logic for the ViewModels and I can process
    // any model using reflection. I don't even know property names or
    // how many properties a model has, the Reflect class I refer to helps
    // me process everything
}

public EmployeeViewModel : BaseViewModel<EmployeeModel>
{
    // I have very little to do here if anything
}

public ManagerViewModel : BaseViewModel<ManagerModel>
{
    // I have a little to do so I'll add a few new methods
    // and perhaps override my parent methods 
}

Il mio BaseViewModel, senza sapere nulla dei modelli generici, gestisce gran parte del mio lavoro pesante (cioè SelectedRecord, CurrentRecord, AddRecord, DeleteRecord, ValidRecord). E dopo aver implementato la mia classe Reflection, non devi mai sapere nulla su quali proprietà vengono utilizzate dal modello.

Nel mio modello, è MOLTO importante che i miei attributi di proprietà contengano informazioni di tipo, nomi, ecc. altrimenti la mia classe Reflect sarebbe inutile.

Rende così semplice l'aggiunta di nuovi View / ViewModels (io uso la stessa logica per le mie Views) e l'unica volta che devo aggiungere proprietà e metodi al mio modello di vista figlio è quando si comporta diversamente dal resto.

Tutto è dinamico. L'unica volta che devo fare riferimento alle proprietà nel mio modello, come nel tuo esempio, è quando sto progettando il mio modello. Una volta creato il modello, la creazione delle viste e dei modelli di visualizzazione è semplice. Modello di esempio

public EmployeeModel: BaseModel 
{ 
    [Column(Title = "#", Field = "employee_id"...)] 
    public ID{ get; set;} 
    ...
}