2

我们有以下类和 WCF 服务（使用 protobuf-net 进行序列化）：

[DataContract]
[KnownType(typeof(NamedViewModel))]
public class NamedViewModel<TKey> : IViewModel
{
    [DataMember]
    public virtual TKey Id { get; set; }

    [DataMember]
    public virtual string Name { get; set; }
}

[DataContract]
[KnownType(typeof(ScheduleTemplateViewModel))]
public class NamedViewModel : NamedViewModel<int>
{
}

[DataContract]
public class ScheduleTemplateViewModel : NamedViewModel
{
    [DataMember]
    public string Comment { get; set; }
}

[DataContract]
public class Container
{
    [DataMember]
    public IEnumerable<ScheduleTemplateViewModel> Templates { get; set; }
}

[ServiceContract]
public interface IService
{
    [OperationContract]
    Container Get();
}

public class Service : IService
{
    public IEnumerable<Container> Get()
    {
        return new Container { Templates = Enumerable.Range(1, 10)
            .Select(i => CreateTemplate()).ToArray() };
    }

    private void ScheduleTemplateViewModel CreateTemplate()
    { 
        var instance = WindsorContainer.Resolve<ScheduleTemplateViewModel>();
        // populate instance
        return instance;
    }
}

我们有两个问题：

  1. 我们在序列化过程中遇到异常，即 ScheduleTemplateViewModel 的 Castle DynamicProxy 类型是意外的。我们注意到 protobuf-net 中有自定义代码来处理 NHibernate 和 EntityFramework 代理......但不是 Castle DynamicProxies。我们通过在 protobuf-net 源代码中添加一个额外的 case 语句来检查 Castle 的 IProxyTargetAccessor 类型来解决这个问题......但是如果有一种方法可以在不修改 protobuf-net 源代码的情况下处理这个问题......

  2. ScheduleTemplateViewModel 上的成员（即评论）被正确序列化......但基类成员不是。我们已经在 RuntimeTypeModel.Default 上将 InferTagFromNameDefault 设置为 true。

4

1 回答 1

1

  1. 我可以补充一下；你能告诉我那个接口的全名（包括命名空间）吗？

  2. 从您给出的示例中，这些值都不应该序列化，因为它们都不包含必要的数字字段编号信息。既然你说有些人会序列化，我会假设这是复制/粘贴中的一个遗漏。如果没有更好的可用信息， Protobuf-net 将尝试使用Order=n来自的信息。[DataMember(...)]但是，如果必须强调 protobuf-net 不能使用[KnownType(...)]，并且继承又需要一些显式的数字字段编号信息。这最容易通过 添加[ProtoInclude(...)]，但也可以在运行时提供

于 2013-03-04T06:40:02.760 回答