說到Json,大家都會想到這樣的一個數據結構：
沒錯，Json的確帶給我們很漂亮的數據。方便我們操作。
在平時，我們經常遇到同時保存List<model>這樣的數據信息。例如List<Student>,List<StudentSetting>等等的數據。可是我們又不想用表單Post時使用serializaArray(),因為我們很難把握數據在前端是否存在一些特定的前端業務影響。比如：點擊張三時，他是班長，在他的Setting中會多出一個權限控制或者管理分數評估，那么我們就不能單純的使用serializaArray去提交他的Value，因為他的分數評估還得參照其他同學的表現分（多），相信看到這里的人都知道serializaArray也許並不能滿足（小弟瞎舉例）。重要的是如果使用了serializaArray，那么后端接受數據顯得格外笨重。 怎么說呢？
這樣子的代碼，不免讓人反感了不少。雖然ids，names。。。他們都會以正確順序i相對應。沒錯，這是我直觀的想法。因為你無法分辨得到頁面上到底還有什么操作！例如：checkbox選項的選擇（萬一不選擇呢，那么下一個checkbox值是不是跑到上一個index了？），好，你可以用以value做手腳，植入id拼接用於后台區分。可是問題又來了，這樣子的數據接收list的時候，又該如何移形換影，就算最后移了換了。你不覺得代碼又笨重了不少嗎？
就這時候，讓我想到了Json.Decode,沒錯！就是System.Web.Helpers.Json.Decode。
想到后端解決關鍵，那么前端呢？
開源的世界猶如璀璨的明珠！巨人的腳印就足以讓小弟這樣的小蝦學習了。Douglascro Ckford 大牛，已經給我們創造了條件：https://github.com/douglascrockford/JSON-js。有機會要好好的研究下，里面的東西。
var params={
"setData":jsonData
};
舉例數據，當中實際情況的數據明顯要比這復雜很多。例如：each tr,find(“[]”).val() 等處理方式在里面。
到了交互階段，后端要做的很簡單：
是不是很簡單呢？ 是不是覺得相比之下，代碼變輕了。重要的擴展性增強了，當出現一些新的字段新的頁面數據時，我們只要輕輕的改變下student實體結構就能解決。
小弟，第一次寫這么一篇隨筆，寫得不好之處還請見諒，指出批評。