應用程式框架實戰二十九:Util Demo介紹
上文介紹了我選擇EasyUi作為前端框架的原因，併發放了最新Demo。本文將對這個Demo進行一些介紹，以方便你能夠順利執行起來。
這個Demo執行起來以後，是EasyUi的一個簡單CRUD操作，資料庫中也只有一個簡單的表，整個操作不帶任何業務邏輯。
看到這裡，不少朋友難免感到失望，搞這麼複雜一個架構，就只用來實現一個簡單的CRUD操作，不是大炮打蚊子嗎？
不要急，我的目的不是教你如何實現CRUD，我還沒有這麼無聊，我是希望通過這個簡單的CRUD操作，幫你引出一些框架特性，大致包括下面內容。
- 分層架構，雖然是一個簡單的CRUD，但基本的構造塊都包含進來了，還有一些沒介紹到的構造，比如領域服務等，我會在後續提供其它示例時再引入。我前面也已經介紹過一些構造，還沒介紹到的會補上來。
- 抽象和封裝CRUD操作，雖然CRUD貌不驚人，但不論多複雜的系統，多少有一些CRUD的機械工作，對於簡單的系統，CRUD則佔據大半江山，所以對CRUD抽象和封裝是有必要的。
- Mvc控制元件封裝，我將以封裝EasyUi控制元件為例，為你詳細介紹如何把Html封裝起來，並使用Lambda表示式為你做更多的工作。
- 依賴注入，對於這種比較複雜的架構，依賴注入框架是必須的，如果沒有它，這種架構用起來就非常痛苦了。
- 查詢封裝，我已經花了很多篇幅來介紹對查詢的一些封裝支援。通過這個示例為你介紹簡單查詢，你會感受到查詢封裝的必要性，你平時那些雜亂無章的查詢條件判斷已經消失無蹤了。對於複雜的查詢，需要配合Linq 語句，更復雜的採用Sql，我以前通過儲存過程的方式解決，不過發現分頁和條件判斷不太方便，最近我將Dapper引入，並封裝了Sql查詢元件，用來自動拼接Sql，提供了條件自動判斷和分頁等功能，待有需要的時候我會放出給大家參考。
- 全域性異常處理。通過一個簡單的全域性異常處理模型，並配合自定義異常Warning，可以解決大部分異常處理問題。
- 日誌封裝。系統一旦部署出去，你的斷點除錯就不管用了，這時查詢問題將主要依賴日誌。哪怕在開發階段，斷點除錯也不是一個高效的排錯手段，通常在檢視日誌無法解決問題時才進行斷點除錯。大部分人採用Log4.Net進行日誌處理，是不是引入Log4.Net就萬事大吉了呢。Log4.Net只是一個底層元件，幫你把需要記錄的資訊儲存一下而已。至於需要記錄哪些資訊，這是你應該考慮的，如果你的每條日誌都需要記錄大量的系統資訊，比如Ip、執行緒號一類的東西，你不進行封裝，就意味著開發人員每次呼叫日誌元件時，需要自己手工設定。日誌更高階的用法，甚至能幫你進行效能調優。
- Excel檔案匯出封裝。檔案匯出是一個常規操作，大部分時候都會匯出為Excel格式。我以前採用簡單的CSV格式，CSV格式使用逗號分隔各列資料，主要優勢是簡單，毛病是沒有樣式，更別說多表頭。本次引入NPOI，並對多表頭設定進行了高度封裝，以大家熟悉的RowSpan和ColumnSpan的方式進行設定，大副簡化了NPOI的操作。
- 測試資料生成。我們平時開發一個新模組，為了進行測試，一般需要錄入一些資料，這些操作多半是手工進行。大部分人都知道偷懶，只是意思一下，隨便錄入幾條，不過很多問題只有達到一定資料量才能有效測試。通過幾個簡單擴充套件和封裝，就可以為簡單模組生成批量測試資料。
- 程式碼生成。無論如何努力的封裝和抽象，你最終發現還是有一些程式碼需要來回複製，這就是程式碼生成器上場的時候到了。我將為你簡單介紹CodeSmith，以及CodeSmith自帶的EF Code First模板，你會發現簡單修改就可以用於生產環境了。不僅如此，還會把我整理的CodeSmith模板分享出來，這套模板是根據Util量身定製的。
在看完以上介紹後，希望你能夠增強對本系列文章的信心。
我這個系列主要分享的是應用程式框架的搭建和封裝經驗，這些程式碼只是給你參考用的。我並不會隨時關注效能問題，因為我平時的專案要求並不高，所以程式碼中總是採用最省力的方式，比如反射，查詢時獲取全部欄位等，我僅在確實碰到效能問題時才進行區域性調優。
下面先介紹Demo的目錄結構。
Applications包含一個VS解決方案，它是你能夠執行的應用程式，這個解決方案採用了DDD架構分層。
為了示例的真實性，我將應用程式和應用程式框架分到了兩個VS解決方案中，這一點非常重要，這樣可以顯著減少應用程式的編譯時間，另一個好處是可以對團隊成員透明，減少複雜度。所以Applications依賴一些DLL，這些DLL被指定到一個目錄，這就是Release。管理DLL有很多方式，標準方式是Nuget，如果你喜歡，請自行建立。
Util目錄包含另一個VS解決方案，這個就是應用程式框架。我已經將Release目錄中的DLL刪除，這樣做是為了節省空間，你只需要編譯Util解決方案，相關的DLL就會生成到根目錄的Release中，這是因為我更改了每個類庫的生成路徑。
當你開啟Util解決方案，你會發現某些專案中包含名稱為00-Source的目錄，這個目錄中包含了某個第三方開源框架的原始碼，這樣做的唯一原因是為了減少生成的DLL。如果你以後也準備這樣幹，需要注意將該開源框架的條件編譯符號複製到你的專案。
TestBin目錄用於放置測試專案生成的DLL，沒有特別的用途，只是方便統一管理測試DLL，以免每個目錄都包含一堆垃圾。
Libraries目錄是依賴的一些第三方DLL。
Data目錄包含一個Sql Server 2005的備份檔案，裡面是一個單表，有1萬行測試資料。
上面介紹了目錄情況，現在你得把Demo執行起來。
第一步開啟Util解決方案編譯。
第二步開啟Applications中的解決方案，編譯。
第三步還原Sql Server資料庫，記住還原，不要附加。
第四步修改連線字串，這些基礎的不要我說了吧。
第五步，設定Managements.Presentation專案為啟動專案，執行。
如果沒什麼意外的話，你應該能跑起來了，如果不行，注意你的開發環境與我的可能有差異。我使用的是VS 2013,MVC 4.0,還有一些人發現他的MVC版本是4.0.1，你本機如果沒有Mvc 4.0的DLL，找別人給你發幾個4.0的DLL就可以了。
目前發出的Demo沒有包含上面所述的全部功能，我會在即將介紹到相關功能時更新，請關注。
還有些朋友反應看不太懂，不要急，這是正常人的反應，看別人的東西總是很頭痛，你可以暫時不要看Util解決方案，先把Applications解決方案看熟，我後面會逐步介紹各構造塊。
後續Demo，不再通過EMAIL方式發放，以免汙染評論區。
最後，希望大家狂點推薦，少點反對，嘿嘿。
.Net應用程式框架交流QQ群: 386092459，歡迎有興趣的朋友加入討論。