Mappatura di entità a macchine virtuali e ritorno: dovremmo usare l'overloading o il costruttore dell'operatore + un metodo di conversione?

Question

Mappatura di entità a macchine virtuali e ritorno: dovremmo usare l'overloading o il costruttore dell'operatore + un metodo di conversione?

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

1

Ho ottenuto la seguente entità e VM:

public class Student
{
    public int ID {get;set;}
    public string FirstName {get;set;}  
    ...
}


public class StudentVM
{
    public int ID {get;set;}
    public string FirstName {get;set;} 
    ..
}

Ora, quale dei seguenti è un modo migliore per convertire l'uno in un altro (assumendo che io modifichi solo la VM, che sembra il modo giusto per farlo):
Questo:

public static implicit operator StudentVM(Student entity)  
    {  
        return new StudentVM  
        {  
            ID=entity.ID,
            FirstName=entity.FirstName
            ...
        };
    }

.. O quello:

public StudentVM(Student entity)
    {
        ID=entity.ID;
        FirstName=entity.FirstName;
        ...
    }

La mia opinione personale è che non si può dire che un'entità "è uguale" a una VM o viceversa, quindi andrei con la seconda, ma non potrei trovare un argomento sufficientemente conciso per quello (o contro). .

programming-practices patterns-and-practices

posta Oren A 29.03.2018 - 11:24

fonte

2 risposte

Leggi altre domande sui tag programming-practices patterns-and-practices

Passaggio dei servizi di ServiceLayer al servizio WCF Esiste uno schema di progettazione con lo scopo di evitare confusione nella firma?

score 1 · Answer 1

Userei metodi di estensione o un costruttore e un metodo ToEntity () sulla VM per mappare tra VM ed Entità.

Hai ragione a cambiare solo la VM dal momento che le entità non dovrebbero preoccuparsi dei loro modelli di visualizzazione.

Il ragionamento è che la VM dovrebbe essere adattata specificamente per la Vista, in modo che possa disporre i dati in modo diverso. Lo studente potrebbe avere un riferimento a un elenco di oggetti classe completa, ma la tua macchina virtuale potrebbe avere solo bisogno di un elenco di coppie Id-Name per riempire un menu a discesa. Potrebbe aver bisogno di altri dati che non siano direttamente collegati allo Studente e potrebbe "denormalizzare" altri dati per facilitare il lavoro con esso nell'interfaccia utente. Potrebbe essere necessario fornire diverse altre entità a una VM per creare un oggetto che la tua vista può consumare facilmente.

L'overloading dell'operatore sembra un po 'imbarazzante per questo scopo.

score 0 · Answer 2

In realtà ho iniziato a utilizzare i costruttori per inizializzare i modelli di visualizzazione. Ha funzionato bene, fino a quando la gerarchia del modello di visualizzazione è diventata grande e un cambiamento di 3 o 4 livelli ha reso necessario un nuovo argomento per il modello di vista di livello superiore, che viene passato al livello più profondo.

Ho trovato che utilizzare i costruttori per mappare le entità per visualizzare i modelli funziona in molti casi, ma è problematico da mantenere per il modello di visualizzazione radice di un'intera pagina.

Esiste un modello di progettazione che si rivolge specificamente alla creazione di nuovi oggetti: il modello di fabbrica.

Ho finito con un compromesso tra una fabbrica del modello di vista e costruttori su altri modelli di vista che non rappresentavano un'intera pagina.

In sostanza, se il modello di visualizzazione è stato utilizzato per il rendering di un partial, sono stato in grado di utilizzare i costruttori con meno mal di testa di manutenzione.

Mappatura di nuovo alle entità

Dovresti cancellare la frase "mappare i modelli di vista sulle entità" e concentrarti invece sul caso d'uso.

Un caso d'uso potrebbe essere creare un nuovo studente o aggiornare uno studente esistente. Hai bisogno di classi e / o metodi aggiuntivi che si concentrino sui casi d'uso che modificano le informazioni in il sistema. Non è una cosa "mappatura".