去年曾經向各位介紹如何使用 LINQPad 快速產生相對映 SQL Command 查詢結果的類別，連結如下：
http://kevintsengtw.blogspot.tw/2015/10/dapper-linqpad-sql-command.html
對於使用 Dapper 做為資料讀取異動操作的開發者來說，應該是相當方便，目前我目前的工作環境裡，幾乎新開發的專案裡都已經使用 Dapper 以及快速產生相對映類別的方法。
另外就是有關於單元測試的部分，公司裡的各個開發團隊也陸續在專案裡導入單元測試，不管是應用展示層或是商業邏輯層都會嘗試去做單元測試，唯獨資料存取層的單元測試卻是比較少人會去做，當然資料存取層的單元測試是否要做，這並沒有一定的標準答案，而我所認知的是，只要程式是開發人員去編寫出來的就有必要做測試，但是資料存取層的測試所牽涉到的技術會比較多一些，也關係到資料存取所使用的方式，都是影響要不要做測試的因素。
而這一篇所要介紹的內容也就是在做資料存取層的單元測試時的其中一個環節。
前面幾篇文章都是一直在介紹 Dapper 的相關功能，不過都是屬於基本的應用，Dapper 也是有很多的進階使用方式，不過這邊就不繼續介紹而是讓各位去發掘與找出適合自己專案的做法，這一篇文章基本上跟 Dapper 沒有直接關係，因為產出對映查詢結果類別的這一個功能並非使用 Dapper，因為 Dapper 只是一個優化 ADO.NET 操作 T-SQL 以及對映類別的一個 Utilities，本身並沒有提供什麼神奇的功能，但是很多人從傳統 ADO.NET 操作並且使用 DataSet DataTable 弱型別的方式改為使用 Dapper 以及強型別的時候，普遍都會遇到一個最大的困難…… 「建立類別」。
這一篇文章的內容算是拾人牙慧，只是跟大家說別人有提供了方法可以讓我們能夠快速地從 SQL Command 去建立相對映的類別，雖然不是我寫的方法，但還是希望大家可以及早地從弱型別的地獄中快點逃離出來（雖然這麼說是有貶抑弱型別的意味，但看了這麼多年以及很多人所開發的專案，發現到很多問題都是從濫用 DataSet DataTable 等弱型別開始）。
使用 CsvHelper 的讀寫操作在前兩篇都已經有說明了，如果需要更進階的操作說明，可以直接參考 CsvHelper 的文件檔或是直接到 Github Repository 裡面的單元測試專案裡去看，而這一篇則是再補上一些在處理 CSV 檔案讀寫時的方法操作說明。
使用 CsvHelper - Part.1 資料寫入
使用 CsvHelper - Part.2 資料讀取
上一篇介紹了如何使用 CsvHelper 將資料輸出到 CSV 檔案，既然有輸出，相對就會有讀取的需要，所以這一篇就說明如何使用 CsvHelper 將 CSV 檔案裡的資料給讀取出來。
最近有個要將資料寫入 CSV 檔案的需求，一般大家對於 CSV 檔案的處理應該就如同處理文字檔的方式一樣，但因為我需要寫入的資料並不是固定的一個類別，而是會因為不同資料處理而會需要將不同類別的資料給寫入到 CSV 檔案裡，像遇到這種需要處理不同類別的狀況時，我比較常看到的就是針對一個類別然後去寫一個相對應的方法去做處理，另外還有看到的就是建立一個很大的方法，在這個方法裡用 switch case 方式先判別進來的資料是哪一種類型，然後再去個別的做處理，其實第二種方法跟第一種方法並沒有什麼分別，不同的地方只在於第一種方法是分散的，而第二種方法是將第一種方法裡分散四處的 method 給集中在一起而已。
我是一個很懶惰的人，對於這樣的需求，我不太喜歡花太多時間去想應該怎麼解決，或是自己動手去寫程式來處理，因為我知道對於處理 CSV 資料的讀寫，一定早就有人去寫好程式，而我所採用的處理 CSV 資料讀寫工具程式就是「CsvHelper」，老早就已經注意到，只是一直沒有專案能夠用上，剛好現在的專案可以讓我實際的應用，所以就在這邊做個簡單的介紹。
前面幾篇有講到西元年轉換民國年格式字串的內容，因為我是使用 TaiwanCalendar 類別之後， 然後年份的地分直接使用 taiwanCalendar.GetYear(source) 的方式來取得，但這個地方的處理不能直接使用 source.Year - 1911 嗎？
當然你可以這麼用，而且你要清楚知道這麼用的原因，而且要確保開發團隊的成員都知道這麼做的原因，甚至於你也要確保日後接手維護的開發人員也能夠知道，不然哪天出現一個天真純潔的開發人員看到這樣的程式，就會想說為何不用 source.AddYears(-1911) 來處理呢？程式不是更加簡潔、漂亮嗎？當出現這樣的狀況時，抓蟲、找問題又將會是一場令人惱怒的過程。
在台灣使用 .NET Framework C# 的開發人員對於這樣的轉換都應該內化為基本操作知識，也就是當有西元年轉為民國年的需求時，都要能夠馬上使用正確的方式來取得正確的資料內容，而並不是直接使用減去 1911 的方式來結案。
為什麼呢？
你使用任何一個閏年（台灣每次總統大選年、夏季奧運舉辦年、美國總統就職的那一年）去取得 2 月 29 日，然後直接用減去 1911 的方式來看結果，我想大部分的人就會知道答案了，如果你還是不懂，那就繼續看下去。
AutoMapper 對於有實作 IQueryable<T>（例如：使用 Entity Framework, NHiberbate 等）提供了另一個資料對映的方式，可以簡化資料對映的處理。
在上一篇文章「AutoMapper - Complex Type 的資料對映」裡說明了幾種對於 Complex Type 的資料對映方式，其實還有一種方式，AutoMapper 提供了一種「Custom value resolvers（自定義值解析器）」，讓我們可以另外定義資料解析以及轉換的方式，以彈性的方式進行目標類別物件的資料對映。
這篇文章將會以前篇文章的程式來做示範。
有時候建立類別並不會單純只使用一般的資料型別來定義屬性，很多時候也是會使用我們所定義的類別作為屬性的型別，最常見的就是在 ASP.NET MVC 所使用的 ViewModel 或是 DTO 資料傳輸物件類別，要如何處理這樣的資料對映呢？
接下來將會說明不同的資料對映使用方式。
這個題目其實蠻簡單的，有時後會需要將接收到的 QueryString 再加以處理，因為 QueryString 是屬於 NameValue 的結構，如下：
ID=12345678&FirstName=OOO&LastName=xxx如果 QueryString 的內容不是又臭又長的時候，可以直接使用 HttpUtility.ParseQueryString() 方法將 QueryString 轉換為 NameValueCollection，然後可以依據 Name 來取得 Value 的內容。
但需要將 QueryString 轉成指定型別的物件呢？好像沒有內建的方法是可以直接將 NameValueCollection 轉成物件，不過還是有方法可以做這樣的處理，只是需要多做幾次簡單的轉換處理而已。
上一篇「使用 AutoMapper 處理類別之間的對映轉換」像各位說明在系統中可以使用 AutoMapper 來處理類別之間的轉換，例如：Entity Model to DTO, DTO to Entity Model, Entity Model to ViewModel, ViewModel to Entity Model … etc.
應該有人會覺得每次要使用 AutoMapper 處理類別轉換的時候總是要先建立類別轉換的設定，然後再執行轉換，如果同樣的類別轉換設定會在不同地方出現時，豈不是每次都要重複建立嗎？比如說以下的這個設定：
這一篇就跟大家說明如何處理 AutoMapper 的設定。
以往使用傳統 ADO.NET 方式對資料庫存取資料時都會碰上資料對映的處理，這是指已經在系統中使用物件導向開發的情況（而沒有使用物件導向的程式中大多是不會遇到這個問題），當從資料庫取得資料後為了要對映到我們所定義的類別，如果沒有使用輔助方法的話，很多人都是乖乖地在程式中去將一筆筆的資料做迴圈處理，然後再一個欄位對映到類別指定的屬性，因為這樣一筆一筆地對映實在太花時間了，所以就有很多輔助方法的產生，有些人會自己寫，而我則是使用 Enterprise Library Data Access Application Block 裡的 RowMapper 方法，在我之前的文章也曾經介紹過，如下：
「簡述 Oracle + Enterprise Library 5.0 Data Access Application Block 的操作」
「Entity Framework 與 Stored Procedure - 回傳多種資料集」
而 Microsoft MVP - 91 也曾經發表了他所設計的 RowMapper 模組「[.NET]RowMapper模組」「[.NET]透過 T4 產生對應 DB table 的 entity」，都是用在資料與類別對映的處理上。
而到了完全以物件導向開發的時候，尤其是已經在專案中使用 ORM Solution，如：ADO.NET Entity Framework or nHibernate 等，大多都是資料庫的 Table 對映到專案的類別，這一段的對映處理不必由我們動手做，在大部分的專案開發上都是一個類別用到底，但有些專案開發時會因為需求而產生了 一些類別，這些類別的屬性可能來自不同的原生類別，而在 ASP.NET MVC 裡最常碰到的就是 ViewModel 類別，而處理這些類別的對映，又遇到上面我所描述過的狀況，如果沒有使用輔助方法的話，又需要一筆一筆資料去做對映，但只少比一般 ADO.NET 的對映處理已經是方便許多，而 AutoMapper 就是可以幫我們簡化這種類別之間的對映轉換處理，讓程式在處理時可以更加簡易也可以更加優雅些，也可以省下更多的開發時間；接著就來讓我簡單介紹怎麼使用 AutoMapper。
在「ASP.NET MVC 資料分頁 MVCPaging 2.0 應用 Part.4：分頁進階處理」的文章當中，我把資料的欄位排序改以表格的標題欄位來操作，因為那一篇文章只是做個範例，所以就直接以 Entity 的 Property 名稱作為標題來顯示，而實際的應用狀況下，我們的 Entity Property 名稱並不會直接顯示在頁面上，而是會另外以 DisplayAttribute 來標註要顯示的名稱，然後頁面上就顯示這個 Display Name。
不過有個朋友就在該文章回應並且提供一個方法，讓表格的標題改用 Display Name 來顯示，看了這位朋友所提供的方法後，覺得這個方法是可以達到需求，但還可以在做些修改，讓修改後的方法不只有提供給 View 做顯示之用，在其他有需要的地方，只要呼叫這個修改後的方法就可以輕易取得 Entity 類別中某個 Property 上的 Display Name。
當專案使用 Entity Framework 4 的時候，使用我之前介紹過的方法都是可行的，例如：
取得 Entity Framework 中 Entity 的主鍵成員名稱（KeyMember）
取得 Entity Framework 中 Entity 對應 Table 的原生 Column Name
而當專案使用 Entity Framework 5 之後就會發現到這些方法全都不行了，既然都不能用了就想辦法解決，只是這次就真的像破頭了，像我都是使用 Database First 的方式來建立 Entity Model，所以當我一開始想要用之前的方法在加上反射的方式來試著找出我想要的資料時，發現到 EF5 所建立的 EDMX 已經是大大不同了，這篇文章就說明如何在使用 EF5 的情況下找出 Entity 的 Property Names 與 KeyMembers。
這篇的文章標題蠻長的，其實這與以前的兩篇文章是有關連的，
觀察 Entity Framework 轉換所產出的 SQL Command
動態取得 Entity Framework 中 Entity 對應的 TableName
這兩篇文章都是以使用 ADO.NET Entity Framework 4.0 以及 .NET 4.0 為背景，不過換成 ADO.NET Entity Framework 5.0 與 .NET 4.5 的使用情境下就會有所不同了，那兩篇文章內所說的方法就行不通，所以就必須要換另外的方式來完成需求。
其實這一篇原本要寫在「Dynamic LINQ + Entity Framework - Part.3：ASP.NET MVC 應用」的最後面，
但是那一篇文章已經是長長一大篇了，為了避免大家看到睡著或是沒耐心看完全部就離開，
所以就把後面要接續寫的內容給放到這一篇文章裡，
這一篇的進階應用會多加一些功能以及調整一些顯示的方式，都可以應用在實務專案裡。
我都快要忘記有開「Dynamic LINQ + Entity Framework」這個系列的主題，
離這個主題的上一篇文章發佈日期都快要超過三個月了，所以趕快來補一下這個主題的進度，
前兩篇是說基本的整合與程式應用，所以這次就直接進入到 ASP.NET MVC 網站專案的應用，
先藉由幾個簡單的範例來說明「Dynamic LINQ + Entity Framework」在網站專案中的操作應用。
Dynamic LINQ 可以在 .NET 的專案中使用，不是只有限定在 ASP.NET MVC 中才能使用，
我目前工作上所開發的專案是 ASP.NET WebForms，也是一樣有使用 Dynamic LINQ。
在今年一月的時候有曾經寫過一篇「圖片裁剪大頭貼功能 - ASP.NET MVC + jQuery + imgAreaSelect」，
這是因為工作上的需求而延伸出來的，工作上的專案是使用 ASP.NET WebForm，而關於這個主題則是 MVC 與 WebForm 都有實作，
當初的實作在之後的專案上也做了一些修正，讓使用情境可以更為便利以及合理，所以也將當初的實作加以修正，
就如本篇文章的主題，這一次的實作有加入使用 fancyBox，使用 fancyBox 是相當簡單的，對於使用者來說是會更加的方便，
至少不用在上傳、裁剪、主頁等這幾個頁面一直跳來跳去的，
這一篇文章會著重於修改以及加強功能的說明，所以就不會再從頭到尾的把製作過程鉅細靡遺的詳述一次，
如果對於本篇文章有完全不懂的地方，會比較建議依序看過以下的幾篇文章，並且把範例程式抓回去看過後再回過頭來看這一篇，
