.net AutoMapper 的替代品
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/7052002/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Alternatives to AutoMapper
提问by subramn
What are the different alternative frameworks available for object to object mapping in .NET apart from AutoMapper
除了 AutoMapper 之外，还有哪些不同的替代框架可用于 .NET 中的对象到对象映射
Currently we're planning to use AutoMapper, but before finalizing this framework, we want to understand any other frameworks are out there.
目前我们正计划使用 AutoMapper，但在最终确定这个框架之前，我们想了解任何其他框架。
采纳答案by hazzik
EmitMapper, http://emitmapper.codeplex.com/
EmitMapper，http://emitmapper.codeplex.com/
ValueInjecter https://github.com/omuleanu/ValueInjecter
ValueInjecter https://github.com/omuleanu/ValueInjecter
BLToolkit https://github.com/igor-tkachev/bltoolkit
BLToolkit https://github.com/igor-tkachev/bltoolkit
And my homework development OoMapper https://github.com/hazzik/OoMapper
还有我的作业开发OoMapper https://github.com/hazzik/OoMapper
回答by kinstephen
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.
我最近经历了一个类似的过程，试图找到一个真正涵盖我所有场景的映射器。我发现 ValueInjecter 是 automapper、emitmapper 和 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.
我选择 ValueInjector 因为它是所有这些中最灵活的。我需要从实体映射到视图模型，并将视图模型映射回实体，深度克隆您有客户 -> 项目 -> 项目，递归情况，如客户 <-> 项目，以及添加/更新/删除子集合。
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...
开箱即用的 ValueInjector 不支持此功能，但它的框架可扩展到足以轻松支持此功能。你可以在这个约定中看到我的扩展点，我发布在他们的讨论论坛上......
回答by swannee
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.
老问题，但看看 Mapster。如果性能至关重要并且支持大多数 AutoMapper 场景，它比 AutoMapper 快很多（在我使用它的场景中是 5-10 倍）。始终记得进行性能测试，因为结果因场景而异。
我们删除了一个适用于 .Net 4.0/4.5/Core 的新 3.x 版本，支持多项新功能，并有很大的性能改进。
http://www.nuget.org/packages/Mapster/
http://www.nuget.org/packages/Mapster/
https://github.com/eswann/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.
披露...这是我为高负载服务创建的项目之一，其中 AutoMapper 开始显示为我们的瓶颈之一。
回答by Malcolm
This is an old question, but there's now also https://github.com/agileobjects/AgileMapper
这是一个老问题，但现在还有https://github.com/agileobjects/AgileMapper
回答by cSharpGuy
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)
如果您更喜欢“自己动手”……这是 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'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;
}
回答by Seblac
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 :
即使您只需要其 10% 的功能，为什么不使用此类工具。这些工具通常经过充分测试和实践，我们越来越喜欢使用它们，然后我们开始使用它们的其他奇特可能性。升级产品总是有风险的，但这就是单元测试的目的。
另外，我发现了一个看起来很有前途的新映射器：Hmapper。我特别喜欢它的性能，它能够选择在映射期间必须检索哪些子对象，以及它映射开放泛型类型的强类型方法。到目前为止，这个映射器运行良好，至少在我当前的项目中是这样。看看这里：
http://www.codeproject.com/Tips/1152752/H-Mapper
http://www.codeproject.com/Tips/1152752/H-Mapper
For example, we can specify sub objects using Linq:
例如，我们可以使用 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).
这样，我们就不必为详细信息创建一个 DTO 类，并为列表创建另一个（轻量级）。
I find this very neat.
我觉得这很整洁。
