This project has moved and is read-only. For the latest updates, please go here.

Initial Thoughts / Gripes

Jun 20, 2010 at 9:39 PM
Edited Jun 20, 2010 at 11:39 PM

I set about using JSON.Net as a nicer (and easier to implement) replacement for XmlSerializer today, particularly comparing it with another custom .Net serialization framework, "SharpSerializer". 

First off, let me note this: JSON.Net is much more powerful, customizable, and versatile. On the other hand, it took me longer to get going because of some of the efficiency tradeoffs applied on default settings and the somewhat cryptic error messages encountered:

  1. Recursive References: There's really good ways of dealing with these in the framework, either using "ReferenceLoopHandling.Ignore" if you know there's no problem or "PreserveReferencesHandling". Neither of these options are mentioned in the error, however, making the casual user think they are going to have to go and manually add "JsonIgnore" entries all over the place and figure out for therselves how to restore consistency later.
  2. Whenever you're using Abstract classes or Interfaces JSON.Net can figure things out really well when you specify appropriate "TypeNameHandling" instructions - but if you don't know that, the error message you get when the type is not available makes you want to cry! (as in, oh no, I did all this and it's not going to work!) Again, a hint in the error description would be great. EXTRA CREDIT: An "Auto" option would really make sense here - include the type info if the object is not of the expected type (because it is a subclass, or because the member type is an interface), and otherwise omit it.
  3. JSON.Net provides a handy "ObjectCreationHandling" attribute, which can fix issues like an IList<> property which actually returns an Array - the default behaviour (Reuse or Auto?) will try to add elements to the existing Array and will therefore fail; but again, discovering what is going on in this situation is a pain, and the documentation does not (as far as I can see) explain what the tradeoff between "Reuse" and "Replace" might actually be...
  4. Multi-dimensional arrays: yes, yes, use jagged arrays... but why?? Multi-dimensional arrays are not complicated! you can serialize them in any number of ways, why not add support for it? "SharpSerializer" does it for Xml, for example, and it's sweet - just works. I don't understand why neither XmlSerializer not JSON.Net support multidimensional arrays - they ARE sometimes the right choice!

Alright, done with my rant. Thanks for the brilliant library, I'm going to go get some coding done now.



Jun 21, 2010 at 1:01 AM

Improving error messages by including a possible solution is a good idea. I'll look at doing that.

Serializing multi-dimensional arrays is easy but deserializing them is a real pain. I don't want one without the other and there is always the perfectly acceptable alternative: jagged arrays.