Co raz cześciej przychodzi mi pisać aplikacje w środowisku rozproszonym to też dzisiejszy, inauguracyjny wpis będzie o Data Transfer Object – Obiekt Transferu Danych, zwany także przez niektórych jako Value Object. W skrócie
“Obiekt przenoszący dane pomiędzy procesami, umożliwiający zmniejszenie ilości wywoływanych metod“ M. Fowler
Tylko co się za tym kryje? Jednym z wielu problemów używania obiektów rozproszonych jest ich koszt wywołania. To czas, który trzeba ponieść, by wywołać zdalną metodę. W przypadku wywołań we wspólnej przestrzeni adresowej danego procesu, nie musimy przejmować się tym czasem. Natomiast sytuacja radykalnie się zmienia, kiedy potrzebujemy wywołać metodę na innym procesorze, w szczególności gdy ów procesor znajduje się na drugim krańcu kuli ziemskiej.
Jednym ze sposóbów radzenia sobię z tym problem jest zmniejszenie ilości wywołań takich metod. Można do tego podejść po przez przesłanie większej ilości danych niż jest to konieczne za jednym razem. Nie jest to jednak takie proste w implementacji. Niektóre języki programowania jak np. Java wymuszają zwrócenie tylko jednej wartości. Dlatego tutaj z pomocą przychodzi nam wzorzec Data Transfer Object, który z pozoru wygląda jak klasa mająca jedynie swoje pola, akcesory i mutatory. Jednakże dodatkowo owa klasa wzbogacana jest o serializacje…
Serializacja
To właśnie dzięki niej, DTO jest w stanie przesłać całą swoją zawartość przez sieć w jednym wywołaniu. Natomiast konkretny używany format zapisu zależy już od programów. Wiele języków programowania jak np. PHP czy Java posiadają gotowe do tego mechanizmy. Trzeba jednak pamiętać, aby zarówno klient jak i serwer używały tego samego mechanizmu. Pewnym dylematem jest czy wybrać serializacje do postaci binarnej czy tekstowej np. XML, JSON. Kuszące jest to drugie rozwiązanie ze względu na łatwość odczytu, ale wymaga to większej przepustowości. Innym problemem jest synchronizacja obiektów transferu danych pomiędzy komunikującymi się stronami. Gdy serwer zmienia dane, taka aktualizacja powinna zajść także po stronie klienta…w teorii. W praktyce po prostu dostaniemy błąd.
Jak utworzyć taki obiekt DTO ?
Zdaniem Fowlera takie obiekty nie powinny być częścią dziedziny, ale też obiekty dziedziny nie powinny być zależne od obiektów transferu danych (bo struktura tych drugich może się zmieniać wraz ze zmianami formatów przesyłanych danych). Tutaj Fowler sugeruje użycie “obiektów grupujących” / “asemblerów“, czyli obiektów tworzących DTO używajac interfejsów modelu dziedziny. Takie obiekty grupujące przypominają wzorzec Mapper, mapują obiekt dziedziny na obiekt transferu danych.
Na zakończenie, warto nadmienić, że DTO całkiem fajnie współpracuje z innym wzorcem – Remote Facade, ale o tym kiedy indziej…
Więcej informacji na ten temat w ksiażce “Architektura Systemów Zarządzania Przedsiębiorstwem. Wzorce projektowe“. M. Fowler.