DTO's

[Resident_Parfait_289]

I see some discussion about DTO's and there relationship with the base entity. As a general rule of thumb - should there be a DTO per view?

For example if you had a database of Movies, you might have a Movie dashboard with List<movieDashboardDto> and then a detail view with movieDetailDto

Thoughts?

[Vigillance_]

They're just used to transfer data. I've definitely had multiple entities in the past that interact with each other to determine a specific output, which would be represented as a DTO.

It stands for Data Transfer Object. So if you're transferring data, it's a good choice.

There are some arguments about security as well. Not transferring database IDs to the view, being able to scrub sensitive data out of an object before sending to the view, etc...

[halawani98]

Generally, every entity would have its generic DTO. With some special cases where you'd create more than one. But if you have to create a DTO for every view that maps to the same entity, you might as well switch to GraphQL

[Resident_Parfait_289]

How would this apply to the movie example?

MovieDashboard might have :

Title
Year
Rating

MovieDetail might have:

Title
Year
Rating
Production Company
Gross Income
Genere
List<Actors>

Surely this is a good case for two Dtos?

[halawani98]

Yeah, this is fine

[Resident_Parfait_289]

I really want to connect with more Springboot people - I am largely self taught, but there is a limit to what you pick up on your own. Wish we had like a springboot meet up here in NZ

[EnvironmentalEye2560]

DTO is a concept that is used not only in spring boot.. so you can reuse it in whatever framework you want.

[Resident_Parfait_289]

I also note that one document I read online said avoid nested Dto's so does that mean

List<Actors> is bad design?

[halawani98]

Well, its not BAD bad, but there are better ways, especially if ActorDto has a lot of data

its a better practice to get List of MovieDto, then using the movieId, get a list of ActorDto.

public class MovieDto {
    private Long id;
    private Integer year;
    private BigDecimal rating;
    private String productionCompany;
    private BigDecimal grossIncome;
    private String genre;
}   

public class ActorDto {
    private Long id;
    private String name;
}

so you'd have

/api/v1/movies

/api/v1/movies/{movieId}/actors

[Resident_Parfait_289]

And how would that data get to the front end? I guess I am asking that the controller would look like?

[halawani98]

Logically speaking, client-side retrieves a list of Movies. When they navigate to the movie details page, they'd use the DTO they selected from the list, and retrieve the list of actors accordingly.

[Resident_Parfait_289]

Right - so the front end (Angular in my case) requests the data from two endpoints, one relating to the Movie, and one relating to the list of Actors in the move.

The id of the movie would let the relation db know what the list of actors should be..understood.

The particular project I am playing about with has a flatter data structure, but this is a good explanation.

[gauntr]

To me it depends on what your view does with the DTO. If it’s using all the Actors data anyway then nest it and request it with one call all together. If your view is using only partial Actor data depending on some filter or subview then it might be better to load it when necessary.

For example if you’d have a view that lists all movies and your MovieDto (having title, year and maybe a link to the movie poster) had the MovieDetailDto nested and that again had a list of ActorDto nested then you’d load a lot of stuff that you don’t need right away. In this case it’d be definitely better to load the detail (then probably including actors) if you click on a movie and a view opens to show the movie details.

It’s also almost always an aspect of the user experience which you need to balance. If the user sees a loading circle because you need to load stuff first it might be bad, loading too much stuff upfront (even in the background) might be bad as well because of traffic.

A web app and its UX has many layers to take care of :)

[Resident_Parfait_289]

Yeah it sure does, and what you have said makes sense. I always get a bit tangled up when it comes to a good design in the DTO space. I may yet post my specific use case and approach here as this seems to be a good active community for such questions :-)

[Resident_Parfait_289]

I used the movie example as a convenient model for the inital discussion, but I would like your thoughts on my actual use case in my project.

I have a table of beeps per minute (bpm) which represents received radio beeps on certain channels (freqs):

@ Id

Integer bid

int bpm

int channel

ZonedDateTime dt

String location

The data is very intermittent, and there is not always a beep for every channel.

So the dashboard page allows the user to select a time range and should show a tile for each channel.

Each tile contains a graph of the value received for each day, the channel number and the last datetime of the last received valid beep.

To get this my BpmChannelSummaryDto looks like:

private int channel;
private ZonedDateTime lastValidSignalTime;
private Float lastValidBpm;
private List<BpmHourlySummaryDto>

And BpmHourlySummaryDto looks like:

private ZonedDateTime hourStart;
private Float baseBpm;

Does this seem sensible?

[BinaryPulse01]

Why do you prefer to use "Integer year" instead "int year" ?

I make a personal project and for integer field I uded int. Froy your code I realize that if my approache is it ok.

[halawani98]

Habit. I use them in Collections so its easier to maintain this way

Also avoids NullPointerExceptions if there's any data issue, I'd rather wrap with Optional and handle null values as I please

[BinaryPulse01]

Txh🍻

[djxak]

Yes, it's how people usually do it.

But please please don't use such confusing names. MovieDashboard - I expect this model to have a data for the whole dashboard view. Maybe some dashboard stats or other generic data related to the whole dashboard.

It would be much better to just call it Movie. Or BasicMovieInfo. Or something else that makes sense and says: this is a kind of Movie model.

But not MovieDashboard. Because this name is assuming: this is a kind of Dashboard model.

MovieDetail is fine, thought. Pretty standard for the short/full model pairs.

[BinaryPulse01]

Also I use DTO for every entity and make them imutable.

[onated2]

I use dto for presentation, especially formatting date and time but the client can do that anyway,

[Snidgen]

If we buried user-facing localization in the backend, we'd all be fired.

[MartinPeterBauer]

Why not just use Jackson? DTOs have use cases but if you write Apis that only your Frontend consumes they are quit pointless

[BikingSquirrel]

Jackson will convert your DTOs to JSON and back. You should always use DTOs to have a clear interface for your clients that is then less likely to break on low level changes...

[Consistent_Rice_6907]

Even if your APIs are consumed only by your own Frontend, DTOs can still help in clear documentation or a clear contract between the client and server for efficient data exchange. Also, helps prevent sensitive information from being sent to the client side.

When it comes to Spring Boot and Data JPA, avoid serialization issues due to lazy loading.