Mapping 使用automapper的优势是什么？

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

我的第一选择是汽车制造商。但是Ive有一些问题（嵌套属性，而不是定义的无参数构造函数）。事实证明，用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的主要原因是什么（正如我在开始时所说的，我很确定我遗漏了一些重要的东西）。

因为使用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

）

您还可以在地图中定义转换（即字符串到日期时间）

Mapper.CreateMap（）.ForMember（d=>d.LastLogin，c=>c.MapFrom（u=>u.Credential.LastLogin））；

AutoMapper还支持嵌套属性

---

请在此处阅读更多信息：

AutoMapper声称的一个好处是按约定进行映射。这里有一段引用自

“这就是AutoMapper的魅力所在。当您的类对齐时 按照惯例，映射配置可以如下所示 简单“

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

如果您不能依赖约定映射，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)

var classA=Mapper.Map（classB）

---

就个人而言，我更喜欢工厂函数，即使约定映射由于其明确性、可读性和调试友好性而成为可能。在第二种情况下，如果您试图找出ClassB是如何映射到ClassA的，映射配置文件是否已加载，调用Map（）函数时为什么会出现异常，或者为什么某些属性被分配了错误的值，那么祝您好运。

有时使用映射器，很难跟踪错误。例如，如果我们将数据类中的Employee与视图模型类中的Employee错配，那么像tiny Mapper这样的映射程序不会抛出任何异常，除非我们显式地将映射程序设置为严格映射，并且在这段时间内，代码编译和运行都很完美，但我们无法跟踪错误。手动映射很少会出现这种情况，因此手动映射对象比自动映射有一些优势。

对于名称不同的属性如何？和嵌套属性？我想我应该改变惯例，但有时一边的属性是'PositionX'，另一边的属性是'X'。（仅举一个例子——anmes的属性可能非常不可预测）。那么，我不应该在我的案例中使用Automapper吗？@Katalonis-然后使用lambdas以类型安全的方式配置映射器。添加了代码示例和链接。

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