One-Way Serialization
Has anyone found a good pattern for serialization without deserialization?
In my previous post about mixing serialization, I mentioned that we’d implemented the IXmlSerializable interface in many of our classes. The main reason for doing this was to include elements and attributes that were read-only.
In other words, we wanted additional information to appear in the serialized stream. This additional information is not needed in order to rehydrate the object.
Why would you want to do that?
Most serialization frameworks don’t handle this case. After all, if the point of serialization is to transport an object across the wire, cluttering up the stream with extra information is wasteful. Besides, you can’t dictate what someone on the other side might do with the data. Nicholas Allen discusses this point in his post explaining why read-only data members are not supported in WCF.
While I understand his point from an object remoting perspective, the reason for choosing XML as a data format in the first place was to allow for human readability. What if you want to embed metadata in your XML that doesn’t affect the behavior of the object? You’d need to include it in the XML output, but you aren’t interested reading it back in from an XML stream. What’s the best way to achieve this?
For example, in our data layer we have a Version object that brings together information about when the object was created and by whom, when it was modified and by whom, as well as the object’s revision number. It’s useful to have this information in resulting XML string, but we don’t need to read it back in.
So here’s my question: Are we doing this wrong? Does the need for one-way serialization indicate a problem with our object model? Is it a code smell, or is it simply an edge case not considered by existing frameworks?
Related Posts
- Don’t Mix Your Serialization
- Validation in Domain Driven Design
- Using WCF for REST, Part 2
- Enums are Ints that Ain’t
