接連三篇有關 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 並不需要太多的介紹與教學，其實對於既有 ADO.NET + T-SQL 已經相當熟悉的開發者應該可以短時間上手，我所看到最多的問題應該會是在「物件導向」的觀念與使用，畢竟之前使用 ADO.NET + T-SQL 的操作處理都是直接使用弱型別，從取得資料一直到資料的顯示輸出，甚至資料的輸入，都沒有什麼機會用到所謂的物件導向，另外要特別強調的就是，不是在專案裡建立了好多個 class 然後使用類別在程式裡傳來傳去就可以叫做物件導向，例如你在一個類別的建構式裡塞了成千上百的程式然後又直接跟資料庫串接並且又有商業邏輯的處理，這完全不是物件導向，還是依然是在程序導向的開發。
嗯…… 這一篇所要講的跟上面所講的沒什麼關係（只是單純地抒發想法），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 所開發的專案都可以使用（一定要先這麼說，不然一定很多人會有所誤解，這是寫部落格文章四年多來，接到無數回應、詢問所得到的心得。）
之前有介紹過如果我們要做程度碼度量，在 Visual Studio 裡可以使用內建的「計算程式碼度量 （Code Metrics）」功能，另外我也在這一篇「Visual Studio 計算程式碼度量 - Code Metrics Viewer 2013」介紹另外一個工具「Code Metrics Viewer 2013」也同樣是在做程度碼度量計算的工作，兩個功能其實都是差不多的，只是要看這些程式碼度量的數據都是要經過工具的計算，而且無法馬上或是隨時看到，比較重視這些數據的開發者是會感到有些不方便。
這篇要介紹的「Microsoft CodeLens Code Health Indicator」能夠將程式裡每個方法的程式碼度量給顯示在 CodeLens 上面，是個蠻方便的工具。
當我們在 Visual Studio 裡開啟了一堆檔案時候，有時候想要去方案總管裡查看目前所編輯的檔案是在哪一個專案、哪一個資料夾裡，通常就會看到很多開發者開始在方案總管裡翻箱倒櫃，如果只有一個專案，甚至專案結構比較簡單的，那麼就能夠很快地找到，但如果是比較大型的專案，或是拆解得相當瑣碎的專案，要找到目前編輯檔案的所在位置就是一件大工程了。
這個功能的操作，我都是使用工具來做處理，但如果是沒有使用到這些工具時，就沒有辦法可以使用比較快速方便的方式來解決嗎？
這一篇就告訴大家可以做些什麼樣的調整，讓我們的操作可以一樣達到相同的效果。
這是個小功能，但卻是可以讓開發者能夠節省很多時間的功能，所以別小看。
我在使用 VS2013, VS2012, VS2010 開發的時候，我都會安裝一套 Visual Studio 的擴充工具「VSCommands」，這個工具有提供相當多的功能，也因為已經長久習慣在 Visual Studio 裡使用，所以有很多由 VSCommands 所提供的功能都讓我一直以為那是 Visual Studio 內建提供的，這是一個需付費購買的工具，不付費與付費版本會有蠻多的差別。
但是到了 VS2015 之後 VSCommands 就不再繼續發佈相對應的版本，這對於已經習慣使用的我來說就有許多功能就必須要找替代方案了，其中的「Restart Visual Studio (Elevated)」快速以系統管理員身份重新開啟 Visual Studio 這個功能就是我時常都會用到的，雖然 VSCommands 沒有相對應 VS2015 的版本，不過還好有找到一個功能相近的 Extensions，在這邊介紹給大家。
我所使用的 Visual Studio 2013 環境色彩佈景主題是使用「藍色」，這佈景主題顏色也是我一直從 Visual Studio 2005 一直沿用到現在，當然在 VS2005, VS2008 是沒辦法選擇更換，到了 VS2010 之後就有了可以更換各種 Theme 的擴充功能，不過大多數的人還是使用藍色為主，然而到了 VS2012 後就變成可以選用 Dark 或 Light 的主題，但是這兩種我都不喜歡，Dark 太黑了，連選單都是黑的，常常找個東西要找很久，但是 Light 又太刺眼了，看久了眼睛會相當疲累，所以我就會使用 Color Theme Editor 選用已經習慣使用的藍色主題，不過之後藍色主題又重新回到 VS2013 預設環境主題之一，在此之前無論用什麼主題然後再去套用不同的文字編輯器顏色設定都不會有太大問題，為此我還有寫了一篇文章作介紹：mrkt 的程式學習筆記: Visual Studio 2013 佈景主題與 Code Style
但是到了 Visual Studio 2015 卻出現了一點點的不一樣，因為找不到怎麼修改，所以就在這一個月裡都是使用 Dark Theme，但真的是相當不習慣呀，所以認真的找了一下怎麼修改，總算又可以使用 Blue Theme 並且使用 Son of Obsidian 的 Code Style，為此寫篇文章做個記錄（其實還蠻簡單的）。
繼續上一篇「NSubstitute 練習題 - void 不回傳值方法但有使用到 out 參數」最後所提到的，當測試對象裡所使用的其他類別方法拋出錯誤時要怎麼去做這個情境的測試。
一樣是使用 NSubstitute 完成這一次的練習。
嗯…… 好久沒有寫文章，再次寫文章的題目卻讓人搞不太清楚，簡單來說就是看下面圖會比較清楚，
不要問為何會有這樣的程式，又為何要這麼樣設計與使用，那個不是重點，重點在於怎麼去對這一段程式去做測試。
