Serialization of Object type without modifying C# class generated out of schema

2,189 views
Skip to first unread message

Shail

unread,
Jul 31, 2012, 9:14:24 AM7/31/12
to prot...@googlegroups.com
Hi,
 I have an existing C# class which is generated out of XML schema, it contains the object type. I need to serialize same  using protocol buffer, without modifying the class, I am having issue in serialization of the object datatype present in the class as mentioned below:
  public class Param
    {

        /// <remarks/>
        [System.Xml.Serialization.XmlElementAttribute("FloatData", typeof(FloatData))]
        [System.Xml.Serialization.XmlElementAttribute("StringData", typeof(StringData))]
        [System.Xml.Serialization.XmlElementAttribute("IntData", typeof(IntData))]
        [System.Xml.Serialization.XmlElementAttribute("Int64Data", typeof(Int64Data))]
        [System.Xml.Serialization.XmlElementAttribute("CompositeData", typeof(CompositeData))]
        public object Item;
        .....
        ....
   }
Is there a way to do this without modifying existing class? 

Thanks and Regards
Shailendra

Marc Gravell

unread,
Aug 1, 2012, 2:21:01 AM8/1/12
to Shail, prot...@googlegroups.com
And in this model, what is FloatData, StringData, IntData, etc?

This is certainly solvable with protobuf-net, but to do a complete example I'd need to see those additional types.

Marc
(protobuf-net)


On 31 July 2012 14:14, Shail <shailend...@gmail.com> wrote:
  public class Param
    {

        /// <remarks/>
        [System.Xml.Serialization.XmlElementAttribute("FloatData", typeof(FloatData))]
        [System.Xml.Serialization.XmlElementAttribute("StringData", typeof(StringData))]
        [System.Xml.Serialization.XmlElementAttribute("IntData", typeof(IntData))]
        [System.Xml.Serialization.XmlElementAttribute("Int64Data", typeof(Int64Data))]
        [System.Xml.Serialization.XmlElementAttribute("CompositeData", typeof(CompositeData))]
        public object Item;
        .....
        ....
   }



--
Regards,

Marc

Shail

unread,
Aug 1, 2012, 2:52:52 AM8/1/12
to prot...@googlegroups.com
Hi Marc,
Here FloatData, StringData,IntData,Int64Data,CompositeData are custom classes like below is the defination of FloatData class:

    public class FloatData
    {

        /// <remarks/>
        [System.Xml.Serialization.XmlArrayItemAttribute("item", IsNullable = false)]
        public float[] Ranges;

        /// <remarks/>
        [System.Xml.Serialization.XmlAttributeAttribute()]
        public System.Single AdjustValue;


        /// <remarks/>
        [System.Xml.Serialization.XmlAttributeAttribute()]
        public System.Single[] Values;
    }

Regards
Shailendra

Marc Gravell

unread,
Aug 1, 2012, 3:28:26 AM8/1/12
to Shail, prot...@googlegroups.com
Firstly, I must emphasise that everything here relates to protobuf-net, not to the more general "protobuf" implementations.

Yes, that is doable, via a combination of configuration at runtime, and a "surrogate".

Firstly: what is a "surrogate" here: well, the layout of Param, with "object" etc, is not very protobuf-net friendly, so protobuf-net allows you to write a separate, more-suitable-for-serialization type, and flip between them at will. To do this, protobuf-net uses the .NET conversion operators (implicit or explicit), for example:

        [ProtoContract]
        public class ParamSurrogate
        {
            [ProtoMember(1)]
            public FloatData FloatData { get; set; }
            // TODO: other types here

            public static implicit operator ParamSurrogate(Param value)
            {
                if (value == null) return null;
                var surrogate = new ParamSurrogate();
                if(value.Item != null)
                {
                    surrogate.FloatData = value.Item as FloatData; // will be null if not this
                    // TODO: other types here
                }
                return surrogate;
            }
            public static implicit  operator Param(ParamSurrogate value)
            {
                if (value == null) return null;
                var param = new Param();
                if (value.FloatData != null) param.Item = value.FloatData;
                // TODO: other types here
                return param;
            }
        }

Note that for convenience I'm using attributes to describe the protobuf-net options for the surrogate, but that could also be avoided if necessary. Note that we also need to tell protobuf-net to *use* that surrogate whenever it sees a Param, which can be done via:

            // configure model (do once at app startup)
            var model = RuntimeTypeModel.Default;
            model.Add(typeof(Param), false).SetSurrogate(typeof(ParamSurrogate));

Now, the FloatData is not actually too problematic - simple values are arrays are fine. All we need to do is tell it about the members we want to serialize, and which keys to use. This is as simple as (continuing that initial configuration):

            model.Add(typeof (FloatData), false).Add("Ranges", "AdjustValue", "Values");
            //TODO: other types here

which gives the 3 members the keys 1, 2, 3 respectively.

We can test this:

            // test data
            var param = new Param
            {
                Item = new FloatData
                {
                    AdjustValue = 123.45F,
                    Ranges = new float[] { 1.0F, 2.4F },
                    Values = new float[] { 7.21F, 19.2F }
                }
            };
            // note the fallowing is the same as Serializer.DeepClone, since
            // model === RuntimeTypeModel.Default
            var clone = (Param) model.DeepClone(param);
            Assert.AreNotSame(clone, param, "Different instance");
            Assert.IsInstanceOfType(typeof(FloatData), clone.Item, "Data type");
            var data = (FloatData) clone.Item;
            Assert.AreEqual(123.45F, data.AdjustValue);
            Assert.AreEqual(2, data.Ranges.Length);
            Assert.AreEqual(1.0F, data.Ranges[0]);
            Assert.AreEqual(2.4F, data.Ranges[1]);
            Assert.AreEqual(2, data.Values.Length);
            Assert.AreEqual(7.21F, data.Values[0]);
            Assert.AreEqual(19.2F, data.Values[1]);

Which all works fine, demonstrating that we have serialized and deserialized the data correctly.

Marc



--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/g3dGIhKUYkoJ.

To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.



--
Regards,

Marc

Shail

unread,
Aug 2, 2012, 12:06:22 AM8/2/12
to prot...@googlegroups.com, Shail
Thanks Marc for Solution as well as detail explanation with test code. I really appreciate your support and effort.

But in my context, as I mentioned above "Param" class is auto generated.So if I write  ParamSurrogate , I need to rewrite this class whenever schema is modified which I prefer to avoid.

Just wanted to know, like XML custom serialization,Is it feasible to write custom serialization for ProtoBuffer? 


Regards
Shailendra
To unsubscribe from this group, send email to protobuf+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.



--
Regards,

Marc

Marc Gravell

unread,
Aug 2, 2012, 2:42:03 AM8/2/12
to Shail, prot...@googlegroups.com
I need to rewrite this class whenever schema is modified which I prefer to avoid.

And if I provided a custom serialization API, you'd need to maintain that when your schema changes, with the additional overhead that you'd have to worry about some protobuf knowledge too. Or (perhaps more likely) I'd need to spend quite some time devising a custom serializer API that is usable without needing to know too much about the actual wire spec.

Another way of looking it is: your DTO model changes will probably be relatively uncommon and pretty simple additions of new members (otherwise you have other problems); the maintenance to add support for an extra member should be minimal.

tl;dr; a custom serialization API is something I can look at at some point, but it is not at the top of my list. And I'm still not convinced it is desirable or advantageous, so looking at it isn't a guarantee of implementing it.

Marc

To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/CfwLilmgOtUJ.

To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.



--
Regards,

Marc
Reply all
Reply to author
Forward
0 new messages