【5min+】 物件映射只有AutoMapper？試試Mapster

系列介紹

【五分鐘的dotnet】是一個利用您的碎片化時間來學習和豐富.net知識的博文系列，它所包含了.net體系中可能會涉及到的方方面面，比如C#的小細節，AspnetCore，微服務中的.net知識等等，
5min+不是超過5分鐘的意思，"+"是知識的增加，so，它是讓您花費5分鐘以下的時間來提升您的知識儲備量，

正文

一談到如何在.Net中進行物件映射，可能大部分同學都會脫口而出：“使用AutoMapper！”， 是的，AutoMapper 是一個非常成熟的物件映射器，截至到寫這篇文章，您能在Nuget上下載到的AutoMapper包的版本為：v9.0.0，而對應的 Github 的 star 已經高達7K，

對了，談到AutoMapper就不得不談起它的作者（之一）：“JIMMY BOGARD”，也許您沒有聽過這個名字，但是您一定聽過他的另一個作品：MediatR（在微軟的官方示例EShop中也使用了MediatR），同時，“JIMMY BOGARD” 也是提出“將領域事件附加在聚合根”上的人，為領域驅動設計（DDD）做出了很大的貢獻，在微軟官方檔案中，您可以看到該處提及到了“JIMMY BOGARD”：

好吧，優秀的人總是優秀??，還是回到今天的正文，物件映射工具，當然，對于AutoMapper大家可能再熟悉不過了，而且它的知名度和熱度也居高不下，看一看百度搜索結果就知道了：

然后再來看一看，咱們今天要介紹的主角：Mapster， 不知道有多少同學聽過它？應該很少吧，這一點從百度搜索也可以看出來：

額………………好像差距有點大哈，而且在這些搜索結果中，有用的資訊只有那么幾條，其中能看的文章就只有一條，而且還是出自于博客園， 來自 “dudu” 大佬去年的一篇文章： EF Core 相關的千倍性能之差： AutoMapper ProjectTo VS Mapster ProjectToType， 再來看一看Github的情況，距離我寫這一篇稿子的時候，Star數只有 518 個，

一個貧訓

咱們先來回顧一下AutoMapper是怎么使用的：

現在有兩個類，一個叫做MyEntity ，一個叫做 MyDto， 在咱們書寫應用層代碼的時候，將資料轉換為Dto是很常見的一種操作，所以這也是我們需要物件映射器的原因， 假設，這兩個類的結構是醬紫的：

public class MyEntity
{
    public string Name { get; set; }

    public int No { get; set; }
}

public class MyDto
{
    public string Name { get; set; }

    public int No { get; set; }
}

很普遍，也是很常見的型別，那么如果我們要用AutoMapper來完成兩者之間的轉換呢？

var configuration = new MapperConfiguration(cfg =>
{
    cfg.CreateMap<MyEntity, MyDto>();
});

var mapper = configuration.CreateMapper();

var r = mapper.Map<MyDto>(new MyEntity() { Name = "xxx", No = 111 });

這是9.0的版本，如果您用過以前的版本可能會有點差異，比如老版本會使用Initialize方法來配置，但是思路都是一樣的，也就是說，咱們需要先配置物件與物件之間的相互關系，然后創建一個Mapper，在.NET core中咱們一般會在Configura配置好之后，將mapper注冊為一個單例，以后使用的話通過依賴注入就可以使用了，

是的，這種寫法邏輯清晰沒有一點問題，那么是什么貧訓讓我選擇放棄AutoMapper呢？ 可能您會認為是性能問題，畢竟在上面 dudu 的那篇文章的標題真的很有吸引力， 但這只是很小的一部分原因，

當我在寫一些庫的時候，我需要用到物件轉換的功能，如果自己造輪子寫一個的話也不現實（可以看看AutoMapper的原始碼，里面有多少的運算式樹寫法??），所以我嘗試引入第三方的映射工具，和大家一樣我第一反應就是AutoMapper，但是在評估的時候，我發現：一般來說，mapper物件全域只需要一個，那么這個mapper物件是在我寫的庫中使用，還是交由用戶來創建呢？ 如果在庫中創建，那么用戶必須在使用庫的時候進行配置，比如庫公開一個委托來配置：

service.AddMyLibary(config=>
{
    //config wrap automapper
})

就好比上面的寫法，可能您現在正在使用的框架中就是使用了這種方式， 當然也不是說這樣不好，但是我個人感覺很奇怪，

還有一點就是，AutoMapper必須要在進行了配置之后才能完成映射，如果我不提供配置的話，就是拋出一個例外，

所以，基于這兩點，我就想有沒有 1：簡單的映射不需要配置 2：可以在任何地方進行配置 的物件映射工具，

是的，后來我采用了Mapster，很早之前就已聽聞該工具，但是一直沒有對比著使用過它，

如果將上面AutoMapper進行映射的代碼修改一下，轉換為Mapster的版本，是這樣的：

var entity = new MyEntity() { Name = "xxx", No = 111 };
var r = entity.Adapt<MyDto>();

是的，沒有看錯，只有一句代碼，（雖然我寫了兩句??）， 當我們安裝了Mapster之后，object物件就會擁有一個 Adapt() 的擴展方法，只需要呼叫該方法就可以直接完成轉換，對于簡單的關系，我們根本都不需要進行配置，

那么對于復雜的映射呢？ Mapster 提供了一個 TypeAdapterConfig<T,T> 的靜態泛型型別來進行配置，所以我們可以在任何地方書寫配置:

TypeAdapterConfig<MyEntity, MyDto>
    .NewConfig()
    .Map(s => s.Name, d => d.Name + "_Mapster");

就像這樣，我們就完成了這組物件的復雜映射關系，（Name里面加上"_Mapster"后綴），

小試牛刀

當然，上面的例子只是一個很基礎的型別，但是我們經常會遇到型別里面擁有另外的型別，這種嵌套關系能行嗎？ 所以我們把上面的物體進行更改：

public class MyDto
{
    public string Name { get; set; }

    public int No { get; set; }

    public string UoyoName { get; set; }
}

public class MyEntity
{
    public string Name { get; set; }

    public int No { get; set; }

    public ChildEntity UoyoCSharp { get; set; }
}

public class ChildEntity
{
    public string Name { get; set; }
}

在MyEntity里面擁有一個ChildEntity的型別， “什么？您問我為什么不好好命名，比如ChildEntity就命名為Child呀，為什么要命名成讀不懂的東西，” 因為……您命名規范了，根本都不用寫配置，Mapster會自動完成映射， 所以基于這個不規則的命名，我們只需要進行下面的配置就行了：

TypeAdapterConfig<MyEntity, MyDto>
           .NewConfig()
           .Map(s => s.UoyoName, d => d.UoyoCSharp.Name);

就是這么簡單，那么其它的高級映射呢？？？ 請自行跳轉自檔案頁查詢， 因為本文不是教程篇所以就偷懶了哈，當然官方的檔案也很少，只需要半個小時，可能您就學完了??，

最后，再來說一說大家很關心的一個問題吧：它和AutoMapper比較，性能有什么差距呢？ 由于選型評估的時候我也并沒有太考慮性能這個因素，所以就沒有進行測驗，但是在Github的說明頁，官方給了一個測驗比較：

好吧，差距相對來說還是挺大的，但是畢竟我沒有進行確切的驗證，也不會對它進行無腦吹，詳細情況還請各位大佬自行測驗，

最后，小聲說一句：點個推薦吧.....

標籤：.NET Core

上一篇：abp(net core)+easyui+efcore實作倉儲管理系統——入庫管理之一(三十七)

下一篇：Asp.net Core MVC（三）UseMvc設定路由