Z czym się je DTO – data transfer object patern

Co to jest DTO (Data Transfer Object) i dlaczego warto go używać?

Podstawową ideą korzystania z DTO (data transfer object patern) jest oddzielenie danych od logiki biznesowej i funkcji specyficznych dla aplikacji. Jest to szczególnie interesujące w przypadkach, gdy trzeba przekazać dane do innej warstwy (np. z warstwy modelu do warstwy widoku) lub otrzymać dane z innej usługi (zewnętrzny interfejs API, mikrousługa itp.).

W końcu DTO to tylko prosta struktura danych, która zawiera różne właściwości wbudowanych typów danych (lub innych DTO). Zaletą egzekwowania tego ograniczenia jest wymienność między systemami i serializowalność.

Na przykład, gdy wysyłamy zapytanie do tabeli bazy danych Students, nie chcemy uwidaczniać wszystkich kolumn danych w bazie danych, ale wysyłamy tylko minimalną ilość informacji do konsumenta, dlatego definiujemy DTO (StudentDTO) w celu reprezentowania pożądanej struktury danych i konwertujemy jednostki Student na obiekty StudentDTO. Typowa implementacja jest podobna do poniższego kodu.

 ...
class StudentDTO()
{
 	public function __construct(
     	public string $firstname,
        public string $surname
         ...
    ){}

 ...
}

  ...
public function Task(StudentDTO $student)
{
   ...
  
   ...
}

Z kodu wynika, że definicja klasy StudentDTO zawiera tylko ograniczone właściwości danych i nie ma metody zachowania. Klasa StudentDTO jest jedynie wykorzystywana jako „prosty worek” dla informacji przekazywanych z bazy danych do jej odbiorców.

Dlaczego warto go używać?

• Jeśli nie używasz DTO, prawdopodobnie ujawniasz wewnętrzne struktury danych.
• Powodem, dla którego chcesz używać DTO, jest to, że chcesz, aby klienci łączyli się z tą umową (jest to struktura danych, która jest umową między producentem a konsumentem), a nie z wewnętrznymi strukturami danych. Pozwala to na swobodne modyfikowanie i rozwijanie elementów wewnętrznych bez łamania klientów.
• Podczas tworzenia interfejsu API HTTP chodzi o reprezentacje. Najczęściej klienci potrzebują bogatej reprezentacji zasobu, a nie tylko serializowanej wersji encji bazy danych. Często potrzebują powiązanych danych. Posiadanie interfejsu API zwracającego bogate reprezentacje oznacza, że musisz wykonać pewien poziom kompozycji, aby utworzyć obiekt, a nie tylko jednostkę bazy danych, która zostanie serializowana. W tym miejscu do gry wkracza DTO.
• W momencie, gdy chcesz zmienić wewnętrzne obiekty danych, musisz teraz zaktualizować klientów.

Kiedy korzystać z DTO?

Jak wspomniałem wcześniej, DTO powinny być używane za każdym razem, gdy dane są przenoszone między warstwami i systemami. Tak więc, jak na mój osobisty gust, wszystko, co jest czymś więcej niż parą (key, value) i poruszanie się między warstwami, powinno być DTO. 

Kiedy nie korzystać z DTO?

Oczywiście zdefiniowanie DTO, który przechowuje tylko jedną właściwość, może być przesadą (nawet jeśli istnieją przypadki, w których można poprawić zrozumiałość, robiąc to).