DTO:n Kanssa Työskentely
DTO:iden käyttö yksinkertaistaa ja tehostaa tiedonvaihtoa jättämällä pois tarpeettomat kentät ja tarjoamalla vain tiedot, joita tietty asiakas todella tarvitsee.
Tässä esimerkissä DTO:t rajoittavat tiedonvaihtoa asiakkaan ja palvelimen välillä. ResponseBookDTO välittää asiakkaalle vain tarvittavat tiedot (name, author, price), kun taas RequestBookDTO mahdollistaa asiakkaiden lähettää vaaditut tiedot (date, name, author, price) palvelimelle.
Keskeinen etu DTO:iden käytössä on, että ne erottavat tiedot liiketoimintalogiikasta ja mahdollistavat hallinnan siitä, mitä tietoja siirretään sovelluksen kerrosten välillä tai sisällytetään HTTP-vastausviesteihin.
Missä DTO:ta käytetään?
DTO:t otetaan käyttöön, kun tiedot täytyy esittää tietyssä muodossa, esimerkiksi siirrettäessä tietoa asiakkaalle tai vastaanotettaessa tietoa asiakkaalta REST API -kontekstissa.
Tämä on myös olennaista, kun vuorovaikutetaan kerrosten välillä monikerroksisessa arkkitehtuurissa, jossa tietoa välitetään palveluiden ja tietovarastojen välillä.
Käytännön esimerkki
Kuvittele, että kehität sovellusta verkkokaupalle. Sinulla on entity nimeltä Product, joka sisältää paljon tietoa: name, description, price, production date, discounts ja niin edelleen.
Asiakas, joka pyytää tuotelistaa, ei tarvitse kaikkea tätä tietoa. Sen sijaan voit luoda DTO-olion, joka sisältää vain tarvittavat kentät (kuten nimi ja hinta) tämän datan lähettämiseksi asiakkaalle.
Käyttöesimerkki
Sovelluksessamme ensisijainen malli on Book, joka lähetetään asiakkaan toimesta ja palautetaan palvelimelta.
Main.java
12345678@Getter @Setter public class Book { private String id; private String name; private String author; private String price; }
Eikö kuitenkin vaikuta siltä, että id-kenttä on tarpeeton kun vastaanotetaan dataa asiakkaalta, koska se luodaan tietovarastotasolla. Tarvitsemme id:n vain kun palautamme vastauksen.
Tässä kohtaa DTO:t tulevat avuksi. Niiden avulla voimme eriyttää logiikan ja luoda erilaisia versioita Book-mallista pyyntöjä ja vastauksia varten, jättäen pois tarpeettomat kentät kuten id silloin kun se on asianmukaista.
DTO:ssa käytetään objektia, jolla on request-etuliite datan lähettämiseen asiakkaalta palvelimelle, kun taas objektia, jolla on response-etuliite, käytetään datan lähettämiseen palvelimelta asiakkaalle. Tämä erottelu varmistaa, että vain tarpeellinen data siirtyy, mikä parantaa sekä turvallisuutta että tehokkuutta.
BookRequestDTO.java
BookResponseDTO.java
12345public class BookRequestDTO { private String name; private String author; private String price; }
Nyt meillä on kaksi DTO:ta: yksi pyyntöjen vastaanottamiseen BookRequestDTO ja toinen vastausten lähettämiseen BookResponseDTO.
Saatat huomata, että BookResponseDTO ja meidän Book malli ovat identtisiä, mikä herättää kysymyksen: miksi luoda erillinen DTO, jos voimme käyttää Book mallia?
Syy tähän on, että jos myöhemmin päätämme lisätä ylimääräistä tietoa, jota tarvitaan vain palvelutasolla, meidän Book malli välittäisi tarpeetonta dataa tietovarastotasolle, mikä vaatisi meidän suodattaa sitä jollain tavalla.
Muunnin
Objektien muuntamiseen yhdestä tyypistä toiseen käytetään erikoistunutta kirjastoa.
Voidaan luoda erillinen luokka, jossa määritellään staattiset metodit ja toteutetaan logiikka objektien muuntamiseksi eri tyyppien välillä.
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); } }
Tässä koodissa MapperBook luokka käyttää ModelMapper kirjastoa automaattiseen olioiden muuntamiseen.
Se sisältää kaksi metodia: ensimmäinen on dtoRequestToModel(), joka muuntaa BookRequestDTO olion Book malliksi käyttäen map metodia, ja toinen on modelToResponseDto(), joka muuntaa Book mallin BookResponseDTO olioksi.
ModelMapper-kirjaston ansiosta olioiden muuntaminen on yksinkertaisempaa ja käytännöllisempää, eikä kenttien manuaalista kopiointia tarvita.
DTO:n lisääminen sovellukseemme
Yhteenveto
DTO (Data Transfer Object) on yksinkertainen olio, joka on tarkoitettu datan siirtämiseen sovelluksen kerrosten tai osien välillä.
Kolmitasoarkkitehtuurin yhteydessä DTO:lla on keskeinen rooli kerrosten eriyttämisessä ja se tarjoaa tehokkaan tavan datan vaihtoon niiden välillä.
Näin ollen DTO on optimaalinen ratkaisu silloin, kun on tarpeen hallita tietoa sovelluksen eri osien välillä ja välttää tarpeettoman tai epäolennaisen datan siirto.
1. Mikä on DTO ohjelmoinnin yhteydessä?
2. Mikä seuraavista on paras käyttötarkoitus DTO:lle?
Kiitos palautteestasi!
Kysy tekoälyä
Kysy tekoälyä
Kysy mitä tahansa tai kokeile jotakin ehdotetuista kysymyksistä aloittaaksesi keskustelumme
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.45DTO:n Kanssa Työskentely
Pyyhkäise näyttääksesi valikon
DTO:iden käyttö yksinkertaistaa ja tehostaa tiedonvaihtoa jättämällä pois tarpeettomat kentät ja tarjoamalla vain tiedot, joita tietty asiakas todella tarvitsee.
Tässä esimerkissä DTO:t rajoittavat tiedonvaihtoa asiakkaan ja palvelimen välillä. ResponseBookDTO välittää asiakkaalle vain tarvittavat tiedot (name, author, price), kun taas RequestBookDTO mahdollistaa asiakkaiden lähettää vaaditut tiedot (date, name, author, price) palvelimelle.
Keskeinen etu DTO:iden käytössä on, että ne erottavat tiedot liiketoimintalogiikasta ja mahdollistavat hallinnan siitä, mitä tietoja siirretään sovelluksen kerrosten välillä tai sisällytetään HTTP-vastausviesteihin.
Missä DTO:ta käytetään?
DTO:t otetaan käyttöön, kun tiedot täytyy esittää tietyssä muodossa, esimerkiksi siirrettäessä tietoa asiakkaalle tai vastaanotettaessa tietoa asiakkaalta REST API -kontekstissa.
Tämä on myös olennaista, kun vuorovaikutetaan kerrosten välillä monikerroksisessa arkkitehtuurissa, jossa tietoa välitetään palveluiden ja tietovarastojen välillä.
Käytännön esimerkki
Kuvittele, että kehität sovellusta verkkokaupalle. Sinulla on entity nimeltä Product, joka sisältää paljon tietoa: name, description, price, production date, discounts ja niin edelleen.
Asiakas, joka pyytää tuotelistaa, ei tarvitse kaikkea tätä tietoa. Sen sijaan voit luoda DTO-olion, joka sisältää vain tarvittavat kentät (kuten nimi ja hinta) tämän datan lähettämiseksi asiakkaalle.
Käyttöesimerkki
Sovelluksessamme ensisijainen malli on Book, joka lähetetään asiakkaan toimesta ja palautetaan palvelimelta.
Main.java
12345678@Getter @Setter public class Book { private String id; private String name; private String author; private String price; }
Eikö kuitenkin vaikuta siltä, että id-kenttä on tarpeeton kun vastaanotetaan dataa asiakkaalta, koska se luodaan tietovarastotasolla. Tarvitsemme id:n vain kun palautamme vastauksen.
Tässä kohtaa DTO:t tulevat avuksi. Niiden avulla voimme eriyttää logiikan ja luoda erilaisia versioita Book-mallista pyyntöjä ja vastauksia varten, jättäen pois tarpeettomat kentät kuten id silloin kun se on asianmukaista.
DTO:ssa käytetään objektia, jolla on request-etuliite datan lähettämiseen asiakkaalta palvelimelle, kun taas objektia, jolla on response-etuliite, käytetään datan lähettämiseen palvelimelta asiakkaalle. Tämä erottelu varmistaa, että vain tarpeellinen data siirtyy, mikä parantaa sekä turvallisuutta että tehokkuutta.
BookRequestDTO.java
BookResponseDTO.java
12345public class BookRequestDTO { private String name; private String author; private String price; }
Nyt meillä on kaksi DTO:ta: yksi pyyntöjen vastaanottamiseen BookRequestDTO ja toinen vastausten lähettämiseen BookResponseDTO.
Saatat huomata, että BookResponseDTO ja meidän Book malli ovat identtisiä, mikä herättää kysymyksen: miksi luoda erillinen DTO, jos voimme käyttää Book mallia?
Syy tähän on, että jos myöhemmin päätämme lisätä ylimääräistä tietoa, jota tarvitaan vain palvelutasolla, meidän Book malli välittäisi tarpeetonta dataa tietovarastotasolle, mikä vaatisi meidän suodattaa sitä jollain tavalla.
Muunnin
Objektien muuntamiseen yhdestä tyypistä toiseen käytetään erikoistunutta kirjastoa.
Voidaan luoda erillinen luokka, jossa määritellään staattiset metodit ja toteutetaan logiikka objektien muuntamiseksi eri tyyppien välillä.
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); } }
Tässä koodissa MapperBook luokka käyttää ModelMapper kirjastoa automaattiseen olioiden muuntamiseen.
Se sisältää kaksi metodia: ensimmäinen on dtoRequestToModel(), joka muuntaa BookRequestDTO olion Book malliksi käyttäen map metodia, ja toinen on modelToResponseDto(), joka muuntaa Book mallin BookResponseDTO olioksi.
ModelMapper-kirjaston ansiosta olioiden muuntaminen on yksinkertaisempaa ja käytännöllisempää, eikä kenttien manuaalista kopiointia tarvita.
DTO:n lisääminen sovellukseemme
Yhteenveto
DTO (Data Transfer Object) on yksinkertainen olio, joka on tarkoitettu datan siirtämiseen sovelluksen kerrosten tai osien välillä.
Kolmitasoarkkitehtuurin yhteydessä DTO:lla on keskeinen rooli kerrosten eriyttämisessä ja se tarjoaa tehokkaan tavan datan vaihtoon niiden välillä.
Näin ollen DTO on optimaalinen ratkaisu silloin, kun on tarpeen hallita tietoa sovelluksen eri osien välillä ja välttää tarpeettoman tai epäolennaisen datan siirto.
1. Mikä on DTO ohjelmoinnin yhteydessä?
2. Mikä seuraavista on paras käyttötarkoitus DTO:lle?
Kiitos palautteestasi!
