关于解析JSON的问题

[西凉董卓]

比如我有一段JSON有5个字段，订单，联系人，联系地址，联系电话，商品，其中商品字段是个集合，集合中一共有3个元素，也就是说同一个订单有3件商品，那么我要解析成3条记录，这3条记录分别都要有订单，联系人，联系地址，联系电话，商品信息，之前都是一个订单一件商品，这个容易解决，现在出现这种情况，我不知道该这么解析了。

[xdashewan]

把你之前的商品字段改成数组或者集合

[by_封爱]

贴出你要解析的原始数据. 在贴出你要解析后的数据..

[以专业开发人员为伍]

说到解析，其实跟数据结构基本知识有关。虽然你可能在某个程序中并不真的去把 json 字符串解析为强类型的自定义数据结构，而是解析为灵活结构的 JObject、JArray、ExpandoObject、List<ExpandoObject> 等等，但是假设你“写不出来数据结构”，或者数据结构中有静态嵌套结构，那么这就会有好多设计问题。 所以你的问题，不管你是否最终要解析强类型的面向业务的自定义数据结构，只要有理解上的问题，都应该先自己写出来一个自定义的数据结构作为分析的基础。

[以专业开发人员为伍]

对于设计一个 class 结构，假设一个人“会”

public class A
{
    public B prod;
    ....
}

这样的设计而不“会”

public class A
{
    public List<B> prods;
    .....
}

这样的设计，我们其实应该好好分析一下背后的原因。

[以专业开发人员为伍]

这就好像是你给别人介绍自己，既要说到你的细节又要有整体架构，又要言简意赅。 你心里应该对于“订单”这个概念有一个直观的图形，那么你就知道其中的“订单头、明细、明细项目、付款、付款方式、运输、运输明细、签收”等等可以有多种形式，而哪一种形式更加适合领域模型的本质（而不是你自己觉得简单方便）。 你说的“那么我要解析成3条记录，这3条记录分别都要有订单，联系人，联系地址，联系电话，商品信息”这个话，其实一般来说会第一时间就被排除掉。你还是在千方百计地套用你的“之前都是一个订单一件商品”这种概念，产生了多余的所谓“解析”要求。