C#
C#

help

Root Question Message

sydney
sydney9/7/2022
long model from api when we use DeserializeObject (working with asp)

hi all, im trying to use JsonConvert.DeserializeObject<NoteModel>(response.Content); to save the result from API to my NoteModel, and the structure of my NoteModel should be like this so we can match the response from api :

    public class Data
    {
        public Properties properties { get; set; }
    }

    public class Properties
    {
        public int id { get; set; }
        public string initials { get; set; }
        public string name { get; set; }
    }

    public class Results
    {
        public Data data { get; set; }
    }

    public class NoteModel
    {
        public Results results { get; set; }
    }


but when i try to access for example name data, i should do it like this

NoteModel result = await ... ;
string nameData = result.results.data.properties.name;

which is really long, can anyone help advise if this is the right/normal way? thank you so much in advance.
Klarth
Klarth9/7/2022
Normally, I define models specific to the JSON schema. I call these Serialization Models. I create other models that are more application task-specific and decoupled from the schema (often called DTOs or sometimes I will map directly to a ViewModel). Then I write code or services to map between each.
Klarth
Klarth9/7/2022
Otherwise, yes. That's roughly correct. I'm not sure if Newtonsoft supports records, but System.Text.Json does. I prefer using records here, plus using C#-proper PascalCase casing for properties.
sydney
sydney9/7/2022
i see.. i saw there's a service to convert to a DTO model, it is AutoMapper, is it ok to use this or we write a code separately?
Klarth
Klarth9/7/2022
This is going into opinion territory, but I don't use Automapper. I don't maintain projects with hundreds of models, and maybe it would be more appealing if I did. But from what I see is that Automapper is ugly when the input and output models aren't 1:1.
Klarth
Klarth9/7/2022
That means learning a new API with new pitfalls instead of writing some very basic C# code.
Klarth
Klarth9/7/2022
There's also https://github.com/MapsterMapper/Mapster as an alternative to Automapper, but I haven't used either in-depth.
sydney
sydney9/7/2022
i see, so it's better to manually write a code to map a json schema model to our DTO model rather than using automapper.
Klarth
Klarth9/7/2022
That's my opinion and the opinion of many members here, yeah. But the amount of value really depends on the type of application architectures you use and how much you change/adapt data as it goes through layers.
sydney
sydney9/7/2022
i'll try to write my own model to convert manually, im also looking into the c# Records json serialization, thank you for your advices!
sydney
sydney9/7/2022
sry.. so for example if i have Json schema model and DTO model, and if we use automapper, we also need the 2 models so we actually dont create another new model for this, can i understand what you mean by "I don't maintain projects with hundreds of models"?
Klarth
Klarth9/7/2022
"I don't maintain projects with hundreds of models" means that I don't know how well the process scales past ~100 models in terms of maintainability.
Klarth
Klarth9/7/2022
Whether you use Automapper or creating the mapper yourself, you still want an input model and an output model. There's no need for yet another model unless you're going through yet another layer.
sydney
sydney9/7/2022
i see.. so if my json schema model is named NoteModel, can i rename my output model for example NoteDTO?
Klarth
Klarth9/7/2022
It's an approach, sure. Sometimes it's worth skipping DTOs and mapping directly to a ViewModel. All indirection has maintainability costs.
Klarth
Klarth9/7/2022
It's very similar to how you use EF for a desktop app. You have entities which represent the database schema (serialization model here), DTOs to transform data and transfer out of the data / service layer, and ViewModel to be much more convenient what the View actually displays (plus some middleman logic).
sydney
sydney9/7/2022
so far i understand that ViewModel is the model that we return to a View (for user to see our model result, i might have a wrong understanding on this), so actually i have to return the output model after i convert from json schema model to another API, is that ok if i name my output model as NoteViewModel (since my result is for an API to receive not a View)?
Klarth
Klarth9/7/2022
If you're only forwarding the same data in the same schema, then there's no need for DTOs, ViewModels, etc.
Klarth
Klarth9/7/2022
If you're transforming, then use both the serialization model and DTO. You only need a ViewModel if you're doing frontend work (and ViewModels are part of your architecture approach).
sydney
sydney9/7/2022
sry if im asking too much 😓 ... im trying to understand your answer.. schema here you mean is like the service or layer, is that right?
Klarth
Klarth9/7/2022
No, schema is the underlying data representation (and the C# representation of the data that matches it which I call serialization models). Whether that's JSON, XML, CSV, database (entities rather than serialization models), etc.
Klarth
Klarth9/7/2022
I try to do as exact a 1:1 match as possible between the schema and serialization models (with some leeway for casing and sensible converters). Then map to a friendlier type. A schema representation and working C# type (DTO) have different needs. This is especially true when the schema is not something you control...or otherwise has to support multiple apps with their own specific needs.
sydney
sydney9/7/2022
i see.. okay.. i'll try to read more on this modeling theory and understand more.. thank you so much for all of your explanations!
ContactFrequently Asked QuestionsJoin The DiscordBugs & Feature RequestsTerms & Privacy