1

我想在我们公司开始使用 AutoMapper。我的团队成员没有看到任何好处。当我们可以编写自己的扩展方法来做同样的事情时，我们需要添加抽象的主要主张。

那么我可以提出反对的理由是什么？

4

3 回答 3

6

我对 Automapper 的两个最大论点：

  1. 当您可以依赖经过良好测试的、基于约定的库为您做事时，为什么还要编写自定义的东西呢？

是的，您可以编写扩展方法来在属性之间移动数据。但是，为什么我要编写无数的映射线只是为了跨类型传输数据，例如

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

特别是当你做这样的事情时：

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

它是乱七八糟的管道代码，编写起来很费时间，而且你有更好的时间来做，比如构建有用的功能，来处理这样的事情。AutoMapper 提供了免费完成第一个案例所需的所有约定，以及用于管理更复杂的场景的简单模式，其中您正在减少形状或更改类型。

  1. 地图本身很容易测试。

同样，您可以编写自己的方法。但是，如果您正确地做事，您将有相应的测试来涵盖您刚刚编写的自定义代码所固有的所有情况。 或者，您可以只加载您的地图并询问 AutoMapper 您的映射配置是否正确。

我对 Automapper 的警告论点：

  • 如果您开始不得不向您几乎不再依赖配置的映射编写足够多的异常，那么它可能会成为一个泄漏的抽象。（实际上，问题可能在于您的域的设计，而 AutoMapper 只是表明上游问题的第一个约束）。

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

于 2012-07-16T18:27:24.110 回答
5

当您有很多只将一种类型映射到另一种类型的代码时，AutoMapper 很有用。

问问自己这个。什么将花费更少的时间来开发和维护：硬编码映射或设置像 AutoMapper 这样的框架？

以下主题可以帮助您确定自动映射框架是否对您的场景有用：

  • 散装。有多少行代码将专门用于映射？需要映射多少个实体？10？100？1000？代码行数越多，您将从该框架中受益越多
  • 复杂性。你的映射有多复杂？都是基本的一对一映射吗？对象是否需要展开或展平？对于复杂的场景，您很可能会受到自动映射框架的限制。
  • 非映射。您当前的映射代码实际上是否 100% 专用于映射对象？它是否做其他事情，例如解析数据或检查业务规则？映射代码的职责越多，自动映射框架的用处就越少。
于 2012-07-16T18:23:09.127 回答
0

事务应用程序的一个常见挑战（针对 3NF 数据库的大量 CrUD 操作）是您经常必须将 3NF 数据库映射到对象模型（即业务对象/类），然后再映射到表示层。数据库将数据存储为元组（行和列），数据通常在应用程序中显示为元组（即网格），但对象模型是一个图形 - 这就像从 2 维（db）到 3（业务逻辑）回到 2（表示为网格）。ORM 映射器有助于将 3NF 转换为对象，但是为了在用户屏幕上表示而扁平化对象需要创建特定于表示的类。

Automapper 非常适合在这样的场景以及许多其他场景中从一种类型（业务对象）映射到另一种（数据传输对象）

于 2012-07-16T18:32:24.357 回答