System.Text.Json Deserialization and illogical behavior BIS

[vintzl]

Read here to get the context.

As @eiriktsarpalis seems unable to understand or to give me an adequate answer, I try again here, hoping that he??? or, better, someone else will give me, this time, a clear answer.

I think there is a buggy behavior with deserialization.

1. I would expect to see the following fields automatically populated as they match constructor parameters, like this:

string json = @"{ ""id"" : 1, ""name"" : ""test"" }"; // The json keys match the constructor parameters
Test test = JsonSerializer.Deserialize<Test>(json, new JsonSerializerOptions());

public class Test
{
    private ushort _id;
    private string _name;

    public Test(ushort id, string name)
    {
        _id = id;
        _name = name;
    }
}

but it fails… I know, the documentation does not mention such support, but wait…

2. To get the "expected behavior", we have to add useless getters to get these private fields initialized:

string json = @"{ ""id"" : 1, ""name"" : ""test"" }"; // The json keys match the constructor parameters
Test test = JsonSerializer.Deserialize<Test>(json, new JsonSerializerOptions());

public class Test
{
    private ushort _id;
    private string _name;

    public ushort Id { get; } // useless as non matching getter, but now deserialization works as expected
    public string Name { get; } // useless as non matching getter, but now deserialization works as expected

    public Test(ushort id, string name)
    {
        _id = id;
        _name = name;
    }
}

Now the private fields are populated, but we have useless getters and values:

_id [ushort]:1
_name [string]:"test"
id [ushort]:0
name [string]:null

3. If this is not buggy, why we have to add useless as not matching getters to get the private fields populated "as expected"? And how this is possible while private fields deserialization "should not be supported"?

Nothing prevent private fields deserialization here. We just have to put some useless as non matching getters.

So why not enabling private fields deserialization when json object keys match constructor parameters, of course without adding such useless as not matching getters?

[eiriktsarpalis]

As explained in the original issue, this behavior is by design.

I would expect to see the following fields automatically populated as they match constructor parameters

They don't, fields are prefixed with underscores whereas the constructor parameters are not. You would need to make the names match (up to case insensitivity) but this would not be sufficient alone, since private fields are not supported. You would need to use something like the following:

string json = @"{ ""id"" : 42, ""name"" : ""name"" }";
Test test = JsonSerializer.Deserialize<Test>(json, new JsonSerializerOptions { IncludeFields = true });

public class Test
{
    public ushort id;
    public string name;

    public Test(ushort id, string name)
    {
        this.id = id;
        this.name = name;
    }
}

Or change your code to use properties to avoid public modification of the class:

string json = @"{ ""id"" : 42, ""name"" : ""name"" }";
Test test = JsonSerializer.Deserialize<Test>(json);

public class Test
{
    public ushort id { get; }
    public string name { get; }

    public Test(ushort id, string name)
    {
        this.id = id;
        this.name = name;
    }
}

To get the "expected behavior", we have to add useless getters to get these private fields initialized:

Again, as mentioned in the original post this is by design behavior intended to ensure that serialization is roundtripable. Do note however that it is far from "expected behavior" since serialization is still broken (it will write the properties instead of the fields). The fact that fields end up being populated on deserialization is not an attribute of the serializer itself, but because it is calling the constructor that does happen to populate the fields. In other words, it is not the adding of properties that somehow make the serializer suddenly support private field serialization.

[eiriktsarpalis]

@vintzl repeating the same question again and again will not somehow change the original answer. Please take a moment to understand the answer provided, instead of spewing abuse. I assure you that I have understood your question as well your misunderstandings of what the problem is, but it's painfully clear that you have not understood my own feedback.

Also, please be aware that these forums operate under a code of conduct, so I would kindly ask you to either abide by it or leave.

[vintzl]

@vintzl repeating the same question again and again will not somehow change the original answer.

I just want to have answers to my questions. As your answers are not adequate answers, I ask again the same questions.

Please take a moment to understand the answer provided, instead of spewing abuse. I assure you that I have understood your question as well your misunderstandings of what the problem is, but it's painfully clear that you have not understood my own feedback.

I took the time to understand, but you do not answer my questions, obviously because you do not understand them…

Also, please be aware that these forums operate under a code of conduct, so I would kindly ask you to either abide by it or leave.

You right, I apologize, but you can also leave as you still give me wrong answers or let my questions unanswered…

Now I just want answers to the following questions, because you never give any answers to them:

1. Is it by design to add useless getters to get private fields initialized?
2. Is this normal to get private fields deserialization by adding useless getters?
3. If private fields deserialization is not supported, why adding useless getters "enable this feature"?
4. Why not supporting private field deserialization/serialization as long as constructor parameters match json key, but without this undocumented and buggy way, meaning by adding useless getters?

I can be rude, but after all you never answer my questions, and you force me to write/ask again the same thing. You just give me inadequate answers, and so you waste my time…

[eiriktsarpalis]

Is it by design to add useless getters to get private fields initialized?

Is this normal to get private fields deserialization

If private fields deserialization is not supported, why adding useless getters "enable this feature"?

You keep repeating the false assertion that adding getters enables private field serialization. I have repeatedly explained why it is false and provided examples as to why you might be confused about this. If we can't agree on this fact then I'm afraid I will not be able to help you any further.

[jeffhandley]

@vintzl and @mickturn, I have been following the threads around this topic, and I have been disappointed in the behavior exhibited by @vintzl. After several disrespectful messages to @eiriktsarpalis that have resulted in threads being locked, @mickturn created a new thread that raised the same topic again, but I've locked that thread too because it was not constructive either.

Ultimately, we just want to know what you can do to get private fields populated in the constructor like stated in the repro.

The necessary and appropriate guidance for this has already been explained in this response from @eiriktsarpalis with code that would accomplish what you're asking for. It seems to me that you simply do not like the solution, even though it would accomplish the behavior sought from System.Text.Json. We understand that you desire the approach/solution to be different from what the feature set offers, but the constraints you're providing cannot and will not be met by the System.Text.Json features, as @eiriktsarpalis has kindly explained, due to the important constraints we have around private field handling.

If you are unhappy with how the serialization/deserialization affects your domain entities, then I would suggest you consider solutions to your problem where you are able to side-step the conflicting requirements you have:

1. Get the necessary (de)serialization behavior from System.Text.Json
2. Avoid having to modify the domain entities to meet the needs of (de)serialization

Perhaps something like a Data Transfer Object pattern would be helpful to you?

Please rest assured that your issues have been reviewed; your questions have been understood; and accurate guidance has been supplied. We will not change the design of System.Text.Json's private field handling to meet your requirements of avoiding modification of your domain entities. The disrespectful comments and the persistence at expressing disappointment will not yield any different guidance or answers.

Please consider this a warning per our code of conduct. Further attempts to post the same topic/question will be locked without response. And any further disrespect toward @eiriktsarpalis or other community members will not be tolerated--the next consequence is a temporary ban from interacting with our community.