Alternatives to AutoMapper [closed]

I went through a similar process recently trying to find a mapper that really covers all my scenarios as well. I've found ValueInjecter the best out of the automapper, emitmapper, and a few others on codeplex.

I choose ValueInjector because it's the most flexible of them all. I had a requirement to map from entity to viewmodel, and viewmodel back to entity, deep cloning where you have customer -> projects -> project, recursive situations like customer <-> project, and add/update/delete of children collections.

Out of the box ValueInjector doesn't support this, but it's framework is extensible enough to support this easily. You can see my extension point in this convention I posted on their discussion forum...

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

回答3:

Old question, but take a look at Mapster. It's a lot faster than AutoMapper (5-10X in the scenarios I've used it in) if performance is critical and supports most AutoMapper scenarios. Always remember to perf test as results vary by scenario.
We've dropped a new 3.x version that works for .Net 4.0/4.5/Core, supports several new features, and has big perf improvements.

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

https://github.com/eswann/Mapster

Disclosure...it's one of my projects that was created for a high load service where AutoMapper started showing up as one of our bottlenecks.

回答4:

This is an old question, but there's now also https://github.com/agileobjects/AgileMapper

回答5:

If you would prefer to "roll your own" ... Here is a Quick n dirty alternative to AutoMapper (bit easier to debug issues + 1 less project dependency)

    public static List<TResult> QuickMapper<TSource, TResult>(IList<TSource> data) where TResult : new()
    {
        /*


         N.B. no DEEP copy - good for simple dto to View Model transfer etc ...
         classes 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<String,string> param to handle cases  where property names don't marry up..

        to use :   List<Class2> lst2 = Helper.QuickMapper<Class1, Class2>(lst1).ToList();

        */

        var result = new List<TResult>(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;
    }

回答6:

Why not using such tools even if you just need 10% of its functionalities. Those tools are usually well tested and with practice, we like to use them more and more, and then we start using their other fancy possibilities. Upgrading the product is always risky, but that is what the unit tests are for.
Also, I discovered a new mapper that seems promising : Hmapper. I specially like its performance, its ability to choose what sub objects must be retrieved during mapping, and its strongly typed way of mapping open generic types. This mapper works well so far, at least in my current project. Have a look here :

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

For example, we can specify sub objects using Linq:

Mapper.Map<Class1, Class2>(source, x=>x.Subobject)

This way, we don't have to create a DTO class for detailed information and another one for listing (light weight).

I find this very neat.