Question

我的问题可能很愚蠢，但我很确定我会错过这个问题的一个非常重要的部分。我必须做一些对象到对象映射（在C＃项目中使用的域类和发送到flash客户端的类之间）。

我的第一选择是Automapper。但我有一些问题（嵌套属性，而不是无定义的构造函数定义）。事实证明，用automapper映射一个非常复杂的类型并不容易。

然后我的问题是：为什么不实现像：

这样的方法

  ClassA GetClassAByClassB(ClassB pObj)

   {  
     ClassA objA = new ClassA();  
     objA.Prop1 = pObj.Prop1;  
     objA.NestedType.Prop2 = pObj.Prop2;  
     //....Some more.....  
     return objA;  
   }

它具有与使用Automapper完成的映射完全相同的灵活性。您仍然必须提供源对象中的哪个属性被复制到目标对象中的哪些属性。你只需使用'='而不是lambda表达式。

但是如果你在域类中改变某些东西，你必须改变这个“映射”部分。那么说服我使用Automapper的主要原因是什么（正如我在开头说的那样，我很确定我错过了一些重要的东西）。

Answer 1

因为使用AutoMapper，不必须实现这些方法; - ）

你的方法需要写很多

classA.propA = classB.propA;
classA.propB = classB.propB;
classA.propC = classB.propC;
classA.propD = classB.propD;
classA.propE = classB.propE;

AutoMapper使用约定来自己计算。更重要的是，您不必担心pObj == null（在这种情况下，您的代码将抛出NulLReferenceException）。

您还可以在地图中定义转换（即。字符串到DateTime）。

Mapper.CreateMap<User, UserModel>().ForMember(d => d.LastLogin, c => c.MapFrom<DateTime?>(u => u.Credential.LastLogin));

AutoMapper也支持嵌套属性。

在此处阅读更多内容：AutoMapper Introduction and Samples

Answer 2

AutoMapper声称拥有的一个好处是按惯例进行映射。以下是"AutoMapper Introduction and Samples"

的引用

＆＃34;这就是AutoMapper的魅力所在。当你的班级对齐传统上，您的映射配置可以是简单＆＃34;

这项好处需要付出代价。重命名或更改目标和源属性将破坏映射并引入运行时错误而不是编译错误。

如果您不能依赖约定映射，AutoMapper将失去其优势。在这种情况下，我宁愿编写如下的工厂函数。

public static ClassA MapToClassA(this ClassB b)
{
    return new ClassA()
    {
        propA = b.propA;
        propB = b.propB;
        propC = b.propC;
    }
}

然后你将构建目标对象，如

var classA = classB.MapToClassA();

而不是

var classA = Mapper.Map<ClassB, ClassA>(classB)

就个人而言，我甚至更喜欢工厂功能，即使可以通过约定映射来实现其显式性，可读性和调试友好性。祝你在第二种情况下试图找出ClassB如何映射到ClassA，是否加载映射配置文件，或者为什么在调用Map＆lt;＆gt;（）函数时出现异常，或为什么有些已为属性分配了错误的值。

Answer 3

有时使用映射器，很难追踪错误。例如，如果我们在视图模型类中使用Emplyee在数据类中拼错Employee，那么像微小的映射器这样的映射器不会抛出任何异常，除非我们明确地将映射器设置为严格映射，并且在此期间代码编译和运行完美但是我们无法追查错误。手动映射很少发生这种情况，因此手动映射对象比自动映射有一些优势。

使用automapper有什么好处？

3 个答案: