Was ist eigentlich ein DTO?

Java • 26. Mai 2025 • Lesezeit: 4 Minuten

In der Welt der Java-Entwicklung stößt man früher oder später auf den Begriff DTO – kurz für Data Transfer Object. Gerade in größeren Anwendungen oder beim Arbeiten mit Daten aus Datenbanken, REST-Schnittstellen oder Microservices ist es ein häufig verwendetes Muster. Doch was genau ist ein DTO, warum braucht man es, und wie unterscheidet es sich von anderen Objekten wie POJOs oder Java Records?
DTO steht für Data Transfer Object. Es handelt sich um ein einfaches Java-Objekt, das nur Daten enthält, ohne jegliche Logik. Es wird verwendet, um strukturierte Informationen von einer Schicht zur anderen zu transportieren – z. B. vom Backend zur UI, zwischen Services oder über das Netzwerk hinweg.

Das besondere ist, dass ein DTO nur aus Feldern (also Variablen) besteht sowie die entsprechenden Getter und Setter und keine Abhängigkeiten zu Services oder Datenbankklassen hat.

Beispiel für ein DTO:

public class UserDTO {
    private String name;
    private String email;

    public UserDTO() {}

    public UserDTO(String name, String email) {
        this.name = name;
        this.email = email;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

Dieses Objekt ist ein typisches DTO – es enthält nur Daten und keinerlei Business-Logik.

Wann benutzt man ein DTO?

DTOs sind sinnvoll, wenn du:

• Daten zwischen verschiedenen Systemen überträgst (z. B. per JSON über eine REST-API)
• nicht alle Daten eines komplexen Objekts weitergeben möchtest
• unterschiedliche Darstellungen desselben Objekts benötigst (z. B. für verschiedene Frontends)
• Schichten entkoppeln willst (z. B. Service und Datenbankmodell)

Vorteile von DTOs

• Kapselung: Du gibst nur das weiter, was wirklich gebraucht wird.
• Flexibilität: Du kannst verschiedene DTOs für unterschiedliche Zwecke definieren (z. B. UserCreateDTO, UserResponseDTO).
• Sicherheit: Du vermeidest, dass sensible Daten (z. B. Passwörter) versehentlich mitgesendet werden.
• Unabhängigkeit von der Datenbankstruktur (ORM, JPA etc.)

Nachteile von DTOs

• Mehr Code: Für jedes DTO musst du eine eigene Klasse schreiben.
• Mapping-Aufwand: Es ist zusätzlicher Aufwand nötig, um Entities ↔ DTOs zu konvertieren (z. B. mit MapStruct oder manuell).
• Doppelung von Strukturen: Häufig ähneln sich DTOs und Entitäten stark.

DTO vs. POJO – was ist der Unterschied?

Ein POJO (Plain Old Java Object) ist ein ganz allgemeines, einfaches Java-Objekt. Ein DTO ist ein POJO – aber nicht jedes POJO ist ein DTO.

Beispiel für ein POJO mit Logik:

public class Product {
    private double price;
    private double taxRate;

    public double getGrossPrice() {
        return price * (1 + taxRate);
    }

    // Getter & Setter ...
}

Dieses Objekt enthält Logik (Berechnung des Brutto-Preises) – es ist also kein reines DTO, sondern ein Domänenobjekt oder Modell.

Java Records als DTOs

Seit Java 14 (Preview) und stabil ab Java 16 gibt es Records – eine neue Art, einfache Datencontainer zu schreiben.

public record UserDTO(String name, String email) {}

Das entspricht funktional dem ersten DTO oben – nur viel kompakter!

Vorteile von Records:

• Weniger Code
• Automatisch generierte equals(), hashCode(), toString()
• Immutable (nur lesbar, keine Setter)
• Perfekt für DTOs, die nur gelesen werden sollen

Wann lieber keine Records?

• Wenn du mutierbare Objekte brauchst (Records sind final)
• Wenn du Frameworks nutzt, die Standard-Konstruktoren oder Setter brauchen (z. B. manche JSON-Mapper)

Fazit:

DTOs helfen dir, deine Architektur klarer, sicherer und flexibler zu gestalten. Auch wenn sie etwas mehr Schreibarbeit verursachen, lohnt sich ihr Einsatz bei:

• APIs und REST-Schnittstellen
• Mehrschichtigen Architekturen (Controller → Service → Repository)
• Separierung von Domäne und Darstellung

Wenn du einfache DTOs brauchst, die nicht verändert werden sollen, sind Records eine elegante Lösung.