You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a sincerely meant question, not a bug report.
Why is de-serialization of immutable classes so poorly supported?
(or one might argue that "not at all" is more precise than "poorly" unless custom converters are deemed support for such case).
By support I mean mostly ability to use parameterized (maybe not public) constructors and private setters during deserialization.
a) Is it by design for performance reasons?
b) Is it just a result of not enough time and it will be supported sometime in near future?
If a) is the answer what are the implications for the rest of the code?
throw immutability out of the window?
have dedicated layer of classes just for de/serialization which are immediately translated to immutable DTOs used down the line. (I wonder what would that do for overall performance even if the serialization framework would do better on its own).
The text was updated successfully, but these errors were encountered:
Tagging subscribers to this area: @eiriktsarpalis
Notify danmosemsft if you want to be subscribed.
jdvor
changed the title
Why is immutable classes so poorly supported?
Why is immutable classes so poorly supported in System.Text.Json?
May 7, 2020
jdvor
changed the title
Why is immutable classes so poorly supported in System.Text.Json?
Why are immutable classes so poorly supported in System.Text.Json?
May 7, 2020
You can try these features in preview 4 of .NET 5 or the System.Text.Json package on Nuget.
These have always been on the roadmap for System.Text.Json, but were scoped out of 3.x due to time constraints and feature scoping. Please see the System.Text.Json project board for 5.0 for an overview of what we are prioritizing in this release.
System.Text.Json
This is a sincerely meant question, not a bug report.
Why is de-serialization of immutable classes so poorly supported?
(or one might argue that "not at all" is more precise than "poorly" unless custom converters are deemed support for such case).
By support I mean mostly ability to use parameterized (maybe not public) constructors and private setters during deserialization.
a) Is it by design for performance reasons?
b) Is it just a result of not enough time and it will be supported sometime in near future?
If a) is the answer what are the implications for the rest of the code?
The text was updated successfully, but these errors were encountered: