使用AutoMapper的原因

我想在我们公司开始使用AutoMapper。问题是我的团队成员没有看到任何好处。主要声明为什么我们需要增加抽象时，我们可以写我们的自我扩展方法，做同样的事情。使用AutoMapper的原因

那么，我可以提出什么理由呢？

2012-07-16 Night Walker

如果你想使用它，你一定有正当理由？ – podiluska 2012-07-16 18:18:33

你知道你的代码;我的建议汇集了为什么从那以后的优点和缺点。但是，您试图解决的问题是什么？你会使用依赖注入器，如Ninject或结构图吗？依赖第三方产品的开销是否会造成更多的开销，那么它的价值呢？ – anAgent 2012-07-16 18:25:12

AutoMapper应该删除您已经编写或计划编写的代码。问题有点广泛 - 你需要映射到其他对象吗？ – 2012-07-16 22:00:56

我的两个用于Automapper最大参数：

为什么写一些东西定制时，你可以依靠完善的测试，以公约为基础库为你做什么？

是的，您可以编写扩展方法来在属性之间移动数据。但是，为什么我会写出无数的映射线，仅仅用于发送跨数据类型的数据（例如）

Property1 = original.Property1; Property2 = original.Property2;

尤其当你正在做这样的事情：

Property1 = (MyEnum)Enum.Parse(typeof(MyEnum), original.Property1);

它的混乱管道代码，耗时写的，你有更好的事情要做你的时间，像建设有用的功能，到乱七八糟像这样的事情。 AutoMapper提供了免费完成第一个案例所需的所有约定，以及用于管理更复杂场景的简单模式，您可以减少形状或更改类型。

地图本身很容易测试。

再次，您可以编写自己的方法。但是，如果您正确地执行了的事情，则需要进行相应的测试，以涵盖您刚写入的自定义代码固有的所有情况。或，如果你的地图配置正确，你可以加载你的地图并询问AutoMapper。

我对Automapper警告的说法：

如果你开始有写足够的例外，你已经几乎停止依靠构成的地图，它有可能成为一个漏水的抽象。（实际上，问题可能在于你的域的设计，而AutoMapper只是第一个表示上游问题的约束）。

我不是说它是映射代码的灵丹妙药（它有它的怪癖），但花费在它上面的时间是否适合您的解决方案值得投资。

来源

2012-07-16 18:27:24

当你有很多代码不做任何事情，而是将一种类型映射到另一种类型时，AutoMapper非常有用。

问问自己这个问题。开发和维护需要多少时间：硬编码映射或设置像AutoMapper这样的框架？

以下主题可以帮助您决定自动映射框架是否适合您的方案有用：

散装。将有多少行代码专门用于映射？需要映射多少个实体？ 10？ 100？ 1000？越多的代码行数越多，您将受益于此框架
复杂性。你的地图有多复杂？这是全部基本的一对一映射吗？物体是否需要展开或展平？对于复杂场景，您很可能会受到自动映射框架的限制。
非映射。您当前的映射代码实际上是100％专用于映射对象吗？它是否像解析数据或检查商业规则一样做其他事情？映射代码的责任越多，自动映射框架的用处就越小。

来源

2012-07-16 18:23:09

事务性应用程序（针对3NF数据库的大量CrUD操作）常见的挑战是您经常必须将3NF数据库映射到对象模型（即业务对象/类），然后再次映射到表示层。数据库将数据存储为元组（行&列），数据通常以应用程序中的元组（即网格）的形式显示，但对象模型是图形 - 就像从2维（db）到3逻辑）回到2（呈现为网格）。 ORM映射器可帮助将3NF转换为对象，但要在用户的屏幕上展平对象以供表示，则需要创建特定于演示文稿的类。

Automapper是伟大的，从一种类型（业务对象）映射到场景中的另一个这样（数据传输对象），以及许多其他

来源

2012-07-16 18:32:24

使用AutoMapper的原因

回答

相关问题