1

I'm in charge of a comprehensive serialization format with support to serialize runtime objects (any derived type of Object). I can't find a sane scenario where one would choose to serialize an instance of System.Object immediately. In my purview, Object is undefinitive, and belongs in a binary format, not in a human-readable text.

With the introduction of Generics, instances of type Object should no longer identify data. Any insights to get me over the edge? For consideration, note that both Data Contracts and JSON.NET support serialization of System.Object.

Improve this question
1
  • Generics don't erase types; they merely defer their selection.
    – Robert Harvey
    Apr 13, 2015 at 14:11

1 Answer 1

Reset to default
4

In my purview, Object is undefinitive, and belongs in a binary format, not in a human-readable text.

I don't see the relationship between these two things; there are plenty of good reasons to choose text versus binary: this is not one of them. How it appears is an implementation detail only.

any derived type of Object

The biggest challenge, then, is deciding how you are going to encode the type data. In many serializers, the answer is simply: you don't. This avoids an entire family of problems with refactoring and version (renaming types, assembly-names, etc). You could limit yourself to [Serializable] types, but by the time you've done that you might as well just use the (terrible, IMO) BinaryFormatter. Of course, some key questions here might be: why do you want to write your own serializer? What is the feature(s) you are after that aren't satisfied by the existing platform tools and 3rd-party / open-source tools?

Then you have a range of protocol / formatting considerations; mapping serialized data back into types is ... non-trivial. If the type is going to require configuration (think: [XmlElement(...)] etc), you could reasonably limit yourself to types that have the basic configuration evidence. This is kinda what DataContractSerializer does, except it falls back into a more basic field-level serializer if that configuration data is missing.

I'm also a big advocate for the view that entity models make lousy serialization types, so it is quite reasonable to expect there to exist a DTO model that broadly reflects your serialization needs; and if that is the case, it is not unreasonable to expect that the DTO type might be annotated in some way (or at least advertised to the serializer in some way - perhaps at runtime if attributes aren't an option).

Improve this answer
13
  • The difference that I recognize is; human-readable text is determined to presentation while binary formats are typically determined to accuracy, because all complexities can be afforded. The problem is: Why would a type designed for serialization contain indefinite members? Sure there is IList, but I'd rather qualify such class as obsolete.
    – toplel32
    Apr 13, 2015 at 12:35
  • @toplel32 I disagree with your description; SOAP isn't intended to be presented; XML is barely human readable in most cases. Json is more readable, but I'd say that even that says nothing about the intent.
    – Marc Gravell
    Apr 13, 2015 at 13:34
  • @toplel32 your comment on IList is very valid; but it gets more complicated; what patterns do you want to support? Not everything is IList<T>. It could be IEnumerable<T> with a good-looking Add. It could even not be IEnumerable<T> but have a custom GetEnumerator() type that is strongly typed. Lots of very awkward questions. Then there's dictionaries, etc. Again: why do you want to write your own? What is the feature you want to add that isn't already available?
    – Marc Gravell
    Apr 13, 2015 at 13:35
  • Why is BinaryFormatter terrible? Is it slow? Is it brittle? Is Protocol Buffers better?
    – Robert Harvey
    Apr 13, 2015 at 14:10
  • 1
    @RobertHarvey it is incredibly brittle re refactoring and versioning, and unless you do all the work yourself (ISerializable etc) it is brittle towards internal field changes; it isn't cross-platform, and has a nasty habit of sucking in events and serializing unexpected objects. I've seen lots of people get into messes where they can't deserialize their data back via BinaryFormatter, so yes: it has some issues. protobuf-net deliberately avoids the worst of these problems; although to be fair: all serializers have scenarios they are strong at / weak at.
    – Marc Gravell
    Apr 13, 2015 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.