我应该在哪里放置automapper代码？

Question

我在Asp.net mvc应用程序中使用Automapper。 我对automapper的用法有疑问

从大量的示例代码中，我看到人们直接使用映射器Mapper.Map<Target>(source) ，我不确定这是不是很好，在我的观点中，我想将Mapper代码包装好代理对象而不是让它直接与controller

      public BankflowData CreateBankflowAdjustments(BankflowData addedBankFlow)
      {
         var bankflow = Mapper.Map<Bankflow>(addedBankFlow);
         var newBankflow = Underlying.CreateBankFlowAdjustments(bankflow);
         return Mapper.Map<BankflowData>(newBankflow);
      }

在这个例子中，控制器对Class Bankflow ，它只知道dto BankflowData 。

我想知道这对于使用AutoMapper的应用程序是否是一个好习惯？

Answer 1

对于上一个问题，我回答了ASP.NET MVC的服务层和存储库层，应该在哪里定义接口？

在我的回答中，我解释说：

[...]我有一个这样的典型结构：

• MyProject.Core
• MyProject.Domain
• MyProject.DependencyInjection
• MyProject.Infrastructure
• MyProject.Web
• MyProject.Tests

Infrastructure层包含有关日志记录，电子邮件和数据访问的信息。 它将包含我选择的ORM 。 这不是商业逻辑的东西，也不是UI的东西。 这是我完成任务的解决方案的铁路。 它位于外层，但仅引用Core。

就我而言，基础设施层也包含Automapper。 核心定义了一个简单的接口（比如说IAutoMapper ），基础设施中存在的一个简单对象实现了它，并且可以通过依赖注入将对象传递给UI层。

然而 Jimmy Bogard（Automapper的创建者）在AutoMapper 3.0，可移植类库和PlatformNotSupportedException中表示

[...] 如果你抱怨UI项目不应该直接引用这个库，因为一些愚蠢的虚假建筑师的原因（甚至引用某种臭的圆形蔬菜），我会开车到你的房子，打你傻。 摆脱你的高马，开始富有成效。

根据我的理解，他意味着可以从UI层引用Automapper。 当他说“某种臭的圆形蔬菜”时，他当然指的是洋米建筑 ，吉米并不是它的忠实粉丝。

Answer 2

如果您的应用程序中有服务层，最好将automapper放在服务层中。 在任何情况下尝试使用扩展方法通过automapper映射您的对象，如下所示：

public static class Mapping
{
public static BankflowData CreateBankflowAdjustments(this BankflowData addedBankFlow)
      {
         var bankflow = Mapper.Map<Bankflow>(addedBankFlow);
         var newBankflow = Underlying.CreateBankFlowAdjustments(bankflow);
         return Mapper.Map<BankflowData>(newBankflow);
      }
}

它将使您的代码更具可读性，并将您的问题分开。 拿这个来获取更多信息