Vor kurzem bin ich zufällig über Patchlevel’s EventSourcing-Package gestolpert und beim Durchstöbern der Doku über den Hydrator gestolpert. Ein Genuss.

Kurz für alle, die mit dem Begriff Hydrator wenig anfangen können: Wenn wir Devs von Hydration sprechen, meinen wir das Umwandeln von Daten in andere Formate. In der Regel geht es darum, ein einfaches Format wie JSON in ein Objekt zu transformieren.

Nehmen wir mal folgendes Beispiel an…

Wir haben eine API, die unter anderem das Konzept eines Produktes kennt.

{
    "title": "Cheesecake",
    "gtin": "0000000000000",
    "price": "EUR 500.00",
    "nutrientDetails": [
        { "typeCode": "HEART", "name": "Eine Portion Liebe" },
        { "typeCode": "TROLL", "name": "Halber Kuchen" },
        { "typeCode": "TROLL", "name": "Halber Käse" }
    ]
}

Das Produkt enthält einige Eigenschaften wie Titel, GTIN und Preis.

Wenn Entwicklungskonzepte und Domain-Konzepte stark voneinander abweichen, laufen wir als Entwickler häufig in technische oder auch unlogische Probleme – einer der Gründe wenn Entwickler von „Sonderfall“ sprechen.

Um solche Sonderfälle zu vermeiden, gibt es zwei Schritte:

1. Applikationsseitig Vertrauen aufbauen.
2. Und (idealerweise) Entwicklungskonzepte näher an die Domain-Konzepte heranführen.

Vertrauen lässt sich in objektorientierter Entwicklung leicht mit Interfaces aufbauen. Ein Interface definiert Eigenschaften und Methoden, und steuert, wer diese nutzen darf.

Zurück zu unserer API: Wenn wir Vertrauen mit Interfaces aufbauen, ergibt es Sinn, über das Interface eines Produktes nachzudenken.

Das könnte dann so aussehen:

class Product
{
    public function __construct(
        private string $title,
        private string $gtin,
        private string $price,
        private array $nutrientDetails
    ) {}

    public function getTitle(): string
    {
        return $this->title;
    }
    ...
}

Fertig, oder?

Jein. Stellen wir uns nun vor, wir bauen die Klasse an vielen verschiedenen Stellen auf, z.B. beim Erstellen, Bearbeiten, Anzeigen oder Referenzieren eines Produktes. Hier lauern weitere Herausforderungen: Wir brauchen einen einfachen und vertrauenswürdigen Weg, um solche Klassen zu instanziieren.

Und genau da kommt ein Hydrator ins Spiel.

Kurz gesagt: Patchlevel bastelt an einer äußerst schmackhaften EventSourcing-Library und hat ihren Hydrator in eine eigene Library gepackt. Ich bin äußerst dankbar.

Dinge, die ich an patchlevel/hydrator schätze:

• Intuitiv!
• Erweiterbar.
• IDE-Unterstützung, die ihresgleichen sucht.
• Einfaches Normalisieren von Objekten und Arrays über Attributes.

Um zu unserem Beispiel zurückzukehren:

$hydrator = new MetadataHydrator();

// Von Array zum Objekt
$product = $hydrator->hydrate(
    Product::class,
    [
        'title' => 'Cheesecake',
        'gtin' => '0000000000000',
        'price' => 'EUR 500.00',
        'nutrientDetails' => [
            [ 'typeCode' => 'HEART', 'name' => 'Eine Portion Liebe' ],
            [ 'typeCode' => 'TROLL', 'name' => 'Halber Kuchen' ],
            [ 'typeCode' => 'TROLL', 'name' => 'Halber Käse' ],
        ],
    ]
);

// Von Objekt zu Array
$asArray = $hydrator->extract($product);

Goil.