Deployment Zone

I guess the title is a little misleading because there is seldom any fun to be had with the .NET Framework.

But if you've got a Linq to SQL *.dbml and the tool is generating those swell ExtensionDataObject properties preventing you from easily serializing your model classes to JSON and you don't want to make shadow classes (::gasp:: yes I know the .NET Fx loves ceremony, I however do not) then you can use a custom JavaScriptConverter to ignore those properties. When you have control of a class you can put a NonSerialized attribute on properties but that becomes substantially more difficult when a tool is responsible for generating the class file and cheerfully overwrites any changes you may make if you even open the file to glance at its contents. Yes shitty *.dbml tool in Visual Studio, I'm looking at you.

So let's say you have this simple helper class:

// JsonSerializationUtility.cs
public static class JsonSerializationUtility
{
	public static string ToJson(this object obj, string wrapper = null)
	{
		var json = new JavaScriptSerializer().Serialize(obj);
		if (!string.IsNullOrEmpty(wrapper))
			json = "{ \"" + wrapper + "\": " + json + " }";

		return json;
	}

	public static T Deserialize<T>(string json)
	{
		var jss = new JavaScriptSerializer();
		jss.RegisterConverters(new [] { new ExtensionDataObjectConverter() });
		var result = jss.Deserialize<T>(json);
		return result;
	}
}

... then you'll need this handy ExtensionDataObjectConverter class!

// ExtensionDataObjectConverter.cs
public class ExtensionDataObjectConverter : JavaScriptConverter
{
	public override IEnumerable<Type> SupportedTypes
	{
		get
		{
			return new ReadOnlyCollection<Type>(new [] { typeof(ExtensionDataObject) });
		}
	}

	public override IDictionary<string, object> Serialize(object obj, JavaScriptSerializer serializer)
	{
		return null;
	}

	public override object Deserialize(IDictionary<string, object> dictionary, Type type, JavaScriptSerializer serializer)
	{
		return null;
	}
}