Replies: 3 comments 3 replies
-
As explained in the original issue, this behavior is by design.
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;
}
}
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. |
Beta Was this translation helpful? Give feedback.
-
I just want to have answers to my questions. As your answers are not adequate answers, I ask again the same questions.
I took the time to understand, but you do not answer my questions, obviously because you do not understand them…
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:
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… |
Beta Was this translation helpful? Give feedback.
-
@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.
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:
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. |
Beta Was this translation helpful? Give feedback.
-
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.
but it fails… I know, the documentation does not mention such support, but wait…
Now the private fields are populated, but we have useless getters and values:
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?
Beta Was this translation helpful? Give feedback.
All reactions