问题
I'm generating my data contract with a command line like:
svcutil /ct:System.Collections.Generic.List`1 MySchema.xsd
In my generated code, I end up with something like this (let's call this "style 1"):
partial class A : object, System.Runtime.Serialization.IExtensibleDataObject
{
private BType collectionB;
public BType CollectionOfB
{
get { return collectionB; }
set { collectionB = value }
}
[System.Runtime.Serialization.CollectionDataContractAttribute(...)]
public class BType : System.Collections.Generic.List<B>
{
}
}
Why does it not generate like this (style 2)?:
partial class A : object, System.Runtime.Serialization.IExtensibleDataObject
{
private System.Collections.Generic.List<B> collectionB;
public System.Collections.Generic.List<B> CollectionOfB
{
get { return collectionB; }
set { collectionB = value }
}
}
From the perspective of consuming the code, the end results of both appear identical. Is the only reason for style 1 to enable serialization (the documentation for CollectionDataContractAttribute indicates that it applies to class or struct)? They are internal classes, and this is 100% generated code, so I can just ignore the implementation details, but it bothers me a little bit (plus I've got those "Nested Types" showing up in my class diagram).
Okay, so it bothers me a lot that is isn't possible to apply an attribute to the property to tell it how to serialize.
回答1:
So as best as I can tell, this problem is an artifact of svcutil. If I was willing to code up the serialization by hand, judging from http://msdn.microsoft.com/en-us/library/aa347850.aspx it appears that I could indeed use style 1 and avoid the unnecessary internal types.
Since the interface for the consumer is identical, I'm going to go with ease of updating over having a clean object model.
来源:https://stackoverflow.com/questions/10934379/is-there-a-reason-for-the-nested-generic-collection-classes-in-svcutil-generated