1

Closed

Add support for ISupportInitialize interface

description

So that deserialization calls BeginInit right after constructing the object and before deserializing properties, and EndInit when it's done.
 
This would allow validation for example of the deserialized values.
Closed Apr 24 at 11:13 PM by JamesNK
Closing as I still don't want this and there is no demand. Also ISupportInitialize isn't in WinRT so won't be available in many versions of Json.NET which I'm trying to get away from.

comments

JamesNK wrote Aug 1, 2011 at 5:09 PM

Use serialization callbacks - http://james.newtonking.com/projects/json/help/SerializationCallbacks.html



** Closed by JamesNK 8/1/2011 5:57 AM

dcazzulino wrote Aug 1, 2011 at 5:09 PM

That would imply it has to be done in a base class for all such objects (with the upcoming new support for inherited deserialization callbacks, so not really an option right now).

If there was a way to do this JsonSerializer-wide (via a few new JsonSerializerSettings Func-style callbacks), that would be fine. But without it, implementing this either in every object or in a base class, is far from ideal.

JamesNK wrote Aug 1, 2011 at 11:15 PM

Pardon? What exactly will ISupportInitialize add that deserialization callbacks won't? (after inheritance has been added next release).

dcazzulino wrote Aug 2, 2011 at 3:07 AM

I can have a POCO that implements ISupportInitialize and NOTHING MORE, and have a deterministic initialization for my object. In IoC containers I have hooks external to the object (i.e. OnActivating/OnActivated kind of stuff at the container level) where I can perform this cross-cutting invocation on all objects owned by the container that implement this interface.

The serialization callbacks, on the other hand, are a resposibility of the object itself. They cannot be added as a cross-cutting behavior a-la JsonSerializerSettings which can even do it for the constructor but not for the callbacks. Hence, the callbacks need to be implemented in EACH AND EVERY object, or in a base class (bye POCOs).

It would be great if such a cross-cutting behavior could be implemented the same way you have exposed the DefaultCreator as a Func on JsonSerializerSettings, as that would allow injecting the behavior from outside the entities, which can remain ignorant of the context in which they will be initialized (an IoC container, Json.NET deserialization, whatever).

I've proposed the same behavior (invoking BeginInit/EndInit before/after setting properties in object initializer syntax) in a C# vNext compiler and Mads Torgersen, C# Language PM, liked the idea too (http://kzu.to/nEz3oC) and it has quickly become the second most voted suggestion in the VS Uservoice forum (http://kzu.to/rpOYNs).

Would be good to have consistency throughout: consistent and deterministic initialization for properties, regardless of class usage context.

BTW, thanks a bunch for the promptly responses! I love Json.NET :)

Sign in to add a comment