BestPractice: pro e contro per l'utilizzo di Automapper o LINQ (LINQ agli oggetti) per la mappatura tra un modello di dominio e un modello di presentazione

Question

Cosa ne pensi? Come mappini tra il tuo dominio e il modello di presentazione?

Answer 1

Citando parte di una risposta da Un'altra domanda automatica:

Se hai un oggetto di un tipo e si desidera popolare le proprietà di un oggetto di un altro tipo usando proprietà del primo tipo, hai due scelte:

1. Scrivi manualmente il codice per fare una tale mappatura.
2. Usa uno strumento che lo gestirà automaticamente per te.

Automapper è un esempio di 2.

Linq to Objects è un esempio di 1: sembra essere un po 'meno doloroso della scrittura del codice di mappatura oggetto a oggetto Vanila.

In termini di pro e contro:

• Automapper dovrebbe ridurre significativamente la quantità di codice che devi scrivere rispetto a LINQ in quanto utilizza le convenzioni per determinare le mappature predefinite. Usando LINQ, questi mapping predefiniti dovrebbero essere definiti.

• Usando LINQ sarà necessario definire mappature in entrambe le direzioni: Automapper dovrebbe essere in grado di risolverlo automaticamente quando vengono utilizzate le convenzioni.

• Come per tutte le DLL di terze parti, l'utilizzo di Automapper introdurrà un'altra dipendenza e richiederà una piccola curva di apprendimento (si noti che ci sarebbe una curva di apprendimento per quegli sviluppatori che non hanno usato anche LINQ).

Nota, Automapper può essere utilizzato insieme a LINQ (e LINQ2SQL) - Ancora un altro post automatico Il che spiega alcuni dei punti più fini.

Answer 2

Vi sono anche svantaggi nell'uso di un Automapper e alcuni di questi svantaggi si applicano generalmente alla programmazione per convenzione (invece di scrivere il codice esplicitamente).

Supponi di avere due classi C# -

namespace MyDtoNamespace {
    public class MyClass {
        public int Id { get; set; }
}}

namespace MyBusinessLayerNamespace {
    public class MyClass {
        public int Id { get; set; }
}}

Un Automapper mapperà bene tra queste due classi con poche configurazioni esplicite richieste.

Ma più tardi, dire che uno sviluppatore considera rinominare una di queste proprietà ID a qualcosa di diverso, ad es.

namespace MyBusinessLayerNamespace {
    public class MyClass {
        public int MyNewIdentifierVariableName { get; set; }
}}

Cerco attentamente i riferimenti in Visual Studio e considero l'impatto della ridenominazione di questi riferimenti - ma poiché mydtonamespace.myclass.id non fa esplicito riferimento a myBusinesslayernamespace.myclass.id, non lo vedo mai.

Quando Visual Studio o un altro strumento rinomina automaticamente tutti gli eventi della variabile per me nella soluzione, la mappatura automatica si interrompe.

Posso solo scoprirlo in fase di esecuzione, non esiste un problema di tempo di compilazione. Idealmente, ho test unitari per verificare le mie opere di mappatura come spero, ma anche così, il potenziale per gli errori del tempo di esecuzione durante il refactoring è un buon motivo per preferire scrivere un codice di mappatura esplicito.

Non sto certamente discutendo di evitare del tutto Automapper, solo notando che un grave problema con la programmazione per convenzione.

Answer 3

http://bhavinsurela.com/linq-and-automapper-view-model-and-data-model/ Potrebbe essere quello che stai cercando.