svcutil 生成的代码中嵌套的泛型集合类是否有原因？答案

【问题标题】：Is there a reason for the nested generic collection classes in svcutil generated code?svcutil 生成的代码中嵌套的泛型集合类是否有原因？
【发布时间】：2012-06-11 15:49:01
【问题描述】：

我正在使用如下命令行生成我的数据合同：

svcutil /ct:System.Collections.Generic.List`1 MySchema.xsd

在我生成的代码中，我最终得到了这样的东西（我们称之为“样式 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>
    {
    }
}

为什么不生成这样（样式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 }
    }
}

从使用代码的角度来看，两者的最终结果似乎相同。样式 1 启用序列化的唯一原因是（CollectionDataContractAttribute 的文档表明它适用于类或结构）？它们是内部类，这是 100% 生成的代码，所以我可以忽略实现细节，但它有点困扰我（另外，我的类图中显示了那些“嵌套类型”）。

好的，所以我很困扰，无法将属性应用于属性来告诉它如何序列化。

【问题讨论】：

标签： generics datacontractserializer svcutil.exe

【解决方案1】：

据我所知，这个问题是 svcutil 的产物。如果我愿意手动编写序列化代码，从http://msdn.microsoft.com/en-us/library/aa347850.aspx 来看，我确实可以使用样式 1 并避免不必要的内部类型。

由于消费者的界面是相同的，我将轻松更新而不是拥有一个干净的对象模型。

【讨论】：