Question

我们有第三方dll包含（除此之外）我们的实体 entites都标有[Serializeable]属性。

我们现在需要创建一个新的WCF服务，它将暴露一些这样的实体问题是，由于entite未使用DataContract和DataMember属性声明，因此属性名称附加__BackingField！

我知道使用DataContarct \ Member属性会解决这个问题，但鉴于我无法使用实体修改第三方dll，是否有不同的解决方法？

Answer 1

使用[Serializable]属性修饰的类型将字段序列化，而不是属性（即[Serializable]“合约”）。如果第三方类型使用自动属性（如下所示），编译器将使用k_BackingField后缀创建字段，这将是序列化的。

如果您无法更改第三方库中的类型，则可以选择在客户端上使用相同的库。在为服务创建代理时（使用svcutil或Add Service Reference），您可以引用第三方库，生成的客户端不会为合同创建新类型，而是重用库中的类型。这样您就不必处理具有公共_BackingField属性名称的类型。

自动属性：

[Serializable]
public class MyType
{
    public string MyProp { get; set; }
}

编译器会把它变成类似于

的东西

[Serializable]
public class MyType
{
    private string <MyProp>k_BackingField;
    public string MyProp
    {
        [CompilerGenerated]
        get { return this.<MyProp>k_BackingField; }
        [CompilerGenerated]
        set { this.<MyProp>k_BackingField = value; }
    }
}

Answer 2

我假设您要从服务中公开这些第三方类型。

您可以考虑的一个解决方案是维护一个独立的库，该库反映第三方库中的类型。

这有以下好处：

所有权 - 您拥有所公开的类型，因此您可以控制服务边界的序列化/反序列化。
您可以避免突然更改其他方的类型，并可以以受控方式更改您的界面。

从SOA的角度来看，如果您在服务上公开另一方的类型，则另一方应提供类似XSD的合同格式的类型。我认为你的设计需要一些相当不合理的箍跳。

可能会提前做更多工作，但这是一种一次性的练习。

希望这会有所帮助。

Answer 3

您可以使用XmlSerializerFormatAttribute在服务实现中使用XmlSerializer而不是DataContractSerializer。

它会表现得更慢，但它应该可以解决你的问题。

WCF Serializableable实体和__BackingField

3 个答案: