CODEWITHSUNDEEP
c#inheritanceprotocol-buffersprotobuf-net
Nick Novotny
Nick Novotny

Reputation: 95

protobuf-net inheritance from child to parent

I have a parent class that I want to have many flat children. That means 10 or more different classes would inherent from one class.

Here is what I have.

Base Class:

[ProtoContract]
[ProtoInclude(500, typeof(Message1Send))]
[ProtoInclude(501, typeof(Message2Send))]
public class MessageBase
{
    [ProtoMember(1)]
    public string Topic {get;set;}
    [ProtoMember(2)]
    public string Action { get; set; }       
}

2 of many Child Classes:

[ProtoContract]    
public class Message1Send : MessageBase
{        
    [ProtoMember(1)]
    public string Property1 { get; set; }
}

[ProtoContract]    
public class Message2Send : MessageBase
{        
    [ProtoMember(1)]
    public string Property1 { get; set; }
}

I want to be able to tell the child object I am part of a base class.

I don’t what to get to the point where my base class is as follows:

[ProtoContract]
[ProtoInclude(500, typeof(Message1Send))]
[ProtoInclude(501, typeof(Message2Send))]
[ProtoInclude(502, typeof(Message3Send))]
[ProtoInclude(503, typeof(Message4Send))]
[ProtoInclude(504, typeof(Message5Send))]
[ProtoInclude(505, typeof(Message6Send))]
[ProtoInclude(506, typeof(Message7Send))]
[ProtoInclude(507, typeof(Message8Send))]
[ProtoInclude(508, typeof(Message9Send))]
[ProtoInclude(509, typeof(Message10Send))]
public class MessageBase
{
    [ProtoMember(1)]
    public string Topic {get;set;}
    [ProtoMember(2)]
    public string Action { get; set; }       
}

Is there a way I can have each one of the Send classes to just add one reference to the base class so I don’t have to keep adding ProtoInclude for every flat child I create?

Upvotes: 5

Views: 855

Answers (1)

Marc Gravell
Marc Gravell

Reputation: 1062600

The problem is one of reliability. Reflection makes veryfew repeatable / reliable guarantees, and it is very important that if you serialize data today, then edit your app to add two new types, each type still has the same number as it did oroginally. Even if you've added some new types, renamed some, and possibly removed two that you weren't really using.

The attribute guarantees this by making the field-number repeatable. The reason it is on the parent (not the child) is that it is much more reliable to walk up the type-chain than down it.

However: if you have a reliable repeatable way of generating field numbers for sub-types, you can use RuntimeTypeModel to configure the serializer to your liking.

Upvotes: 3

Related Questions