Abstrakte Modelle und @type

Worum es geht

Manchmal gibt es von einer Sache mehrere Arten, die vieles gemeinsam haben, aber nicht alles. Ein Kunde kann ein Privatkunde (mit Geburtsdatum) oder ein Firmenkunde (mit Handelsregisternummer) sein. Beide haben Name, Adresse und Aufträge.

Dafür gibt es abstrakte Modelle: ein Obermodell mit den gemeinsamen Feldern und mehrere konkrete Untermodelle, die davon erben.

classDiagram
    class kunde {
        <<abstrakt>>
        name
        adresse
        auftraege
    }
    class privatkunde {
        geburtsdatum
    }
    class firmenkunde {
        handelsregisternummer
    }
    kunde <|-- privatkunde
    kunde <|-- firmenkunde

Der Typ: @type

Jedes Objekt trägt seinen konkreten Typ. In der Datenbank steht er in der Spalte _MODELTYPE, im JSON heißt er @type. Der Wert ist der API-Pfad des Untermodells mit Punkten statt Schrägstrichen:

Die Hub-API: ein Eingang, mehrere Ziele

Für das abstrakte Modell erzeugt der Generator eine Hub-API mit den üblichen Pfaden, hier /api/rest/crm/kunde/…. Sie macht selbst nichts, sondern leitet jede Anfrage an die API des richtigen Untertyps weiter. Jeder Untertyp hat außerdem seine eigene, normale API.

flowchart LR
    C(["Client"]) --> H["Hub-API<br/>/crm/kunde"]
    H -->|"@type = crm.privatkunde"| P["API<br/>/crm/privatkunde"]
    H -->|"@type = crm.firmenkunde"| F["API<br/>/crm/firmenkunde"]
    C -.->|direkt| P
    C -.->|direkt| F

Woher die Hub-API den Typ kennt, hängt von der Operation ab:

Alle Operationen im Ablauf

Suchen über alle Untertypen: zwei Phasen

Eine Suche an der Hub-API muss Objekte verschiedener Typen in einer Liste liefern, richtig sortiert und geblättert. Das geht in zwei Phasen:

sequenceDiagram
    participant C as Client
    participant H as Hub-API /crm/kunde
    participant DB as Datenbank
    participant P as API privatkunde
    participant F as API firmenkunde
    C->>H: POST /query (Filter, Sortierung, Seite)
    Note over H,DB: Phase 1: nur IDs und Typen
    H->>DB: SELECT id, _MODELTYPE ... WHERE ... ORDER BY ... LIMIT
    DB-->>H: [ (id1, privat), (id2, firma) ] + totalCount
    Note over H,F: Phase 2: jede Zeile über ihren Untertyp lesen
    par parallel
        H->>P: read id1
    and
        H->>F: read id2
    end
    P-->>H: Objekt 1
    F-->>H: Objekt 2
    H-->>C: data in der Reihenfolge von Phase 1 + meta

Rechte und Filter

Jeder Untertyp ist ein vollständiges Modell mit eigenen Rollen. Wer über die Hub-API liest, braucht deshalb die Leserechte des Untertyps, zu dem das Objekt gehört. Attributfilter des Obermodells gelten automatisch auch für alle Untertypen: Ein Untertyp ist nie ein Weg an den Regeln des Obermodells vorbei.

In der Datenbank

Das Obermodell hat eine eigene Tabelle mit den gemeinsamen Feldern und der Spalte _MODELTYPE. Jeder Untertyp hat eine eigene Tabelle mit seinen zusätzlichen Feldern, verbunden über dieselbe id.

Die Firma steht mit ihren eigenen Feldern in der Tabelle firmenkunde.

Fallen