ASP.NET Web API一開始就以JSON.NET來取代JavaScriptSerializer以完成世代交替，JSON.NET的表現一直是中規中矩，以我的認知他是求穩。ASP.NET Web API採用Formatter的設計方式，預設有JsonFormatter與XmlFormatter，在求快的過程，如同頭文字D的86，換上一顆新F1引擎是最快的方式，我們來替ASP.NET Web API安裝一顆JilFormatter的高速引擎。
ASP.NET MVC的ActionResult一直有個讓人疑惑的地方，就是它的JsonResult，JsonResult預設使用了.NET Framework的JavaScriptSerializer類別，並不是說JavaScriptSerializer不好，每一個技術都有它的時空背景，.NET Framework發展過程中JSON格式也是慢慢才成為標準。在JSON格式流行與大量使用下，JavaScriptSerializer已經有點上氣不接下氣。而微軟在ASP.NET Web API第1版中就非常明確的以JSON.NET取而代之。而ASP.NET MVC到第5版為止雖然一直無異動這部分的程式碼，原因也很簡單，ASP.NET MVC設計了優良的擴充點，讓開發者想要擴充原有的ActionResult也不是太難的問題。
如果讀者想使用Json.NET來擴充原有的ActionResult，可以參考Json.NET的作者James所寫的JsonNetResult或是參考黑大所寫的JsonNetController版本。這都是能直接上線使用的程式碼，我就不再多說明。
最近在進行專案效能調教，在MVC專案中使用了大量的JsonResult，在黑大JSON轉換效能評比-Json.NET，就決定是你了!得到JavaScriptSerializer早就應該退休了的結論，取代ASP.NET MVC預設JsonResult是個快又有效的一步。不過在這個唯快不破的時代，我想找找是否還有更好的選擇。
我發現一個JSON(反)序列化新選擇-Jil。
以下效能圖表參考原專案：
多年前還在手刻AJAX時，前端後端要進行資料交換還是很辛苦的事。後來發現JSON這個好物，不過那個年代（也不過三年前）不管是瀏覽器或是伺服器端的JSON環境都還不太成熟。現在，JSON已成為顯學，不管是前端應用程式還是後端伺服器應用程式都已大大支持JSON格式。JSON格式的好，用過都知道。如果在開發階段要準備JSON資料，嗯，就不是那麼好玩了。今天就是要介紹一套起方便的網頁工具，讓我們可以極速來產生所需要的JSON測試資料。
上圖是一個ASP.NET Web API專案，從範例Northwind資料庫裡加入兩張有關連性的資料表到Entity Framework（EDMX）裡，很正常的，它會加入巡覽屬性（Navigation Property），當我們什麼都不修改，直接加入API Controller，例如，ProcutsController和OrderDetailsController然後建置、啟動、測試Web API服務會立即得到一個錯誤。
完整訊息如下
from:http://www.json.org