BestPractice: Avantages et inconvénients pour utiliser AutoMapper ou LINQ (LINQ to Objects) pour le mappage entre un modèle de domaine et un modèle de présentation

Question

Qu'en pensez-vous? Comment mappez-vous entre votre domaine et votre modèle de présentation?

Answer 1

Citant une partie d'une réponse de another Automapper question:

Si vous avez un objet d'un type et que vous voulez remplir les propriétés d'un objet d'un autre type en utilisant les propriétés du premier type, vous avez deux choix :

1. Écrivez manuellement du code pour effectuer une telle mappage .
2. Utilisez un outil qui va gérer cela automatiquement pour vous.

AutoMapper est un exemple de 2.

LINQ to Objects est un exemple de 1 - il se trouve être un peu moins douloureux que l'écriture de code de cartographie vanila objet-objet.

En ce qui concerne les avantages et les inconvénients:

• Automapper devrait réduire considérablement la quantité de code que vous devez écrire par rapport à LINQ car il utilise les conventions pour déterminer les correspondances par défaut. À l'aide de LINQ, ces mappages par défaut doivent être définis. En utilisant LINQ, il sera nécessaire de définir des mappages dans les deux sens - Automapper devrait être capable de résoudre ce problème automatiquement lorsque des conventions sont utilisées. L'utilisation de Automapper introduira une autre dépendance et nécessitera une petite courbe d'apprentissage (notez qu'il y aurait une courbe d'apprentissage pour les développeurs qui n'ont pas utilisé LINQ auparavant).

Remarque, Automapper peut être utilisé conjointement avec LINQ (et LINQ2SQL) - yet another Automapper post ce qui explique certains des points plus fins.

Answer 2

http://bhavinsurela.com/linq-and-automapper-view-model-and-data-model/ peut être ce que vous cherchez.

Answer 3

L'utilisation d'un AutoMapper présente également des inconvénients et certains de ces inconvénients s'appliquent généralement à la programmation par convention (par opposition à l'écriture de code explicitement).

Supposons que vous avez deux classes C# -

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

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

Un AutoMapper cartographierons entre ces deux classes bien avec peu de configuration explicite nécessaire. Mais plus tard, disons qu'un développeur envisage de renommer l'une de ces propriétés Id pour quelque chose de différent, par exemple.

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

Je recherche attentivement les références dans Visual Studio et considère l'impact du changement de nom sur ces références - mais parce que MyDtoNamespace.MyClass.Id ne voit pas explicitement référence MyBusinessLayerNamespace.MyClass.Id, je jamais.

Lorsque Visual Studio ou un autre outil renomme automatiquement toutes les occurrences de la variable pour moi dans la solution, le mappage AutoMapper se casse.

Je ne peux le trouver au moment de l'exécution, il n'y a pas de problème de temps de compilation. Idéalement, j'ai des tests unitaires pour vérifier mes travaux de cartographie comme je l'espère mais même ainsi, le potentiel d'erreurs d'exécution pendant la refactorisation est une bonne raison de préférer écrire du code de mappage explicite.

Je ne suis certainement pas en train d'argumenter pour éviter AutoMapper tout à fait, notant simplement qu'un problème majeur avec la programmation par convention.