Alternativas para o AutoMapper

Quais são as diferentes estruturas alternativas disponíveis para mapeamento de object a object no .NET, além do AutoMapper

Atualmente, estamos planejando usar o AutoMapper, mas antes de finalizar esse framework, queremos entender que outros frameworks estão disponíveis.

Eu passei por um processo semelhante recentemente tentando encontrar um mapeador que realmente cobre todos os meus cenários também. Eu encontrei ValueInjecter o melhor fora do automapper, emitmapper e alguns outros no codeplex.

Eu escolho o ValueInjector porque é o mais flexível de todos. Eu tinha um requisito para mapear de entidade para viewmodel e viewmodel de volta para entidade, clonagem profunda onde você tem customer -> projects -> project, situações recursivas como customer <-> project e add / update / delete de collections de filhos.

O ValueInjector não suporta isso, mas sua estrutura é extensível o suficiente para suportar isso facilmente. Você pode ver meu ponto de extensão nesta convenção que postei em seu fórum de discussão …

http://valueinjecter.codeplex.com/discussions/274484

Existem muitas alternativas como:

  • EmitMapper
  • AutoMapper
  • ValueInjecter
  • TinyMapper
  • OoMapper
  • Mapster

Mas você também pode usar o Expressmapper . É simples e baseia-se em trees de expressão que funcionam como código escrito à mão e todos os mapeamentos são altamente otimizados em toda a solução. Além disso, você pode dar uma olhada nos fatos – benchmarks que provam que o Expressmapper é o mesmo que o código escrito à mão. Possui quase o mesmo conjunto de resources que o AutoMapper faz, outros serão suportados nos lançamentos futuros. E é extremamente fácil de usar.

Pergunta antiga, mas dê uma olhada no Mapster. É muito mais rápido que o AutoMapper (5-10X nos cenários em que o utilizei) se o desempenho é crítico e suporta a maioria dos cenários do AutoMapper. Lembre-se sempre do teste de desempenho, pois os resultados variam de acordo com o cenário.
Descartamos uma nova versão 3.x que funciona para .Net 4.0 / 4.5 / Core, suporta vários novos resources e tem grandes melhorias perf.

http://www.nuget.org/packages/Mapster/

https://github.com/eswann/Mapster

Divulgação … é um dos meus projetos que foi criado para um serviço de alta carga onde o AutoMapper começou a aparecer como um dos nossos gargalos.

Se você preferir “rolar seu próprio” … Aqui está uma alternativa rápida e simples ao AutoMapper (pouco mais fácil depurar problemas + 1 menos dependência de projeto)

public static List QuickMapper(IList data) where TResult : new() { /* NB no DEEP copy - good for simple dto to View Model transfer etc ... classs will need to have a parameterless constructor 'where TResult : new()' by default - this will ignore cases where destination object does not have one of the source object's fields- common in ViewModels ... you could use a Dictionary param to handle cases where property names don't marry up.. to use : List lst2 = Helper.QuickMapper(lst1).ToList(); */ var result = new List(data.Count); PropertyDescriptorCollection propsSource = TypeDescriptor.GetProperties(typeof(TSource)); PropertyDescriptorCollection propsResult= TypeDescriptor.GetProperties(typeof(TResult)); TResult obj; Object colVal; string sResultFieldName = ""; string sSourceFieldName = ""; foreach (TSource item in data) { obj = new TResult(); for (int iResult = 0; iResult < propsResult.Count; iResult++) { PropertyDescriptor propResult = propsResult[iResult]; sResultFieldName = propResult.Name ; for (int iSource = 0; iSource < propsResult.Count; iSource++) { PropertyDescriptor propSource = propsSource [iSource ]; sSourceFieldName = propSource.Name; if (sResultFieldName == sSourceFieldName) { try { colVal = propSource.GetValue(item) ?? null; propResult.SetValue(obj, colVal); } catch (Exception ex) { string ss = "sResultFieldName = " + sResultFieldName + "\r\nsSourceFieldName = " + sSourceFieldName + "\r\n" + ex.Message + "\r\n" + ex.StackTrace; // do what you want here ... } } } } result.Add(obj); } return result; } 

Essa é uma pergunta antiga, mas agora também há https://github.com/agileobjects/AgileMapper

Por que não usar essas ferramentas, mesmo que você precise apenas de 10% de suas funcionalidades? Essas ferramentas geralmente são bem testadas e, com a prática, gostamos de usá-las cada vez mais e, em seguida, começamos a usar suas outras possibilidades sofisticadas. Atualizar o produto é sempre arriscado, mas é para isso que servem os testes de unidade.
Além disso, descobri um novo mapeador que parece promissor: o Hmapper . Eu gosto especialmente de seu desempenho, sua capacidade de escolher quais sub objects devem ser recuperados durante o mapeamento e sua maneira fortemente tipificada de mapear tipos genéricos abertos. Este mapeador funciona bem até agora, pelo menos no meu projeto atual. Dê uma olhada aqui:

http://www.codeproject.com/Tips/1152752/H-Mapper

Por exemplo, podemos especificar sub objects usando o Linq:

 Mapper.Map(source, x=>x.Subobject) 

Dessa forma, não precisamos criar uma class DTO para informações detalhadas e outra para listar (peso leve).

Eu acho isso muito legal.