| One thing that's a bit unclear to me about properties, as described in this article, is how they should behave with respect to serialization. For instance, in C#, both System.Text.Json and Newtonsoft.Json will get and serialize all properties, regardless of whether they are virtual "projections" (like the "red" property in the article's RgbColor example) or "plain" properties. Similarly, all properties are deserialized and set when doing the reverse. This has the consequence that you may have redundant information in your serialization format. That's not the end of the world, and in fact there are some use-cases for this. The bigger consequence is that you can have redundant and conflicting information in the serialized data you read in. For instance, adapting the author's example to C#: https://try.dot.net/?fromGist=1bb01bd2b78a3212c52b40ff7955c0... You get a different deserialization result depending on the order of the properties in the JSON, because the last property wins and the properties are mutually inconsistent with respect to the underlying data model. Is the conclusion from this that objects which you intend to serialize should avoid using this "properties" feature, or else be extremely deliberate about what properties to include in the serialization format? |
The intended behavior is to serialize all fields of an object (some properties have backing fields, others don't). You wouldn't serialize properties themselves for the same reason a getter/setter on it's own wouldn't be serialized - only the data stored.
Put simply, I would say C# has the wrong default behavior here.