我的 DataContract XML 中的所有这些空集合条目是什么？
有谁知道为什么 NetDataContractSerializer 可能会在序列化集合中添加“nil”条目？
例如，
<Jobs z:Id="17">
<_items z:Id="18" z:Size="4">
<JobRecord z:Id="19">
<Name z:Id="20">Job1</Name>
</JobRecord>
<JobRecord i:nil="true" />
<JobRecord i:nil="true" />
<JobRecord i:nil="true" />
</_items>
<_size>1</_size>
<_version>2</_version>
</Jobs>
请注意三个额外的“JobRecord”条目和附加元素，其中显示“嘿，我知道这里有四个节点，但只有其中一个具有任何意义。”
这似乎是一种奇怪的行为。好的，所以我可以看到 NDCS 深入观察对象图，并且可能正在摆弄一个大小大于序列化项目数量的支持数组（想想列表的支持数组）。
这就是这里发生的事情吗？它是构造函数创建的用于处理yield return（这是 JobRecord 的来源）的类的工件吗？
Does anybody know why the NetDataContractSerializer might add "nil" entries in a serialized collection?
For example,
<Jobs z:Id="17">
<_items z:Id="18" z:Size="4">
<JobRecord z:Id="19">
<Name z:Id="20">Job1</Name>
</JobRecord>
<JobRecord i:nil="true" />
<JobRecord i:nil="true" />
<JobRecord i:nil="true" />
</_items>
<_size>1</_size>
<_version>2</_version>
</Jobs>
Notice the three extra "JobRecord" entries and the additional element saying "hey, I know there are four nodes here, but only one of them means anything."
It seems like an odd behavior. Okay, so I could see that the NDCS peers deeply into the object graph and might be twiddling with a backing array that has a size that is greater than the number of items being serialized (think of the backing array for a List).
Is that what's going on here? Is it an artifact of the class the constructor creates to handle yield return (which is the source of the JobRecord)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在 .net 中，集合和列表在空间不足时通过自动调整大小来工作。为了提高效率，他们不仅仅在每次用完时额外调整大小 1，而是使用内部算法来调整大小并留出一些额外的空间，目的是不必经常调整大小。
您在这里看到的是正在序列化的集合，并且所有额外空间也都已序列化。这是因为序列化完全按原样存储集合，因此当您反序列化它时，您会得到相同的结果，并留下相同数量的内部空间。
如果您使用的是列表，您可以通过查看
Capacity属性来检查内部保留的空间。如果您想在序列化集合之前删除任何额外的空间，您可以调用。
这会将可用容量设置为与所包含的项目数相同，因此不会有保留空间。
不幸的是，如果您正在使用的集合的容量不可用，您只需要信任该集合即可在内部调整大小。
不管怎样，我不会太担心它，除非你真的需要节省空间。如果这样做，请改用固定大小的数组。
In .net collections and lists work by auto resizing when they run out of space. To make this efficient they don't just resize by 1 extra each time they run out, they use an internal algorithm to resize and leave some extra space, the aim being that they don't have to resize too often.
What you are seeing here is the collection being serialized with all of the extra space being serialized too. this is because the serialization is storing the collection exactly as it is, so when you deserialize it you get the same back, with the same number of internal space left.
If it's a List you are using you can check the internally reserved space by looking at the
Capacityproperty.If you want to remove any extra space before you serialize the collection you can call.
This will set the available capacity to be the same as the number of items contained, so there will be no reserved space.
Unfortunately, if it's a collection you are using the Capacity isn't available, you just need to trust the collection to do it's resizing internally.
Either way, I wouldn't worry about it too much unless you need to be really really space efficient. If you do, use a fixed size array instead.
只是猜测，但请注意
z:Size="4"。对我来说，看起来像是四个JobRecord条目，我猜其中三个 =null。Just a guess, but note the
z:Size="4". Looks like fourJobRecordentries to me, and I guess three of them =null.