È una buona idea aggiungere ViewModel esattamente come il modello

Ho i seguenti livelli nella mia soluzione:

1. App.Domain
2. App.Service
3. App.Core (forse si chiama questo App.DataLayer)
4. App.Web

Il modello di progettazione del software non è la mia domanda, ho il seguente 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 (ad esempio la home page) E voglio usare Id, Name & Value, quindi se voglio creare ViewModel, aggiungerò quanto segue:

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

Quindi, è una buona idea? o semplicemente usare Fooinvece di FooViewModel?

Questo può sembrare inizialmente 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 in modo indipendente. E nel caso dei modelli di vista, il codice definisce ciò che vede il "cliente", non necessariamente le entità e le operazioni di cui parla l'azienda. Quindi, stai spesso rivelando al client o all'interfaccia modelli che sono "casualmente identici". È possibile modificare le regole e i termini aziendali o la terminologia dell'utente finale indipendentemente l'uno dall'altro.

Quindi, vorrei rivolgere 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?

Quel tipo di domande in mente, se la "funzione" della tua vista è quella di rivelare rigorosamente il modello di dominio sottostante, sì, questo sembra violare la regola DRY.

_{Inoltre, tieni presente che in alcune lingue è possibile realizzare una visione che cambia in modo più naturale con le modifiche del modello con attributi e riflessioni dei membri. (O con meno ripetizioni attraverso altre imprese di intelligenza ... Ma, "intelligenza" spesso non riesce a giustificare la ripetizione che ti risparmia.)}

Avrei un modello di vista che conteneva solo una proprietà, un'istanza di Foo. In questo modo, non stai violando DRY secondo una sua 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 è necessario che la vista mostri qualcos'altro oltre al Foo, puoi semplicemente aggiungere una nuova proprietà e l'intento del tuo modello di vista sarà ancora chiaro, contiene un Foo e qualcos'altro, non avrai una miscela di proprietà di 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 mostrare. Se viene visualizzato solo un Foo, il modello di visualizzazione contiene una proprietà, un Foo.

Non sono sicuro di averlo spiegato chiaramente. In caso contrario, fammi sapere e proverò a riformularlo quando sono sveglio!

Direi che l'utilizzo FooViewModelin questo modo viola il principio DRY. Quando è necessario apportare una modifica, Fooè necessario apportare anche una modifica a FooViewModel. Penso che saresti meglio servito semplicemente usando Foocome modello per la tua vista. Vorrei prendere in considerazione un modello di visualizzazione se è necessario visualizzare le cose da Foo e altre cose. Ad esempio, supponiamo che sia necessario eseguire il rendering di alcune informazioni da Fooe anche da Bar.