AutoMapper目錄：
【AutoMapper官方文檔】DTO與Domin Model互相轉換（上）
【AutoMapper官方文檔】DTO與Domin Model互相轉換（中）
【AutoMapper官方文檔】DTO與Domin Model互相轉換（下）
未完待續。。。
本篇目錄：
Flattening-複雜到簡單
Projection-簡單到複雜
Configuration Validation-配置驗證
Lists and Array-集合和數組
Nested mappings-嵌套映射
後記
上一篇《【道德經】漫談實體、對象、DTO及AutoMapper的使用 》，因為内容寫的有點跑偏，關于AutoMapper的使用最後隻是簡單寫了下，很明顯這種簡單的使用方式不能滿足項目中複雜的需要，網上找了下AutoMapper相關文檔，但差不多都是像我一樣簡單的概述下，看來懶的不隻有我一個，哈哈。在AutoMapper 官方文檔中找到其使用的詳細說明，天書一樣的英文，然後就找相關中文文檔，最後還是沒找到，這邊沒辦法，隻能自己動手，豐衣足食了。英語牛逼的可以直接略過，檢視英文文檔，本篇也不算是翻譯，因為本人英語實在拿不出手，隻是按照示例加上自己的一些了解，做個學習筆記，不對的地方還請指正。
注：雖然上一篇寫跑偏了，但是本人真的很喜歡道德經，除了為人處世，在軟體設計這方面其實也有展現，也希望可以運用到這上面，如果你和我有一樣的想法，請在點選公告欄中的QQ連結，知音難覓啊！
Flattening 翻譯為壓扁、拉平、扁平化的意思，可以了解為使原有複雜的結構變得簡化，我們先看下領域模型和DTO代碼：
可以看到領域模型 Order 是很複雜的，但是對于業務場景中的OrderDto卻很簡單，隻有 CustomerName和Total兩個屬性，AutoMapper配置代碼：
轉換效果：
可以看到配置相當的簡單，隻要設定下Order和OrderDto之間的類型映射就可以了，我們看OrderDto中的CustomerName和Total屬性在領域模型Order中并沒有與之相對性，沒什麼可以轉換呢，感覺好神奇的樣子，其實仔細發現這些屬性的命名都有一定的規則，AutoMapper在做解析的時候會按照PascalCase（帕斯卡命名法），就是一種變量命名法，除了PascalCase還有Hungarian（匈牙利命名法）和camelCase（駱駝命名法），PascalCase就是指混合使用大小寫字母來構成變量和函數的名字，首字母要大寫，camelCase首字母小寫，我們C#命名中，一般使用的是camelCase和PascalCase，比較進階的是PascalCase。
但是為什麼AutoMapper會解析Total呢？因為在領域模型Order中有個GetTotal()方法，AutoMapper會解析“Get”之後的單詞，是以會與Total相對應，如果你把OrderDto的屬性“Total”改為“Totals”，就會發現得到的“Totals”為0。了解了AutoMapper的解析方式，我們就要注意在編寫變量、屬性或是方法名稱的時候一定要規範，這也是一種好的習慣。
Projection 翻譯為投影，Flattening是由複雜結構簡化，Projection正好相反，投影可以了解為由原始結構千變萬化，我們看下兩種轉換結構：
CalendarEvent是原始結構，CalendarEventForm是我們需要轉換後的結構，可以看到CalendarEventForm要比CalendarEvent結構複雜些，看下AutoMapper配置轉換代碼：
和Flattening不同的是，我們除了定義類型映射，還要自定義映射規則，src.EventDate.Date指向dest.EventDate，src.EventDate.Minute指向dest.EventMinute，src.EventDate.Hour指向dest.EventHour，當然我們還可以在MapFrom方法中做一些複雜的映射關系操作，MapFrom接受一個lambda表達式作為參數，可以是任何的Func表達式。Projection适用于由簡單到複雜的結構映射，一般展現在業務場景很複雜的情況下。
【更正：Projection也不一定适用在由簡單到複雜的場景，應該說使用Projection就是把AutoMapper的映射配置交給使用者來操作】
我們在使用Flattening的前提是我們需要轉換的結構命名是沒有錯誤的，但是如果我們沒有使用PascalCase命名法，或者說我們命名是錯誤的，該怎麼辦呢？比如下面代碼：
可以看到Source和Destination中的字段并不相對應，我們測試下AutoMapper映射：
AssertConfigurationIsValid方法是驗證結構映射的，如果配置不正确，會報“AutoMapperConfigurationException”異常錯誤，如何解決這個問題？你可能會說，就不能改下SomeValuefff的名稱嗎？這種方法可以，但是如果業務場景中必須要使用怎麼辦呢，看了上面Projection的映射配置，你可能想到解決方法了，如下：
名稱不對，我們可以自定義映射規則，雖然這種方式可以，但是如果業務場景中SomeValuefff并不需要，那我們改怎麼辦？既然有問題，就有解決之道，AutoMapper提供了Ignore方法，忽略不需要映射的資料結構，我們這樣配置就可以了：
有時候我們除了類型映射之外，還需要對集合類型進行映射，先看個示例：
轉換結果：
Source和Destination結構類型隻有一個Value屬性，可以看到對集合類型映射也很簡單，隻需要執行Mapper.Map泛型方法，指定需要轉換的集合類型即可，AutoMapper所支援的集合類型包括：
IEnumerable
IEnumerable<T>
ICollection
ICollection<T>
IList
IList<T>
List<T>
Arrays
我們在使用Mapper.Map執行類型映射的時候，如果來源類型支援上述集合類型，我們可以把來源類型省略掉，因為AutoMapper會自動判斷傳入對象sources的類型，如下：
還有一種情況是，在使用集合類型類型的時候，類型之間存在繼承關系，例如下面我們需要轉換的類型：
ChildSource繼承ParentSource，ChildDestination繼承ParentDestination，看下AutoMapper配置轉換代碼：
注意在Initialize初始化CreateMap進行類型映射配置的時候有個Include泛型方法，簽名為：“Include this configuration in derived types' maps”，大緻意思為包含派生類型中配置，ChildSource是ParentSource的派生類，ChildDestination是ParentDestination的派生類，cfg.CreateMap<ParentSource, ParentDestination>().Include<ChildSource, ChildDestination>(); 這段代碼隻是說明ParentSource和ChildSource之間存在的關系，我們如果把這段代碼注釋掉，就會報上面“AutoMapperMappingException”類型指定不正确的異常錯誤，如果我們把下面這段代碼：“cfg.CreateMap<ChildSource, ChildDestination>();”注釋掉，轉換結果為：
雖然沒有報“AutoMapperMappingException”異常，但是可以看出AutoMapper并沒有從ChildSource類型映射到ChildDestination類型，而是自動映射到基類型，上面那段映射代碼隻是說明派生類和基類之間存在的關系，如果派生類需要映射的話，是需要添加派生類的映射的。
我們上面說的集中映射方式都是簡單類型映射，就是類型中并不包含其他類型的映射，如何在嵌套類型中執行映射？請看下面示例：
OuterSource和OuterDest類型是我們需要映射的類型，可以看到OuterSource類型中嵌套了InnerSource類型，OuterDest類型中嵌套了InnerDest類型，AutoMapper類型映射配置代碼：
上面代碼中可以看出，對于嵌套映射，我們不需要配置什麼，隻要指定下類型映射關系和嵌套類型映射關系就可以了，也就是這段代碼：“Mapper.CreateMap<InnerSource, InnerDest>();” 其實我們在驗證類型映射的時候加上Mapper.AssertConfigurationIsValid(); 這段代碼看是不是抛出“AutoMapperMappingException”異常來判斷類型映射是否正确，因為AssertConfigurationIsValid方法沒有傳回值，隻能在catch中捕獲了，個人感覺AutoMapper可以提供個bool類型的傳回值，驗證成功則傳回true。
示例代碼下載下傳：http://pan.baidu.com/s/10A7WM
貪多嚼不爛，關于AutoMapper的使用先整理這些，後面會陸續更新，還請關注。
AutoMapper在配置類型映射最注意的一點是，類型中的名稱一定要按照PascalCase命名規則（Projection和Ignore除外）。
如果你覺得本篇文章對你有所幫助，請點選右下部“推薦”，^_^
參考資料：
https://github.com/AutoMapper/AutoMapper/wiki
http://www.cnblogs.com/dudu/archive/2011/12/16/2284828.html
http://www.cnblogs.com/ego/archive/2009/05/13/1456363.html
http://www.cnblogs.com/jiguixin/archive/2011/09/19/2181521.html
http://blog.csdn.net/yujunwu2525/article/details/7850486
作者：田園裡的蟋蟀
微信公衆号：你好架構
出處：http://www.cnblogs.com/xishuai/
公衆号會不定時的分享有關架構的方方面面，包含并不局限于：Microservices（微服務）、Service Mesh（服務網格）、DDD/TDD、Spring Cloud、Dubbo、Service Fabric、Linkerd、Envoy、Istio、Conduit、Kubernetes、Docker、MacOS/Linux、Java、.NET Core/ASP.NET Core、Redis、RabbitMQ、MongoDB、GitLab、CI/CD（持續內建/持續部署）、DevOps等等。
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接。
分享到：
QQ空間
新浪微網誌
騰訊微網誌
微信
更多