接連三篇有關 Dapper 的文章，都是使用 LINQPad 向各位說明，對於有些開發者來說可能無法馬上可以體會，因為沒有一個明確或是簡單的應用範例，所以感覺就會有點在空談，所以這一篇就用一個簡單的 ASP.NET MVC 網站範例來做介紹，之前曾經在 twMVC #10 裡有分享過「ASP.NET MVC Model 的設計與使用」這個主題，然後又在部落格裡寫了以「ASP.NET MVC 的 Model 使用 ADO.NET」為題的五篇系列文，這一篇的範例文章就以那五篇系列文最後所完成的簡單範例做修改，在方案裡添加使用 Dapper 的 Repository 專案，並且讓 ASP.NET MVC 與 WebForm 網站都可以直接使用。
關於定義類別這件事，尤其是裝載資料的 Model 類別，在開發的過程中算是稀鬆平常的事情，但如果你的開發是習慣使用弱型別並且從頭到尾（從資料庫取得一直到資料顯示在頁面上）都使用弱型別，那麼建立 Model 類別的次數就會相對地比較少，因為會用到的情況比較少，但如果你已經試著在專案裡使用 Dapper 開發或是早已經使用 ADO.NET + T-SQL 然後自行處理資料對映到類別的操作，那一定會遇到一種情況會讓人相當猶豫不決，那就是查詢所取得的欄位數量不多時，實在是不想再去建立一個新的類別（因為建立的類別已經一堆了，再新建下去就搞不清楚了）。
Dapper 有提供查詢結果對映到 dynamic 型別，上述所遇到的狀況就能提供方便的處理，如此一來就不必每個查詢都需要建立一個新的類別，減少管理及維護上的困擾。
前一篇已經向大家介紹了 Dapper 這一個資料存取套件，可以作為解決專案仍須使用一般 T-SQL 操作但是又不想直接處理弱型別的情境，尤其是在比較強調使用「強型別」的 ASP.NET MVC / Web API 專案裡，可以不必硬著頭皮使用 Entity Framework（因為許多企業的系統環境不允許），而且也可以兼顧既有的商業邏輯包袱（都已經說是包袱了，還是希望可以早點解下並丟開）。
Dapper 對於一次新增多筆資料的做法是相當簡單的，這篇也跟大家介紹如何處理一次新增多筆且大量的資料新增。
這一篇文章的內容是依據我在公司裡所分享的主題「ASP.NET.MVC / Web API 另一種存取方式」再加以整理。接觸 Dapper 這個資料存取套件是有一段時間，但一直都沒有機會使用上，因為之後所做的專案多半都是使用 Entity Framework，而在去年要開始做新專案的時候，因為系統環境以及舊有包袱的緣故，於是我就想起了 Dapper，也的確解決了許多原有的問題並且大來很大的效益。
這一篇介紹 Dapper 並不會有特別深入的使用介紹，大概只能算是入門介紹，最主要的目的是要讓大家能夠知道在現有環境無法使用 ORM 的情況，尤其又是開發 ASP.NET MVC / Web API 的專案，除了 Entity Framework 之外能夠有其他的替代方案。
注意，並不是說 ASP.NET MVC / Web API 才能夠使用 Dapper，任何你之前使用 ADO.NET + T-SQL 所開發的專案都可以使用（一定要先這麼說，不然一定很多人會有所誤解，這是寫部落格文章四年多來，接到無數回應、詢問所得到的心得。）
在 2015 年 12 月裡所舉行的 twMVC#21，我在主講的「以實例說明 ASP.NET Web API 服務的開發與測試過程」裡就有將 NanoProfiler 介紹給大家，而到了現在才有時間將使用、安裝的說明給整理出來，所以將會有一系列的文章說明如何使用 NanoProfiler。
Elmah 有提供一個基本的記錄顯示介面，可以讓我們看到有哪些 Exception 被記錄下來，但長久下來要在一大多的 Exception Record 裡去找出問題或是作分析就會是一大難題，因為這個基本的顯示介面是相當陽春的，如果有將這些記錄存在 SQL Server 裡的話，還可以在 SSMS 裡去下 T-SQL 做資料查詢，但是要要查個 Exception 紀錄還要開啟 SSMS 也是蠻累人的，尤其是有些團隊的環境裡是不允許開發人員直接連接正式環境的 SQL Server，所以就無法使用 SSMS 去做查詢了。
如果有將 Elmah 所攔截的例外錯誤給存放到「SQL Server」的團隊，這邊向你們介紹一個簡單方便的套件「ASP.NET MVC ELMAH Dashboard」
2009 年在台灣微軟 7F 的一場由 Will 保哥所帶來的一個多小時教學課程開始，我第一次接觸了 ASP.NET MVC，當時的我對於這項技術還是懵懵懂懂，整場下來猶如走馬看花一般，太多觀念與實作方式與當時我所熟悉的 ASP.NET WebForm 有著極大的不同，但當時對我而言，比較讓我不明白的是在 View, Controller 以及 Route，因為這是 WebForm 所沒有的，但已經使用 LINQ to SQL 與 Entity Framework, 物件導向程式開發的我來說，在 Model 部分是沒有讓我有任何的不明白，當時我已經不再使用 DataSet, DataTable, DataSource Controls，而在一年之後的七月，我就全面開始以 ASP.NET MVC 在工作上進行專案開發，而從 ASP.NET WebForm 到全面轉換為 ASP.NET MVC 開發，這過程我花了一個多月，不算順利、遇到很多問題、撞了很多牆、衝擊很多觀念，最後就一直到了現在。
這邊分享一些我的看法與建議。
經過兩篇文章的鋪陳，總算來到了最後一篇，將會把修改過的最後完成版提供給各位，讓各位開發 Web API 專案時在操作使用 Postman 能夠方便與易於管理。
ASP.NET Web API - Import a Postman Collection Part.1
ASP.NET Web API - Import a Postman Collection Part.2
接續上一篇的內容，來看看最原始的做法有些什麼樣的問題，先開門見山做個說明，這一篇會再沿用別人所提供的改良做法，不過最後的結果依舊還是會有一些問題存在，所以最後在第三篇的文章裡將會提供我所修改過的程式碼，而這也是我開發的專案以及部門其他開發團隊所使用的方法。
在開發過程中，開發人員主要還是會透過 Postman 進行開發的偵錯、測試、操作等，如果開發人員只有一個人的時候，在 Postman 裡增加或管理 Collection, API 都還算是可以控制，但如果是多人開發團隊共同開發一個 Web API 專案時，就會發現到每個人所使用的 API Collection 內容都有很大的出入與差異，所以就必須要有一個能夠一致化 API Collection 的功能，讓團隊的每個開發人員都使用一樣的 API Collection 進行操作。