Does JsonSerializer.Deserialize<JsonNode>(...) cause lazy parse?

[GF-Huang]

The docs of JsonSerializer seems not detail how it works. Consider the follow:

namespace MyLibrary {
    public class Model {
        public int Number => _node[nameof(Number)].GetValue<int>();    

        private readonly JsonNode _node;

        internal Model(JsonNode node) {
            _node = node;
        }
    }

    public class Api {
        public Model GetModel(...) {
            var node = JsonSerializer.Deserialize<JsonNode>(...);
            return new Model(node);
        }
    }
}

...

namespace LibraryUser {
    public class Program {
        public static void Main() {
            var model = Api.GetModel(...);
            Console.WriteLine(model.Number); // First time access, will this cause lazy parse json here?
            ...
            Console.WriteLine(model.Number); // Second time access, will this cause parse json here again?
        }
    }
}

Maybe you will ask, why not deserialize into Model directly instead of JsonNode?

Because in a real environment, a json object may have dozens or even hundreds of fields, but not all of these fields appear at the same time. To define all fields as properties (rather than get accessors) in the Model is an unnecessary waste of memory.

[Clockwork-Muse]

Because in a real environment, a json object may have dozens or even hundreds of fields, but not all of these fields appear at the same time.

.... you have a completely flat data model? That seems unusual. If you instead split the model up into multiple domain types your deserialized size could be smaller than a flatter model due to nested properties not being deserialized in some cases.

To define all fields as properties (rather than get accessors) in the Model is an unnecessary waste of memory.

You're retaining the JSON structure. There's a break-even point, sure, but it's probably around 25-50% of the fields being filled. If your data is consistently mostly filled you're losing just due to object references. If they're consistently mostly empty your data model is likely too sparse.

Note that this only applies if you're receiving lots of instances of models in a relatively short period of time, like for a web api. If these are config values in a client application, the savings are mostly irrelevant.

// Second time access, will this cause parse json here again?

The answer would be an internal implementation detail, and not something you should rely on.

[GF-Huang]

Not flat, but fields depends on a specific enum field value. Maybe I should write a custom converter for deserializing into different derived classes.

[Clockwork-Muse]

Polymorphic serialization is already supported.

[GF-Huang]

Oh, thanks point it out.

[GF-Huang]

There's a bit crappy is the type discriminator must be the first property in the json.

If I move ActivityType to first, it works well, but usually I can't control properties order if it is a Web API.

[Clockwork-Muse]

Yes, see #72604.