Best Practice: Pros y contras para usar Automapper o Linq (LINQ a objetos) para mapear entre un modelo de dominio y un modelo de presentación

Question

¿Qué piensas? ¿Cómo se asigna entre su dominio y modelo de presentación?

Answer 1

Citando parte de una respuesta de Otra pregunta de Automapper:

Si tiene un objeto de un tipo y desea completar las propiedades de un objeto de otro tipo usando propiedades desde el primer tipo, tiene dos opciones:

1. Escriba el código manualmente para hacer tal mapeo.
2. Use una herramienta que manejará esto automáticamente por usted.

Automapper es un ejemplo de 2.

Linq a los objetos es un ejemplo de 1: resulta ser un poco menos doloroso que escribir el código de mapeo de objeto a objeto Vanila.

En términos de pros y contras:

• Automapper debe reducir significativamente la cantidad de código que tiene que escribir en comparación con LINQ, ya que utiliza convenciones para determinar las asignaciones predeterminadas. Usando LINQ, estas asignaciones predeterminadas tendrían que definirse.

• Usando LINQ, será necesario definir asignaciones en ambas direcciones: Automapper debe poder resolver esto automáticamente cuando se usen convenciones.

• Al igual que con todas las DLL de terceros, el uso de Automapper introducirá otra dependencia y requerirá una pequeña curva de aprendizaje (tenga en cuenta que habría una curva de aprendizaje para aquellos desarrolladores que también no han usado LINQ antes).

Nota, Automapper se puede usar junto con Linq (y Linq2SQL) - Otra publicación de Automapper más Lo que explica algunos de los puntos más finos.

Answer 2

También hay desventajas en el uso de un automático y algunas de estas desventajas se aplican generalmente a la programación por convención (en lugar de escribir código explícitamente).

Digamos que tienes dos clases de C# -

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

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

Un Automapper se asignará entre estas dos clases bien con poca configuración explícita requerida.

Pero más tarde, por ejemplo, un desarrollador considera cambiar el nombre de una de estas propiedades de identificación a algo diferente, por ejemplo,

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

Busco cuidadosamente referencias en Visual Studio y considero el impacto del cambio de nombre en estas referencias, pero debido a que mydtonamespace.myclass.id no hace referencia explícitamente a mybusinesslayernamespace.myclass.id, nunca lo veo.

Cuando Visual Studio u otra herramienta renombra automáticamente todas las ocurrencias de la variable para mí en la solución, se rompe el asignación Automapper.

Solo puedo descubrir esto en tiempo de ejecución, no hay ningún problema de tiempo de compilación. Idealmente, tengo pruebas unitarias para verificar que mi mapeo funciona como espero, pero aun así, el potencial de errores de tiempo de ejecución durante la refactorización es una buena razón para preferir escribir código de mapeo explícito.

Ciertamente no estoy argumentando para evitar el Automapper por completo, solo señalar que es un problema importante con la programación por convención.

Answer 3

http://bhavinsurela.com/linq-and-automapper-view-model-and-data-model/ Podría ser lo que estás buscando.