【问题标题】:how to not return null when a Data member field is not set in the data contract数据合约中未设置数据成员字段时如何不返回 null
【发布时间】:2011-04-16 07:05:54
【问题描述】:

我的WCF 服务有一个奇怪的问题,它以JSON 格式返回数据。 我想根据客户发送的请求返回有关“客户”的信息。

客户可以请求他们需要哪些客户信息字段,而服务只需要发送有关客户的信息。

例如:如果客户要求提供客户列表并说他们想要名字、姓氏、城市 每个客户然后服务器应该发送一个带有每个字段名称和相应值的json响应

有点像……

[
  {"firstname":"john","lastname":"Goodman","city" :"NY"},
  {"firstname":"brad","lastname":"newman","city" :"LA"}
]

如果客户仅要求提供 ID 和城市字段的客户列表,则响应应如下所示

[
  {"id" :"1234","city" :"NY"},
  {"id":"1235","city" :"LA"}
]

我最初的设计是实现一个“客户”类,然后拥有每个可能的“字段” 作为这个类的一个领域。然后在我的服务方法中,我得到了客户端指定的字段列表,并实例化了只设置了这些属性的客户对象。

我的运营合约是这样的

[OperationContract]
[WebGet(BodyStyle = WebMessageBodyStyle.Bare, ResponseFormat = WebMessageFormat.Json, UriTemplate = "Customers?fields={value}")]
List<Customer> GetCustomers(string value);

但问题是当我用“DataContract”装饰类并将每个字段装饰为“DataMember”时......如果未设置某些属性,它们在发送到客户端时仍会被反序列化为 NULL。我不希望这种情况发生。

此外,客户的可能字段列表非常长,因此类变得非常大。我宁愿将这些字段作为枚举集合存储在我的服务中,而不是类的字段。

然后我想到让我的操作返回一个IDictionary&lt;string,object&gt;,然后将每个字段和值迭代地添加到这个集合中。这不起作用,因为当字典被序列化时,它会显示 {"Key:dfas", "Value:34"} 等等,这不是我想要的

所以我有点卡住了。解决这个问题的最佳方法是什么?

我可以标记我的[DataContract],这样如果[DataMember] 属性未设置,即null,那么它们不应该被序列化并发送给客户端吗?

【问题讨论】:

    标签: wcf json serialization datacontractserializer


    【解决方案1】:

    您可以标记每个数据成员,使其在为空时不会被序列化。必不可少的部分是:EmitDefaultValue = false

    [DataContract]
    public class Person
    {
        [DataMember(EmitDefaultValue = false)]
        public string id { get; set; }
    
        [DataMember(EmitDefaultValue = false)]
        public string firstname { get; set; }
    
        [DataMember(EmitDefaultValue = false)]
        public string lastname { get; set; }
    
        [DataMember(EmitDefaultValue = false)]
        public string city { get; set; }
    }
    

    【讨论】:

    • 我还有一个问题......客户的可能字段总数非常大......比如说50......所以我在想是否有更好的方法解决这个问题,而不是将它们作为类中的属性......有什么想法吗?
    • '...为什么我在 5 年前没有发现这个!'
    猜你喜欢
    • 2013-09-22
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-09-03
    • 1970-01-01
    相关资源
    最近更新 更多