JsonDataContractSerializer and structs

[Tymek]

Hi,

When a struct (not a class) is serialized using
ServiceStack.ServiceModel.Serialization.JsonDataContractSerializer it
is represented by what the struct's ToString() returns.

Surely, this is wrong or I am missing something.

Thanks in advance,
Tymek

[Demis Bellot]

Nope, most ValueTypes are just convenience properties around a single scalar value. 

e.g. DateTime has 13 instance properties that are just convenience properties over a 64bit value, so it's best to only serialize it's value not all of it's properties.

Cheers,

--
- Demis

http://twitter.com/demisbellot

http://www.servicestack.net/mythz_blog

[Tymek Majewski]

Hi,

This is an SS convention, isn't it? 

I can see few points where this approach is, hm...., not right:)

1. As this a dataContract serializer I assumed that it is driven by attributes to know what to serialize, and what not to so it doesn't need to make assumptions about types (expect for built-in simple types and few known special cases like DateTime).

2. This behavior results in a completely different output than what XML serializer generates and I think this is big problem. The fact that the XML serializers (including the one used by SS) cope with complex structs also contradicts your argument. Finally, this different approach makes XML to/from conversion impossible.

3. You mentioned DateTime, but DateTime is serialized to a Json date format, not through DateTime's standard ToString() so it's a special case and cannot be used as an example here.

4. Normally for user defined types ToString returns the name of the type, not its 'value'. The 'value' of a struct may be as complicated as for a class.

5. If ToString is used how do you deserialize a struct which stores more than one value? You would need to have a dedicated member method to this. Does the deserializer expect method called 'Parse'? Also what if ToString is broken or produces an illegal JSON?

What you said makes total sense for what's called simple types in c# and for others (including DateTime) I have to disagree. I have to say I'm really puzzled by this approach to c# structs. 

Cheerio
/Tymek

[Demis Bellot]

It's a SS convention and point of optimization, if you want to control the payload and optimization of a type you can use a Struct.

I don't see how differing from a different serialization format is a concern, i.e. Google protocol buffers serializes types in a completely different way and is likewise not a problem.

Xml serializers have to adhere to the XSD specification and likewise Json serializers have to adhere to the JSON specification which SS.JsonSerializer does.

Other than that my concern is performance and payload size without loss of quality, and the current behavior of structs is an example that.

I used DateTime as a good example of a well known struct that wraps a single scalar value, TimeSpan is another. 

If I was to serialize structs as I do objects TimeSpans would have 11 serialized properties instead of a single human readable and easily parseable string which represents the true value of a TimeSpan.

Developers use structs because they want to pass by value and not have the overhead of creating objects on the heap. As such most of the time structs encapsulate scalar values. Having a complex struct that contains reference types as a typical class does is pointless.

Most structs follow the convention of customizing their ToString() method to return a string that represents the value of the struct and either have a static Parse method to parse that value or a constructor that takes the string.

Any custom structs you want to serialize should do the same, and any BCL classes that don't follow the convention just needs to be special-cased in the serializer to cater for it.

Cheers,

[Tymek]

Hi,

Thanks for the answer.

I disagree mainly because DateTime and TimeSpan (alongside
DateTimeOffset, Guid, Uri, and byte arrays). are special cases as they
are really primitive types (not on a compiler level, but on a
serialization level) and are special cases and should have custom
handling in a serializer.

Looking at it from the opposite perspective it is hard, in my view,
justify the following struct failing serialize->deserialize test.
struct Example {
public int Ticks {get;set;}
}

Anyway, these are just my opinions, thank you for your explanations.

Thanks
Tymek

> > Dnia 01/09/2011 o godz. 20:56 Demis Bellot <demis.bel...@gmail.com>

> > napisał(a):
>
> > Nope, most ValueTypes are just convenience properties around a single
> > scalar value.
>
> > e.g. DateTime has 13 instance properties that are just convenience
> > properties over a 64bit value, so it's best to only serialize it's value not
> > all of it's properties.
>
> > Cheers,
>

> > On Thu, Sep 1, 2011 at 5:04 AM, Tymek < <letssellsomebana...@gmail.com>
> > letssellsomebana...@gmail.com> wrote:
>
> >> Hi,
>
> >> When a struct (not a class) is serialized using
> >> ServiceStack.ServiceModel.Serialization.JsonDataContractSerializer it
> >> is represented by what the struct's ToString() returns.
>
> >> Surely, this is wrong or I am missing something.
>
> >> Thanks in advance,
> >> Tymek
>
> > --
> > - Demis
>

> > <http://twitter.com/demisbellot>http://twitter.com/demisbellot
> > <http://www.servicestack.net/mythz_blog>

[Steve Dunn]

I can see why giving special treatment to BCL types makes sense, but it'd be nice to be able to serialize non BCL structs in the same way as reference types are serialized.

I'm using SS for XNA development.  There are a lot of structs in the XNA framework such as Vector2, Color, Size, Point etc. etc.

Maybe there should be a switch to control whether non-native structs should be serialized.

In fact, I'd just let people serialize what they want.  If they end up with huge payloads, then that's down to them.  It's what they'd get with Newtonsoft and the BCL JSON serializer.

Cheers,

Steve.

[Demis Bellot]

What happens when you ToString() the XNA Framework structs?

Do they not have a constructor which can instantiate themselves from their ToString() output?

[Steve Dunn]

Nothing, you just the qualified name of the type.

To be honest, I don't know many structs in the BCL that can deserialize based on what was written in ToString().