Att Arbeta med DTO
Att använda DTO:er förenklar och optimerar datautbytet genom att utesluta onödiga fält och endast tillhandahålla den data som en specifik klient faktiskt behöver.
DTO:er i detta exempel används för att begränsa datautbytet mellan klient och server. ResponseBookDTO används för att skicka endast nödvändig data (name, author, price) till klienten, medan RequestBookDTO tillåter klienter att skicka obligatorisk data (date, name, author, price) till servern.
Den främsta fördelen med att använda DTO:er är att de hjälper till att separera data från affärslogik och möjliggör kontroll över vilken data som överförs mellan applikationens lager eller inkluderas i HTTP-svarmeddelanden.
Var används DTO?
DTO:er används när det finns behov av att presentera data i ett specifikt format, till exempel för överföring av data till en klient eller mottagning av information från en klient inom ramen för ett REST API.
Detta är också relevant vid interaktion mellan lager i en flerskiktsarkitektur, där data skickas mellan tjänster och databaser.
Exempel från verkligheten
Föreställ dig att du utvecklar en applikation för en webbutik. Du har en entitet kallad Product, som innehåller mycket information: name, description, price, production date, discounts och så vidare.
En klient som begär en lista över produkter behöver inte all denna information. Istället kan du skapa ett DTO-objekt som endast innehåller de nödvändiga fälten (såsom namn och pris) för att skicka denna data till klienten.
Exempel på användning
I vår applikation är den primära modellen Book, som skickas av klienten och returneras av servern.
Main.java
12345678@Getter @Setter public class Book { private String id; private String name; private String author; private String price; }
Men verkar inte id-fältet vara onödigt när data tas emot från klienten, eftersom det genereras på repository-nivå. id behövs endast när ett svar returneras.
Här kommer DTO:er till undsättning. De möjliggör att separera logiken och skapa olika versioner av Book-modellen för förfrågningar och svar, där onödiga fält som id kan uteslutas när det är lämpligt.
I en DTO används ett objekt med prefixet request för att skicka data från klienten till servern, medan ett objekt med prefixet response används för att skicka data från servern till klienten. Denna separation säkerställer att endast nödvändig data utbyts, vilket förbättrar både säkerhet och effektivitet.
BookRequestDTO.java
BookResponseDTO.java
12345public class BookRequestDTO { private String name; private String author; private String price; }
Nu har vi två DTO:er: en för att ta emot förfrågningar BookRequestDTO och en annan för att skicka svar BookResponseDTO.
Du kanske märker att BookResponseDTO och vår modell Book är identiska, vilket väcker frågan: varför skapa en separat DTO om vi bara kan använda Book modellen?
Anledningen är att om vi senare bestämmer oss för att lägga till extra information som endast behövs på servicenivå, skulle vår modell Book börja vidarebefordra onödig data till repository-nivån, vilket skulle kräva att vi filtrerar den på något sätt.
Mapper
För att smidigt omvandla objekt från en typ till en annan använder vi ett specialiserat bibliotek.
Vi kan skapa en separat klass där vi definierar statisk metoder och implementerar logiken för konvertering av objekt mellan 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 denna kod använder klassen MapperBook biblioteket ModelMapper för automatisk objektomvandling.
Den innehåller två metoder: den första är dtoRequestToModel(), som omvandlar ett BookRequestDTO-objekt till en Book-modell med hjälp av metoden map, och den andra är modelToResponseDto(), som konverterar en Book-modell till ett BookResponseDTO-objekt.
Tack vare ModelMapper blir processen för objektomvandling enklare och mer bekväm, vilket eliminerar behovet av att manuellt kopiera fält.
Lägga till en DTO i vår applikation
Sammanfattning
DTO (Data Transfer Object) är ett enkelt objekt avsett för överföring av data mellan lager eller komponenter i en applikation.
I sammanhanget av en trelagersarkitektur spelar DTO en avgörande roll genom att säkerställa separation av lager och erbjuda ett effektivt sätt att utbyta data mellan dem.
Att använda en DTO blir därmed en optimal lösning när det är nödvändigt att hantera information mellan olika delar av en applikation, och undvika överföring av onödig eller irrelevant data.
1. Vad är en DTO i programmeringssammanhang?
2. Vilket av följande är det bästa användningsområdet för en DTO?
Tack för dina kommentarer!
Fråga AI
Fråga AI
Fråga vad du vill eller prova någon av de föreslagna frågorna för att starta vårt samtal
What are the main benefits of using DTOs in an application?
Can you explain how ModelMapper works for mapping DTOs?
When should I use a DTO instead of a regular model?
Awesome!
Completion rate improved to 3.45Att Arbeta med DTO
Svep för att visa menyn
Att använda DTO:er förenklar och optimerar datautbytet genom att utesluta onödiga fält och endast tillhandahålla den data som en specifik klient faktiskt behöver.
DTO:er i detta exempel används för att begränsa datautbytet mellan klient och server. ResponseBookDTO används för att skicka endast nödvändig data (name, author, price) till klienten, medan RequestBookDTO tillåter klienter att skicka obligatorisk data (date, name, author, price) till servern.
Den främsta fördelen med att använda DTO:er är att de hjälper till att separera data från affärslogik och möjliggör kontroll över vilken data som överförs mellan applikationens lager eller inkluderas i HTTP-svarmeddelanden.
Var används DTO?
DTO:er används när det finns behov av att presentera data i ett specifikt format, till exempel för överföring av data till en klient eller mottagning av information från en klient inom ramen för ett REST API.
Detta är också relevant vid interaktion mellan lager i en flerskiktsarkitektur, där data skickas mellan tjänster och databaser.
Exempel från verkligheten
Föreställ dig att du utvecklar en applikation för en webbutik. Du har en entitet kallad Product, som innehåller mycket information: name, description, price, production date, discounts och så vidare.
En klient som begär en lista över produkter behöver inte all denna information. Istället kan du skapa ett DTO-objekt som endast innehåller de nödvändiga fälten (såsom namn och pris) för att skicka denna data till klienten.
Exempel på användning
I vår applikation är den primära modellen Book, som skickas av klienten och returneras av servern.
Main.java
12345678@Getter @Setter public class Book { private String id; private String name; private String author; private String price; }
Men verkar inte id-fältet vara onödigt när data tas emot från klienten, eftersom det genereras på repository-nivå. id behövs endast när ett svar returneras.
Här kommer DTO:er till undsättning. De möjliggör att separera logiken och skapa olika versioner av Book-modellen för förfrågningar och svar, där onödiga fält som id kan uteslutas när det är lämpligt.
I en DTO används ett objekt med prefixet request för att skicka data från klienten till servern, medan ett objekt med prefixet response används för att skicka data från servern till klienten. Denna separation säkerställer att endast nödvändig data utbyts, vilket förbättrar både säkerhet och effektivitet.
BookRequestDTO.java
BookResponseDTO.java
12345public class BookRequestDTO { private String name; private String author; private String price; }
Nu har vi två DTO:er: en för att ta emot förfrågningar BookRequestDTO och en annan för att skicka svar BookResponseDTO.
Du kanske märker att BookResponseDTO och vår modell Book är identiska, vilket väcker frågan: varför skapa en separat DTO om vi bara kan använda Book modellen?
Anledningen är att om vi senare bestämmer oss för att lägga till extra information som endast behövs på servicenivå, skulle vår modell Book börja vidarebefordra onödig data till repository-nivån, vilket skulle kräva att vi filtrerar den på något sätt.
Mapper
För att smidigt omvandla objekt från en typ till en annan använder vi ett specialiserat bibliotek.
Vi kan skapa en separat klass där vi definierar statisk metoder och implementerar logiken för konvertering av objekt mellan 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 denna kod använder klassen MapperBook biblioteket ModelMapper för automatisk objektomvandling.
Den innehåller två metoder: den första är dtoRequestToModel(), som omvandlar ett BookRequestDTO-objekt till en Book-modell med hjälp av metoden map, och den andra är modelToResponseDto(), som konverterar en Book-modell till ett BookResponseDTO-objekt.
Tack vare ModelMapper blir processen för objektomvandling enklare och mer bekväm, vilket eliminerar behovet av att manuellt kopiera fält.
Lägga till en DTO i vår applikation
Sammanfattning
DTO (Data Transfer Object) är ett enkelt objekt avsett för överföring av data mellan lager eller komponenter i en applikation.
I sammanhanget av en trelagersarkitektur spelar DTO en avgörande roll genom att säkerställa separation av lager och erbjuda ett effektivt sätt att utbyta data mellan dem.
Att använda en DTO blir därmed en optimal lösning när det är nödvändigt att hantera information mellan olika delar av en applikation, och undvika överföring av onödig eller irrelevant data.
1. Vad är en DTO i programmeringssammanhang?
2. Vilket av följande är det bästa användningsområdet för en DTO?
Tack för dina kommentarer!
