C#•3y ago

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; }
    }

    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;

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.

14 Replies

Klarth•3y ago

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. 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.

zi_youOP•3y ago

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•3y ago

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. That means learning a new API with new pitfalls instead of writing some very basic C# code. There's also https://github.com/MapsterMapper/Mapster as an alternative to Automapper, but I haven't used either in-depth.

zi_youOP•3y ago

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•3y ago

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.

zi_youOP•3y ago

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! 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•3y ago

"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. 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.

zi_youOP•3y ago

i see.. so if my json schema model is named NoteModel, can i rename my output model for example NoteDTO?

Klarth•3y ago

It's an approach, sure. Sometimes it's worth skipping DTOs and mapping directly to a ViewModel. All indirection has maintainability costs. 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).

zi_youOP•3y ago

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•3y ago

If you're only forwarding the same data in the same schema, then there's no need for DTOs, ViewModels, etc. 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).

zi_youOP•3y ago

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•3y ago

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. 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.

zi_youOP•3y ago

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!

Gaming

Programming

long model from api when we use DeserializeObject (working with asp)

Did you find this page helpful?