JSON serialization problems and solution in MVC3

For various reasons you may find that the default JsonResult returned by invoking the controller method such as

return Json(data);

Is unsuitable for the consumer. The main issue most often encountered is that this method uses the JsonResult which in turn uses the JavaScriptSerializer with no access to the JavaScriptTypeResolver.

This means that you can provide that serializer a parameter specifying you own custom type resolver.

Other issues, such as maximum recursion depth and maximum length and type resolvers can be simply configured in web.config. See Configuring JSON Serialization section on MSDN.

Back to the core problem though.

To override the JsonResult, we would need to do 2 things:

1. Create our own custom JsonResult implementation
2. Tell the controller to use ours rather than the stock one.

A new JsonResult is needed because the base one hard codes the construction of the JavaScriptSerializer.

So here we go. Some CTRL+C, CTRL+V later from the open source MVC on Codeplex gives us

public class TypedJsonResult : JsonResult
{
    public override void ExecuteResult(ControllerContext context)
    {
        if (context == null)
        {
            throw new ArgumentNullException("context");
        }
        if ((JsonRequestBehavior == JsonRequestBehavior.DenyGet)
            && string.Equals(context.HttpContext.Request.HttpMethod, "GET", StringComparison.OrdinalIgnoreCase))
        {
            throw new InvalidOperationException("JsonRequest GetNotAllowed");
        }
        var response = context.HttpContext.Response;
        response.ContentType = !string.IsNullOrEmpty(ContentType) ? ContentType : "application/json";
        if (ContentEncoding != null)
        {
            response.ContentEncoding = ContentEncoding;
        }
        if (Data != null)
        {
            var serializer = new JavaScriptSerializer(new BiasedTypeResolver());
            response.Write(serializer.Serialize(Data));
        }
    }
}

You will note that we’re still using the JavaScriptSerializer, but this time we’re controlling its construction and decided to give it our own type resolver. More on that type resolver in a bit.

Next, we want to our controller(s) an easy way to choose our TypedJsonResult rather than the stock one. Luckily, the controller boils down the call Json(data) and several other signatures to a call to a virtual signature which we may simply override, like so:

protected override  JsonResult Json(object data, string contentType, Encoding contentEncoding, JsonRequestBehavior behavior)
{
    return new TypedJsonResult { Data = data, ContentType = contentType, ContentEncoding = contentEncoding, JsonRequestBehavior = behavior };
}

That’s it! On line 3 you will notice we return our custom Typed JsonResult, whereas the stock implementation would have returned the JsonResult.

If this new behavior is desired everywhere, then you would probably want to place this override in a base controller of your own, and have all your controllers inherit it.

Other powers this bestows on you is of course using some other serializer altogether, such as Json.NET or whatever you fancy.

Now back to my own type resolver. You could, after all, use the SimpleTypeResolver built into the framework, which works quite well. However, it introduces fairly long type names – frowned upon by my clients consuming this Json on other platforms, and also doesn’t enable me to map my own type names to a type of my choice. Enter the BiasedTypeResolver.

private static readonly Dictionary<string, Type> _KnownTypes;
static BiasedTypeResolver()
{
    _KnownTypes = new Dictionary<string, Type> ();
    var appDomain = AppDomain.CurrentDomain;
    foreach (var assembly in appDomain.GetAssemblies().Where(a => a.GetName().Name.EndsWith(".ValueObjects")))
    {
        foreach (var type in assembly.GetTypes().Where(t => !t.IsInterface && !t.IsAbstract))
        {
         _KnownTypes[type.Name] = type;
        }
    }
}

public override Type ResolveType(string id)
{
     var result = Type.GetType(id);
     if (result != null || _KnownTypes.TryGetValue(id, out result))
     {
         return result;
     }
     throw new ArgumentException("Unable to resolve [" + id + "]", "id");
}

public override string ResolveTypeId(Type type)
{
    if (type == null)
    {
        throw new ArgumentNullException("type");
    }
    return type.Name;
}

This resolver spelunks specific assemblies only (those named [whatever].ValueObjects which are my naming convention for POCO public objects) and catalogs them into a dictionary by short type name.

It doesn’t know how to resolve 2 types of the same name if they only differ by namespace, but then again I’d ask “how come you would define 2 classes of the same exact name in your solution?” You can define type names to whatever suites your needs.

The resolver’s responsibility is twofold: Given a string , return the System.Type that corresponds to it. Given a type, return a name for it. The former is used during deserialization, the latter when serializing.

Now you may not need or like this particular type resolver implementation. But now that you can inject your own, possibilities are limitless. These can range to configuration based type resolution, versioning decisions base on some revision upgrades etc.

Note also that upon deserialization, the type resolver is only called when a type discriminator exists in the JSON stream. That is, a complex type that doesn’t contain “__type”:”foo” will be serialized by the JavaScriptSerializer by matching the target member name rather than the resolver. This is nice because the JSON can contain strategically placed type discriminators for polymorphic reasons on some members, but be left terse and bare otherwise.

Hopefully, this helps you, or me-of-the-future when the gray cells got filled with the next great thing..

Happy Coding!