Bestpractice: prós e contras para usar o AutomApper ou LINQ (LINQ para objetos) para mapeamento entre um modelo de domínio e um modelo de apresentação

Question

O que você acha? Como você mapeia entre seu domínio e modelo de apresentação?

Answer 1

Citando parte de uma resposta de Outra pergunta do AutomApper:

Se você tem um objeto de um tipo e deseja preencher as propriedades de um objeto de outro tipo usando propriedades do primeiro tipo, você tem duas opções:

1. Escreva manualmente o código para fazer esse mapeamento.
2. Use uma ferramenta que lidará automaticamente para você.

O AutomApper é um exemplo de 2.

O Linq to Objects é um exemplo de 1-só é um pouco menos doloroso do que escrever o código de mapeamento Vanila Object to-Object.

Em termos de prós e contras:

• O AutomApper deve reduzir significativamente a quantidade de código que você deve escrever em comparação com o LINQ, pois usa convenções para determinar os mapeamentos padrão. Usando o LINQ, esses mapeamentos padrão teriam que ser definidos.

• Usando o LINQ, será necessário definir mapeamentos em ambas as direções - o AutomApper deve poder resolver isso automaticamente quando as convenções forem usadas.

• Como em todas as DLLs de terceiros, o uso do AutomApper introduzirá outra dependência e exigirá uma pequena curva de aprendizado (observe que haveria uma curva de aprendizado para os desenvolvedores que também não usaram o LINQ antes).

Nota, o AutomApper pode ser usado em conjunto com o LINQ (e Linq2SQL) - Mais uma postagem do AutomApper o que explica alguns dos pontos mais refinados.

Answer 2

Também existem desvantagens no uso de um AutomApper e algumas dessas desvantagens se aplicam geralmente à programação por convenção (em vez de escrever o código explicitamente).

Diga que você tem duas aulas C# -

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

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

Um AutomApper mapeará entre essas duas classes com pouca configuração explícita necessária.

Mais tarde, porém, digamos que um desenvolvedor considere renomear uma dessas propriedades de identificação para algo diferente, por exemplo,

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

Eu procuro cuidadosamente por referências no Visual Studio e considero o impacto da renomeação dessas referências - mas porque o mydtonamespace.myclass.id não faz referência explicitamente a mybusinesslayernamespace.myclass.id, nunca o vejo.

Quando o Visual Studio ou outra ferramenta renomeia automaticamente todas as ocorrências da variável para mim na solução, o AutomApper mapeando quebras.

Só posso descobrir isso no tempo de execução, não há problema de tempo de compilação. Idealmente, tenho testes de unidade para verificar meu mapeamento, como espero, mas mesmo assim, o potencial de erros de tempo de execução durante a refatoração é um bom motivo para preferir escrever código de mapeamento explícito.

Certamente não estou argumentando para evitar completamente o Automapper, apenas observando que um grande problema com a programação por convenção.

Answer 3

http://bhavinsurela.com/linq-and-automapper-view-model-and-data-model/ Pode ser o que você está procurando.