是否有任何其他原因我应该考虑忽略发出默认值是一种不好的做法？

Posted 2023-03-15

【中文标题】是否有任何其他原因我应该考虑忽略发出默认值是一种不好的做法？

【英文标题】：Are there any other reasons why I should consider omitting emitting the default value to be a bad practice?

【发布时间】：2011-12-16 05:16:44

【问题描述】：

我已经与 WCF 合作了一段时间，并且在客户端和服务器倾向于共同发布的地方工作；也就是说，几乎总是同时发布新版本。互操作性和版本控制不是问题（至少在这种情况下）。

MSDN 文档 DataMemberAttribute.EmitDefaultValue 和 Data Contract Versioning 建议发出默认值是一种不好的做法，除非有特定需要并支持版本控制。

在实践中，我发现省略默认值很有用，有时也很重要，尤其是当 WCF 服务必须回调多个客户端时。在高负载时，较大的消息会给服务器带来较高的内存压力并需要更长的时间来传输。

还有什么其他的理由可以避免这种情况吗？

【参考方案1】：

我还在某些地方使用DataMemberAttribute.EmitDefaultValue = false 来尝试限制传输的数据量。就我而言，我同时控制着客户端和服务器端，所以我没有任何问题。

我确实找到了 reference 与 DataMemberAttribute.IsRequired 的潜在冲突，这是我以前不知道的：

与 IsRequired 的交互

...如果 IsRequired 设置为 true，（表示必须存在值）和 EmitDefaultValue 设置为 false（表示该值不得 如果设置为默认值，则存在），此默认值 数据成员无法序列化，因为结果将是 矛盾的。如果这样的数据成员设置为其默认值 （通常为 null 或零）并尝试进行序列化，a 抛出序列化异常。

通常，这应该不是问题，因为一旦您尝试使用标记为EmitDefaultValue = false、IsRequired = true 和默认值的成员序列化对象，就会得到SerializationExeception，所以问题出在非常明显（我刚刚测试过）。但是，我可以看到EmitDefaultValue 是false 并且稍后将IsRequired 设置为true 的情况，这会产生问题（希望在部署更改之前进行测试）。

这种组合还有一个可能的问题：客户端可以使用默认值发送数据，这将被反序列化而没有问题。然后，您的服务可能会将其保存到数据库中，然后尝试将其发回，这将引发异常。

话虽如此，我认为您使用该设置是出于文档中所述的特定原因。请注意与IsRequired 的潜在冲突。

【讨论】：

在我看来，设置 IsRequired=true 和 EmitDefaultValue=false 很有用。对于原始类型或 DateTime，当客户端确实应该将值设置为非默认值时，它不会让客户端传递默认值。这使您不必检查服务器端的默认值，我认为这不是一种验证值的干净方法。