系列介紹
【五分鍾的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的說明頁，官方給了一個測試比較：
好吧，差距相對來說還是挺大的。但是畢竟我沒有進行確切的驗證，也不會對它進行無腦吹。詳細情況還請各位大佬自行測試。
最后，小聲說一句：點個推薦吧.....
