Wpis z mikrobloga

#programowanie #java #dto
Mirki, przepisuję obecnie średniej wielkości aplikację webową (spring + angular 4) i teraz się zastanawiam czy korzystać z mechanizmu DTO. Możecie mi podać PRAKTYCZNE przykłady w których pomocne byłoby mapowanie obiektów na DTO. Wcześniej pisałem aplikację bez DTO, ale teraz ją przepisuję i się zastanawiam czy od razu nie wprowadzić DTO.
  • 6
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@Patres: to w jakiej formie przesyłałeś dane?

Wiadomo, jeśli piszesz CRUDa, gdzie możesz spokojnie obfuskować wrażliwe dane z encji, możesz je pchać bezpośrednio do rządań/odpowiedzi, ale jeśli model danych jest trochę bardziej skomplikowany, użycie DTO wydaje się rozsądne.
  • Odpowiedz
Możecie mi podać PRAKTYCZNE przykłady w których pomocne byłoby mapowanie obiektów na DTO.


@Patres: jeśli masz na myśli po prostu Data Transfer Object, czyli coś co w praktyce jest zestawem danych dla widoku, to korzyści widziałbym takie:
- architektura: rozdzielenie warstwy widoku od warstwy dostępu do danych (co np. pozwala implementować frontend niezależnie od jpa), inaczej przepychasz encję przez wszystkie warstwy
- bezpieczeństwo: wypychając encję bezpośrednio do przeglądarki jako JSON
  • Odpowiedz
@fegwegw: Dzięki za odpowiedz! Dane wysyłam jako springowy obiekt ResponseEntity i odbieram je jako JSON w angularze.

Wiadomo, jeśli piszesz CRUDa, gdzie możesz spokojnie obfuskować wrażliwe dane z encji, możesz je pchać bezpośrednio do rządań/odpowiedzi, ale jeśli model danych jest trochę bardziej skomplikowany, użycie DTO wydaje się rozsądne.


Właśnie większość obiektów wysyłam 1:1. Może jedną klasę mam bardziej skomplikowaną, którą trochę inaczej wysyłam (dodaję dodatkowe pola). Dlatego myślałem, żeby większość
  • Odpowiedz
@Patres: problemem jest to ze jak chcesz przeorac strukture encji w bazie to przy okazji ci sie zepsuja widoki. A jak masz dto to po stronie backendu inaczej mapujesz i front dostaje to samo :)
  • Odpowiedz