说到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 大牛，已经给我们创造了条件：。有机会要好好的研究下，里面的东西。

 

var params={

　　"setData":jsonData

};

举例数据，当中实际情况的数据明显要比这复杂很多。例如：each tr,find(“[]”).val() 等处理方式在里面。

 

到了交互阶段，后端要做的很简单：

是不是很简单呢？  是不是觉得相比之下，代码变轻了。重要的扩展性增强了，当出现一些新的字段新的页面数据时，我们只要轻轻的改变下student实体结构就能解决。

 

小弟，第一次写这么一篇随笔，写得不好之处还请见谅，指出批评。