9 Comments

I'm working on a little internal app that involves some AJAX-y callbacks to the server for data. The data is returned in JSON format for easy consumption by the client side code and is being generated with very un-sexy Response.Writes, whose output looks something like this:

{
   "jbloggs" : 
   {
      fullName : "Fred Bloggs",
      title : "Chief Burger Flipper",
      tel : "512"
   },
   "jdoe" : 
   {
      fullName : "Jane Doe",
      title : "Assistant Burger Flipper",
      tel : "587"
   },
   ...
}

This works nicely as a information can be looked up on the client in JavaScript like so:

var person = peopleJson["jbloggs"];
alert(person.fullName);

Dead easy. JavaScript objects are just dictionaries/hash tables.

Now I was aware that Windows Communication Foundation (WCF) services can now do JSON serialization in .NET 3.5, so I thought I'd swap out my low-tech Response.Writes for a WCF Service that would let me come up with structures in my server-side code that would be serialized automatically to JSON. But I found that the the way WCF (which ultimately uses DataContractJsonSerializer) serializes Dictionaries is a bit lame. This is what it came up with:

[
   {
      "Key":"jbloggs",
      "Value":
      {
         fullName : "Joe Bloggs",
         title : "Chief Burger Flipper",
         tel : "512"
      }
   },
   {
      "Key":"jdoe",
      "Value":
      {
         fullName : "John Doe",
         title : "Assistant Burger Flipper",
         tel : "587"
      }
   },
   ...
]

Odd. Dictionaries are serialised as arrays of objects whose members consist of a Key and Value. So in order to look up an entry I'd have to do a linear search through this array. I mean, you would have thought the fact there is dictionary functionality built-in to the JavaScript Object prototype (in fact, fundamental to JavaScript) - that it would be the sensible format to use rather than the Key/Value format. I just can't quite see why Microsoft thought that this Key/Value format was necessary as it's such a pain to consume on the client.

Looks like my low-tech Response.Writes are going to get a stay of execution for the time being.