Arbejde med DTO
Brugen af DTO'er forenkler og optimerer dataudveksling ved at udelade unødvendige felter og kun levere de data, som en specifik klient faktisk har brug for.
DTO'er i dette eksempel bruges til at begrænse dataudveksling mellem klient og server. ResponseBookDTO anvendes til kun at sende nødvendige data (name, author, price) til klienten, mens RequestBookDTO gør det muligt for klienter at sende pålkrævede data (date, name, author, price) til serveren.
Den primære fordel ved at anvende DTO'er er, at de hjælper med at adskille data fra forretningslogik og giver mulighed for kontrol over, hvilke data der overføres mellem lagene i applikationen eller inkluderes i HTTP-svarmeddelelser.
Hvor anvendes DTO?
DTO'er anvendes, når der er behov for at præsentere data i et specifikt format, såsom ved overførsel af data til en klient eller modtagelse af information fra en klient inden for rammen af et REST API.
Dette er også relevant, når der interageres mellem lag i en flerlaget arkitektur, hvor data videregives mellem services og repositories.
Eksempel fra virkeligheden
Forestil dig, at du udvikler en applikation til en onlinebutik. Du har en entitet kaldet Product, som indeholder en masse information: name, description, price, production date, discounts og så videre.
En klient, der anmoder om en liste over produkter, behøver ikke alle disse oplysninger. I stedet kan du oprette et DTO-objekt, der kun indeholder de nødvendige felter (såsom navn og pris) for at sende disse data til klienten.
Eksempel på anvendelse
I vores applikation er den primære model Book, som sendes af klienten og returneres af serveren.
Main.java
12345678@Getter @Setter public class Book { private String id; private String name; private String author; private String price; }
Dog ikke virker det som om, at id-feltet er overflødigt ved modtagelse af data fra klienten, da det genereres på repository-niveau. id er kun nødvendig ved returnering af et svar.
Her kommer DTO'er til undsætning. De muliggør adskillelse af logik og oprettelse af forskellige versioner af Book-modellen til forespørgsler og svar, hvor unødvendige felter som id udelades, hvor det er passende.
I en DTO anvendes et objekt med request-præfiks til at sende data fra klienten til serveren, mens et objekt med response-præfiks bruges til at sende data fra serveren til klienten. Denne adskillelse sikrer, at kun nødvendige data udveksles, hvilket øger både sikkerhed og effektivitet.
BookRequestDTO.java
BookResponseDTO.java
12345public class BookRequestDTO { private String name; private String author; private String price; }
Nu har vi to DTO'er: én til at modtage forespørgsler BookRequestDTO og en anden til at sende svar BookResponseDTO.
Du bemærker måske, at BookResponseDTO og vores Book model er identiske, hvilket rejser spørgsmålet: hvorfor oprette en separat DTO, hvis vi bare kan bruge Book modellen?
Årsagen er, at hvis vi senere beslutter at tilføje ekstra information, som kun er nødvendig på serviceniveau, vil vores Book model ende med at videregive unødvendige data til repository-niveauet, hvilket kræver, at vi filtrerer det på en eller anden måde.
Mapper
For nemt at omdanne objekter fra én type til en anden, anvendes et specialiseret bibliotek.
Det er muligt at oprette en separat klasse, hvor der defineres statisk metoder og implementeres logik til konvertering af objekter mellem typer.
MapperBook.
1234567891011public class MapperBook { private static final ModelMapper mapper = new ModelMapper(); public static Book dtoRequestToModel(BookRequestDTO dto) { return mapper.map(dto, Book.class); } public static BookResponseDTO modelToResponseDto(Book book) { return mapper.map(book, BookResponseDTO.class); } }
I denne kode anvender MapperBook klassen ModelMapper biblioteket til automatisk objekttransformation.
Den indeholder to metoder: den første er dtoRequestToModel(), som transformerer et BookRequestDTO objekt til en Book model ved hjælp af map metoden, og den anden er modelToResponseDto(), som konverterer en Book model til et BookResponseDTO objekt.
Takket være ModelMapper bliver processen med objekttransformation nemmere og mere bekvem, hvilket eliminerer behovet for manuelt at kopiere felter.
Tilføjelse af en DTO til vores applikation
Resumé
DTO (Data Transfer Object) er et simpelt objekt designet til overførsel af data mellem lag eller komponenter i en applikation.
I konteksten af en trelagsarkitektur spiller DTO en afgørende rolle ved at sikre adskillelse af lag og give en effektiv metode til at udveksle data mellem dem.
Brugen af en DTO bliver således en optimal løsning, når det er nødvendigt at håndtere information mellem forskellige dele af en applikation, og undgå overførsel af unødvendige eller irrelevante data.
1. Hvad er en DTO i programmeringskontekst?
2. Hvilket af følgende er den bedste anvendelse af en DTO?
Tak for dine kommentarer!
Spørg AI
Spørg AI
Spørg om hvad som helst eller prøv et af de foreslåede spørgsmål for at starte vores chat
Awesome!
Completion rate improved to 3.45Arbejde med DTO
Stryg for at vise menuen
Brugen af DTO'er forenkler og optimerer dataudveksling ved at udelade unødvendige felter og kun levere de data, som en specifik klient faktisk har brug for.
DTO'er i dette eksempel bruges til at begrænse dataudveksling mellem klient og server. ResponseBookDTO anvendes til kun at sende nødvendige data (name, author, price) til klienten, mens RequestBookDTO gør det muligt for klienter at sende pålkrævede data (date, name, author, price) til serveren.
Den primære fordel ved at anvende DTO'er er, at de hjælper med at adskille data fra forretningslogik og giver mulighed for kontrol over, hvilke data der overføres mellem lagene i applikationen eller inkluderes i HTTP-svarmeddelelser.
Hvor anvendes DTO?
DTO'er anvendes, når der er behov for at præsentere data i et specifikt format, såsom ved overførsel af data til en klient eller modtagelse af information fra en klient inden for rammen af et REST API.
Dette er også relevant, når der interageres mellem lag i en flerlaget arkitektur, hvor data videregives mellem services og repositories.
Eksempel fra virkeligheden
Forestil dig, at du udvikler en applikation til en onlinebutik. Du har en entitet kaldet Product, som indeholder en masse information: name, description, price, production date, discounts og så videre.
En klient, der anmoder om en liste over produkter, behøver ikke alle disse oplysninger. I stedet kan du oprette et DTO-objekt, der kun indeholder de nødvendige felter (såsom navn og pris) for at sende disse data til klienten.
Eksempel på anvendelse
I vores applikation er den primære model Book, som sendes af klienten og returneres af serveren.
Main.java
12345678@Getter @Setter public class Book { private String id; private String name; private String author; private String price; }
Dog ikke virker det som om, at id-feltet er overflødigt ved modtagelse af data fra klienten, da det genereres på repository-niveau. id er kun nødvendig ved returnering af et svar.
Her kommer DTO'er til undsætning. De muliggør adskillelse af logik og oprettelse af forskellige versioner af Book-modellen til forespørgsler og svar, hvor unødvendige felter som id udelades, hvor det er passende.
I en DTO anvendes et objekt med request-præfiks til at sende data fra klienten til serveren, mens et objekt med response-præfiks bruges til at sende data fra serveren til klienten. Denne adskillelse sikrer, at kun nødvendige data udveksles, hvilket øger både sikkerhed og effektivitet.
BookRequestDTO.java
BookResponseDTO.java
12345public class BookRequestDTO { private String name; private String author; private String price; }
Nu har vi to DTO'er: én til at modtage forespørgsler BookRequestDTO og en anden til at sende svar BookResponseDTO.
Du bemærker måske, at BookResponseDTO og vores Book model er identiske, hvilket rejser spørgsmålet: hvorfor oprette en separat DTO, hvis vi bare kan bruge Book modellen?
Årsagen er, at hvis vi senere beslutter at tilføje ekstra information, som kun er nødvendig på serviceniveau, vil vores Book model ende med at videregive unødvendige data til repository-niveauet, hvilket kræver, at vi filtrerer det på en eller anden måde.
Mapper
For nemt at omdanne objekter fra én type til en anden, anvendes et specialiseret bibliotek.
Det er muligt at oprette en separat klasse, hvor der defineres statisk metoder og implementeres logik til konvertering af objekter mellem typer.
MapperBook.
1234567891011public class MapperBook { private static final ModelMapper mapper = new ModelMapper(); public static Book dtoRequestToModel(BookRequestDTO dto) { return mapper.map(dto, Book.class); } public static BookResponseDTO modelToResponseDto(Book book) { return mapper.map(book, BookResponseDTO.class); } }
I denne kode anvender MapperBook klassen ModelMapper biblioteket til automatisk objekttransformation.
Den indeholder to metoder: den første er dtoRequestToModel(), som transformerer et BookRequestDTO objekt til en Book model ved hjælp af map metoden, og den anden er modelToResponseDto(), som konverterer en Book model til et BookResponseDTO objekt.
Takket være ModelMapper bliver processen med objekttransformation nemmere og mere bekvem, hvilket eliminerer behovet for manuelt at kopiere felter.
Tilføjelse af en DTO til vores applikation
Resumé
DTO (Data Transfer Object) er et simpelt objekt designet til overførsel af data mellem lag eller komponenter i en applikation.
I konteksten af en trelagsarkitektur spiller DTO en afgørende rolle ved at sikre adskillelse af lag og give en effektiv metode til at udveksle data mellem dem.
Brugen af en DTO bliver således en optimal løsning, når det er nødvendigt at håndtere information mellem forskellige dele af en applikation, og undgå overførsel af unødvendige eller irrelevante data.
1. Hvad er en DTO i programmeringskontekst?
2. Hvilket af følgende er den bedste anvendelse af en DTO?
Tak for dine kommentarer!
