Model-View-ViewModel pattern violazione di DRY?

Question

Ho letto questo articolo oggi http://dotnetslackers.com/articles/silverlight/Silverlight-3-and-the-Data-Form-Control-part-I.aspx sull'utilizzo del pattern MVVM all'interno di un'app silverlight in cui si hanno le entità di dominio e si vedono entità spesific che sono fondamentalmente un sottoinsieme degli oggetti entità reali. Non è questa una chiara violazione del principio ASCIUTTO? e se sì, come puoi affrontarlo in un modo carino?

Answer 1

Personalmente, non mi piace quello che Dino sta facendo lì e non vorrei affrontare il problema allo stesso modo. Di solito penso a una VM come una raccolta filtrata, raggruppata e ordinata di classi di modelli. Una VM per me è una mappatura diretta alla vista, quindi potrei creare una classe NewOrderViewModel che abbia più CollectionView utilizzate dalla View (forse un CV per i clienti e un altro CV per i prodotti, probabilmente entrambi filtrati). A mio parere, la creazione di una classe VM completamente nuova per ogni classe nel modello viola DRY. Preferisco usare la derivazione o le classi parziali per aumentare il modello laddove necessario, aggiungendo proprietà specifiche (spesso calcolate). IMO .NET RIA Services è un'eccellente implementazione della combinazione di dati M e VM con il vantaggio aggiuntivo che è utilizzabile sia sul client che sul server. Dino è un ragazzo brillante, ma è un modo per chiamarlo su questo.

Answer 2

ASCIUTTO è un principio, non una regola difficile. Tu sei un umano e puoi differenziare. E.g. Se DRY fosse davvero una regola difficile, non assegneresti mai lo stesso valore a due variabili diverse. Immagino che in qualsiasi programma non banale avresti più di una variabile contenente il valore 0.

In generale: di solito DRY non si applica ai dati. Quelli che visualizzano entità specifiche probabilmente sarebbero solo oggetti di trasferimento dati senza alcuna logica degna di nota. I dati possono essere duplicati per tutti i tipi di motivi.

Answer 3

Penso che la risposta dipenda davvero da ciò che si sente dovrebbe essere nel ViewModel. Per me il ViewModel rappresenta il modello dello schermo attualmente visualizzato.

Quindi, per qualcosa come ViewCategoryViewModel, non ho una duplicazione dei campi nella categoria. Espongo un oggetto Category come proprietà sul ViewModel (sotto "SelectedCategory"), qualsiasi altro dato che la vista deve visualizzare e i comandi che lo schermo può assumere.

Ci sarà sempre qualche somiglianza tra il modello di dominio e il modello di visualizzazione, ma tutto dipende da come si sceglie di creare il ViewModel.

Answer 4

È lo stesso di DTO (Data Transfer Objects).

Il dominio per quei due tipi di oggetti è diverso, in modo da non è una violazione della DRY.

consideri il seguente esempio:

class Customer 
{ 
    public int Age 
} 

E una vista del modello corsponding:

class CustomerViewModel 
{ 
    public string Age; 

    // WPF validation code is going to be a bit more complicated: 
    public bool IsValid() 
    { 
     return string.IsNullOrEmpty(Age) == false; 
    } 
} 

domini differente - i tipi di proprietà differnet - oggetti diversi.