ASP.NET MVC 與 Elmah.MVC 2.1.1 以及使用 Windows Azure SQL Database 的Schema 修改

將近一年的時間沒有寫關於 Elmah 或 Elmah.MVC 的文章，因為這工具的安裝與使用並不是太過於複雜，所以之前的文章內容都已經含蓋了大部分的功能，而最近透過 NuGet 為專案加入 Elmah.MVC 時發現到版本推進到了 2.1.1，觀察安裝後的內容後有發現到了一些改變，畢竟自從去年 11 月所更新的 2.0.2 之後，一直到今年的七月才又再一次的更新到 2.1.0，這一篇就來看看有做了什麼樣的改變。

 

---

ASP.NET MVC 4 + jQuery EasyUI Tree and TreeGrid

在今年七月時有發了兩篇關於無限階層樹狀選單的文章：

「ASP.NET MVC + jQuery Easy UI Tree 無限階層的樹狀選單」
「ASP.NET MVC + jQuery Easy UI Tree 無限階層的樹狀選單 - 使用 JSON」

第一篇說明如何在 ASP.NET MVC 的 View 裡使用 Razor Page Helper 建立遞迴顯示樹狀節點的 Tree 清單內容，然後再套用 jQuery EasyUI Tree，讓頁面上的清單轉換為樹狀選單。

第二篇則是進階的內容，分別說明如何在前端接收 JSON 資料然後產生樹狀選單，另一個則是說明非同步載入樹狀選單節點內容的作法。

這兩篇都是在說明如何去顯示既有的階層資料然後套用 jQuery Easy UI Tree 來顯示為樹狀選單，然而階層資料的維護管理功能則是隻字未提，這也不是要賣關子或是留一手，而是這個管理功能說起來也算是有些複雜，一直推敲琢磨該用什麼方式來說明會比較好，所以一直延宕至今。

因為也不是什麼多麼稀奇古怪的實作內容，也沒有什麼好隱藏的，所以最後決定將做好的樹狀選單的階層資料維護功能提供給大家，將整個 Solution 放到 GitHub 上面，所以這一篇文章只會簡單說明如何使用 jQuery EasyUI TreeGrid 做出這樣一個階層資料維護功能，其餘的就請各位自己去 GitHub 抓檔案下來看。

 

---

ASP.NET MVC Route 基本題 - 如何自定 URL 的子目錄路徑

對於剛學習 ASP.NET MVC 的朋友來說，Route 設定是比較少去碰到的，甚至於有人會對於 Route 是不太清楚甚至於有些模糊，這一篇講個 ASP.NET MVC 初學者常會誤解的作法，哪就是設定 URL 的子目錄路徑，尤其是已有 ASP.NET WebForm 開發經驗的朋友會把以往的開發經驗給帶到 ASP.NET MVC 的開發上，所以在這邊說明一下。

 

---

錯誤更正：有關 ASP.NET MVC 分層架構使用 Unity 的 DbContext 處理

2014-12-02 補充說明：
這一系列的文章並不適合初階及中階的開發人員，如果你是程式開發的初學者或是 ASP.NET MVC 初學者，甚至是開發經驗少於兩年的開發人員，請馬上離開此篇文章。

有網友在「ASP.NET MVC 專案分層架構 Part.6 - DI/IoC 使用 Unity.MVC」這篇文章提出了一個問題：

一開始我還以為是我的 DbContext 是不是有做了什麼特殊設定還是忘了做什麼設定才會出現這樣的情況，然後我把範例程式給找出來，按照網友所提出的情境做操作，結果還真的如他所說的，當我在執行的網頁上做新刪修查時都不會有問題，資料也會同步，但如果直接對資料做修改後，網頁上面的資料並不會跟著改變，在仔細看過原本的程式之後才恍然大悟，我犯了一個嚴重的低級錯誤才會導致這種資料不一致的狀況，這一篇就是來說明要如何改正這個問題。

有關這個錯誤的文章如下：

「ASP.NET MVC 專案分層架構 Part.6 - DI/IoC 使用 Unity.MVC」「ASP.NET MVC 4 使用 Unity bootstrapper for ASP.NET MVC」

可以按照此篇文章的作法來修正錯誤。

 

---

ASP.NET MVC + NLog + Clutch.Diagnostics.EntityFramework 追蹤 EF 執行的 SQL Command

有關追蹤觀察 Entity Framework 所產生的 SQL Command，在之前我有寫了幾篇文章來做介紹：

觀察 ADO.NET Entity Framework 5.0 產生的 SQL Command 與取得 Entity 對應的 Table Name

觀察 Entity Framework 轉換所產出的 SQL Command

但是在上面兩篇文章裡所介紹的方法都是必須要去添加程式，開發專案的時候總不能每個執行 EF 的地方都要去手動加入程式片段，所以我一直找尋一個最簡單而且也不需要對專案程式再去做修改的解決方式。

其實現在有很多方法可以去追蹤觀察 EF 所產生的 SQL Command，但往往都需要過多的配置或者是被迫要更改我們已經習慣的開發方式，過多的配置就代表日後的維護困難以及交接的不便，而更改已經習慣的開發方式就影響甚鉅，有時為了需要妥協而採納一個不熟悉也不習慣的方法，這會嚴重影響開發效率，甚至讓原有的開發人員四處碰壁。

剛好今天看到了一篇文章的介紹，並且在自己實際開個專案來測試一下，的確是相當符合我的需求，不需要對原本程式做過多的修改或是更改程式原有結構（或是更換範本），也不需要改變我原來的開發習慣，只要利用已經熟悉的 NLog 並且再加入 Clutch.Diagnostics.EntityFramework 就行了。

 

---