我们正在使用protobuf-net(并且喜欢它!)。我们现在有一个从父类基础派生的protocontract装饰的子类,它不是protocontract装饰的。
我们正在尝试让子类序列化/反序列化一些父类的字段。
public abstract class TableServiceEntity
{
public virtual string PartitionKey { get; set; }
public virtual string RowKey { get; set; }
public DateTime Timestamp { get; set; }
}
[ProtoContract]
public class IndicatorStreamIndex : TableServiceEntity
{
// protomember properties
}
我们如何让IndicatorStreamIndex序列化/反序列化PartitionKey,RowKey和Timestamp?
最佳, 麦克
答案 0 :(得分:2)
这可以在v2中轻松配置,使用RuntimeTypeModel
在运行时调整配置:
// this should only be done once per AppDomain, usually at app startup
RuntimeTypeModel.Default.Add(typeof (IndicatorStreamIndex), true)
.Add("PartitionKey", "RowKey", "Timestamp");
// then when needed:
var obj = new IndicatorStreamIndex
{
RowKey = "abc",
PartitionKey = "def",
Timestamp = DateTime.Today
};
var clone = Serializer.DeepClone(obj);
Console.WriteLine(clone.RowKey); // "abc"
Console.WriteLine(clone.PartitionKey); // "def"
Console.WriteLine(clone.Timestamp); // 13/02/2012
答案 1 :(得分:2)
首先 - 我认为你有技术基础来开发出优秀的序列化器。也就是说,我发现ProtoBuf序列化的各个方面都是不切实际的,以至于我无法看到自己在当前状态下使用它。
让我符合资格 - 首先,明确需要在类上使用ProtoBuf属性来序列化强制ProtoBuf部署依赖项;序列化背后的基本思想之一是,可以使用相同的类,并在需要时刷出序列化程序 - 这意味着不同部署可能不需要属性和dll。
第二关 - 使用ProtoBuf默认情况下不会递归继承树使其更具特异性 - 这意味着代码更加混乱,更具体的代码依赖性等等。在我看来这是一个非常明显的缺陷,就像一个派生出来的B一样从A开始,人们自然希望在序列化B时包含A的属性 - 没有上面线程中所示的自定义代码。
第三 - 想象自己不需要属性......然后你也可以想象自己从对象中序列化,例如object []参数 - ProtoBuf目前无法做到的。我想(自己不是序列化专家),它可能就像将类和程序集作为序列化对象的一部分来远程解析它一样简单 - 请记住,同一个库也必须驻留在那里。换句话说,能够序列化任何类型/类型层次结构,没有显式属性,基于假设远程机器上存在相同类型的名称和汇编。
马克,祝你好好实施。Gawie