È una buona idea aggiungere ViewModel esattamente come Modello

16

Ho i seguenti livelli nella mia soluzione:

  1. App.Domain
  2. App.Service
  3. App.Core (forse lo chiami App.DataLayer)
  4. App.Web

Il modello di progettazione del software non è una mia domanda, ho seguito il modello in Domain

public class Foo {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Voglio usare questo modello sulla vista (per esempio la home page) E voglio usare Id, Name & Value , quindi se voglio creare ViewModel, aggiungerò seguente:

public class FooViewModel {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Quindi, è una buona idea? o semplicemente utilizzare Foo anziché FooViewModel ?

    
posta Mehdi Dehghani 09.08.2015 - 17:11
fonte

3 risposte

20

Inizialmente potrebbe sembrare una violazione della regola DRY, ma direi che "codice simile, e persino identico" non è necessariamente "ripetizione" se fa qualcosa di diverso o è in grado di cambiare indipendentemente. E nel caso dei modelli di vista, il codice sta definendo ciò che vede il "cliente", non necessariamente le entità e le operazioni di cui parla l'azienda. Quindi, stai spesso rivelando modelli al client o all'interfaccia che sono "incidentalmente identici". È possibile modificare le regole aziendali e i termini o la terminologia dell'utente finale indipendentemente l'uno dall'altro.

Quindi, rivolterei la domanda a te. Se il dominio cambia, è accettabile che i client "versione 1" continuino a utilizzare le vecchie interfacce? Rivelerai mai termini o operazioni nell'interfaccia che non fanno parte delle "regole del core business"? E viceversa?

Questo tipo di domande in mente, se la "funzione" della tua vista è rigorosamente quella di rivelare il modello di dominio sottostante, si, sembra che viola la regola DRY.

Tenete presente che l'esposizione di una vista che cambia in modo più naturale con le modifiche del modello può anche essere eseguita in alcune lingue con attributi e riflessioni dei membri. (Oppure con la ripetizione meno attraverso altre prodezze di intelligenza ... Ma "l'intelligenza" spesso non riesce a giustificare la ripetizione che ti risparmia.)

    
risposta data 09.08.2015 - 19:01
fonte
2

Avrei un modello di vista che conteneva solo una proprietà, un'istanza di Foo. In questo modo, non stai violando DRY in base a nessuna definizione, se Foo cambia, il tuo modello di vista vede automaticamente il cambiamento e ti lasci libero da un legame diretto del modello di vista con il modello.

Se domani c'è bisogno che la vista mostri qualcos'altro oltre a Foo, puoi semplicemente aggiungere una nuova proprietà, e l'intento del tuo modello di vista sarà ancora chiaro, contiene un Foo e qualcos'altro, hai vinto 'avere una miscela di proprietà da Foo con altre proprietà non correlate.

Non penserei al tuo modello di vista come a FooViewModel, lo penserei in termini di ciò che la vista dovrebbe visualizzare. Se mostra solo un Foo, il modello di vista contiene una proprietà, un Foo.

Non sono sicuro di averlo spiegato chiaramente. Se no, fammelo sapere e proverò a riformularlo quando sono sveglio!

    
risposta data 09.08.2015 - 22:29
fonte
-2

Direi che usando FooViewModel in questo modo si viola il principale di DRY. Quando devi apportare una modifica a Foo , devi anche apportare una modifica a FooViewModel . Penso che sarebbe meglio servire semplicemente usando Foo come modello per la tua vista. Considererei un modello di vista se hai bisogno di mostrare cose da Foo e altre cose. Ad esempio, supponi di dover rendere alcune informazioni da Foo e anche da Bar .

    
risposta data 09.08.2015 - 17:28
fonte

Leggi altre domande sui tag