Альтернативы AutoMapper

Каковы различные альтернативные рамки, доступные для сопоставления объектов с объектами в .NET, помимо AutoMapper

В настоящее время мы планируем использовать AutoMapper, но перед окончательной доработкой этой структуры мы хотим понять, что там есть другие фреймворки.

Ответы

Ответ 2

Недавно я прошел аналогичный процесс, пытаясь найти картографа, который действительно охватывает все мои сценарии. Я нашел ValueInjecter лучше всего из automapper, emitmapper и нескольких других на codeplex.

Я выбираю ValueInjector, потому что это самый гибкий из всех. У меня было требование сопоставить сущность с viewmodel и viewmodel обратно к сущности, глубокое клонирование, где у вас есть проект клиента → проекты → , рекурсивные ситуации, такие как проект Customer ↔ и добавление/обновление/удаление дочерних коллекций.

Из коробки ValueInjector этого не поддерживает, но она достаточно расширяема, чтобы легко ее поддерживать. Вы можете увидеть мой пункт расширения в этом соглашении, который я опубликовал на своем дискуссионном форуме...

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

Ответ 3

Существует много альтернатив:

Но вы также можете использовать Expressmapper. Он прост и основан на деревьях выражений, которые работают как написанный вручную код, и любые сопоставления сильно оптимизированы в решении. Также вы можете взглянуть на факты - benchmarks, которые доказывают Expressmapper - это то же самое, что и ручной код. Он обладает почти тем же набором функций, что и AutoMapper, другие будут поддерживаться в будущих выпусках. И он чрезвычайно прост в использовании.

Ответ 4

Старый вопрос, но взгляните на Mapster. Это намного быстрее, чем AutoMapper (5-10X в сценариях, в которых я использовал его), если производительность критическая и поддерживает большинство сценариев AutoMapper. Всегда помните о первичном тестировании, поскольку результаты варьируются в зависимости от сценария.
Мы выпустили новую версию 3.x, которая работает для .Net 4.0/4.5/Core, поддерживает несколько новых функций и имеет большие улучшенные возможности.

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

https://github.com/eswann/Mapster

Раскрытие... это один из моих проектов, который был создан для службы высокой нагрузки, где AutoMapper начал проявляться как одно из наших узких мест.

Ответ 5

Если вы предпочитаете "сворачивать свои собственные"...  Вот небольшая альтернатива AutoMapper от Quick n (бит легче отлаживает проблемы + 1 меньше зависимости от проекта)

    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 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

Почему бы не использовать такие инструменты, даже если вам нужно только 10% его функциональных возможностей. Эти инструменты, как правило, хорошо проверены и с практикой, мы любим использовать их все больше и больше, а затем мы начинаем использовать их другие возможности. Обновление продукта всегда сопряжено с риском, но для этого нужны модульные тесты.
Кроме того, я обнаружил новый сопоставитель, который кажется многообещающим: Hmapper. Мне особенно нравится его производительность, способность выбирать, какие вспомогательные объекты должны быть получены во время сопоставления, и свой строго типизированный способ сопоставления открытых типов. Этот картограф хорошо работает до сих пор, по крайней мере, в моем текущем проекте. Посмотрите здесь:

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

Например, мы можем указать вспомогательные объекты, используя Linq:

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

Таким образом, нам не нужно создавать класс DTO для получения подробной информации, а другой для перечисления (легкий вес).

Я нахожу это очень аккуратным.