0

I need to serialize an object into a form that can be easily transported. Transportation across an object boundary will then occur, where the object must be a string. After transportation across an application boundary I will deserialize the object and then do some work with it.

My object will have a number of simple public properties, and a collection.

I need to work within the boundaries of the .Net framework due to a sandboxed environment, i.e. no use of Json.Net or other third party libraries.

It seems .Net offer a number of options for this type of work, I am trying to understand which I should be using.

Binary Serialization (BinaryFormatter & SoapFormatter)

These seems pretty straightforward, all I have to do is mark my classes as [Seralizable] and use appropriate classes to create the stream. I then need to convert the stream into a string which would seem straight forward. The SoapFormatter has the bonus of creating some data which is reasonably human readable.

XML Serialization (XmlSerializer)

For this I don't need to decorate my classes, however I should consider using Sgen.exe to improve performance (which sounds like a pain). It has the added bonus over Binary Serialization in that the data is human readable.

Data Contract Serializer (DataContractSerializer & DataContractJsonSerializer)

Part of WCF, for this I should decorate my classes (but I can get away without it), i.e. [DataContract] and [DataMember]. The additional decoration is a pain, but I do end up with some human readable data. Also I have the option for Json formatted data, but they are fundamentally the same process.

So in terms of picking between them all:

  • The MSDN suggests the default position is DataContractSerializer over XmlSerializer (apart from in some situations). Whilst I have to decorate my classes this avoids the need to use Sgen.exe.
  • I'm not really sure how to pick between DataContractSerializer and BinaryFormatter.
  • Performance wise they all seem pretty similar, if slower than other non .Net options.

At the moment I'm steering towards Binary Serialization for simplicity, but is there anything else I should consider?

Community
  • 1
  • 1
James Wood
  • 17,286
  • 4
  • 46
  • 89
  • You can use the Javascript Serializer from System.Web – Sreenath Jun 28 '16 at 14:54
  • 2
    `BinaryFormatter` is known to be version change intolerant, if you change the schema of a class in the serialization graph the entire graph may fail to desearalize unless you do a lot of extra work. – Scott Chamberlain Jun 28 '16 at 14:54
  • 2
    `DataContractSerializer` actually can serialize types without `[DataContract] and [DataMember]` - all you need is parameter-less constructor (only public members will be serialized) – Aleksey L. Jun 28 '16 at 14:55
  • I would follow MSN's suggestion and use `DataContractSerializer,` *and* go ahead and put in those decorations. This will *annotate,* so to speak, the data-stream that gets sent, and it will also help to verify that incoming data streams are conformant to your app's expectations, automagically raising a stink if they aren't. "Always think ahead to *debugging."* And, if any client can (unintentionally, perhaps ...) send bogus-data to you, one day they will, and *you* will be the one to debug it! – Mike Robinson Jun 28 '16 at 15:04
  • 1
    Follow-up: I *do* specifically suggest that you should use one of the Microsoft-provided options, and not waste time "rolling your own [JSON]" and so forth. Furthermore, don't be particularly worried about "performance," unless you really have to. *Reliability* is far more important. – Mike Robinson Jun 28 '16 at 15:06
  • 2
    Technically you don't need to attribute decorate when using `DataContractSerializer`, it is smart enough to still work. You may find it meets your needs since you are not actually doing WCF. – Crowcoder Jun 28 '16 at 15:07
  • It depends on where do you want to transport it. Through the web (REST) then use JSON or XML. Binary would be hard to transport, because you must convert it first to Base64. –  Jun 28 '16 at 15:20
  • Datacontractserializer is fussy when deserializing - if members are out of order they will be silently skipped. – Ben Jun 28 '16 at 15:26

0 Answers0