Generierter Code und eigener Code

Worum es geht

In einem CDMS-Projekt gibt es zwei Sorten Code. Den generierten Code erzeugt der Build aus dem Modell im Hub, siehe Codegenerierung im Build. Den eigenen Code schreibst du: Fachlogik, die sich nicht modellieren lässt.

Die beiden liegen an verschiedenen Orten und haben verschiedene Besitzer. Wer das trennt, kann jederzeit neu generieren, ohne etwas zu verlieren.

Wer wo wohnt

flowchart TB
    subgraph T["target/generated-sources/ · generiert, bei jedem Build neu"]
        A["OrderApi"] --> S["OrderSystem"] --> D["OrderDatabase"]
        S --> AL["OrderAuthorizationLayer"]
        M["OrderEntity, OrderDto, Payloads, Mapper, MetaService"]
    end
    subgraph SRC["src/main/java/ · deins, im Repository"]
        H["OrderHook<br/>(Hook)"]
        F["OrderFilter<br/>(Filter)"]
        C["eigener Controller<br/>oder Service"]
        ST["Start.java<br/>(einmal erzeugt)"]
    end
    subgraph R["src/main/resources/ · deins"]
        Y["application.yaml"]
    end
    H -. "wird aufgerufen von" .-> S
    F -. "wird gefragt von" .-> S
    C -- "ruft auf" --> S

Wohin mit meiner Logik?

Hooks

Ein Hook ist eine Klasse, die CDMS bei jeder Operation auf ein Modell aufruft. Du schreibst sie für die Entity des Modells:

@Service
@Order(100)
public class OrderHook implements HookServiceInterface<OrderEntity> {

  @Override
  public void beforeDatabaseChange(OrderEntity item, CmsMethods method)
      throws AbstractCodamaiException {
    if (method == CmsMethods.CREATE && item.getOrderNr() == null) {
      item.setOrderNr(nextNumber());
    }
  }

  @Override
  public void afterDatabaseChange(OrderEntity item, CmsMethods method)
      throws AbstractCodamaiException {
    // e.g. publish an event
  }

  @Override
  public void fieldBeforeDatabaseChange(OrderEntity item, String field, CmsMethods method) { }

  @Override
  public void fieldOnDatabaseRead(OrderEntity item, String field, CmsMethods method) { }
}

Die Arbeit machen beforeDatabaseChange (vor dem Schreiben, in der Transaktion) und afterDatabaseChange (nach dem Schreiben, beim Lesen nach dem Laden). Wirft ein Hook eine AbstractCodamaiException, bricht die ganze Operation ab und die Transaktion wird zurückgerollt. Wann genau welcher Hook läuft, steht unter Hooks: Arten und Zeitpunkte und Reihenfolge der Hooks.

Eigene Filter

Ein Filter schränkt jede Suche auf ein Modell ein, bevor sie die Datenbank erreicht. Er arbeitet mit dem DTO des Modells. Der häufigste Fall ist ein Attributfilter: Jeder Benutzer sieht nur die Zeilen, deren Feld zu einem Attribut in seinem Token passt. Dafür gibt es die fertige Basisklasse AbstractAttributeFilter:

@Service
public class OrderFilter extends AbstractAttributeFilter<OrderDto> {
  @Getter
  private final String dataAttribute = "companyId";   // field on the model
  @Getter
  private final String profileAttribute = "company";  // attribute in the user's token
}

Brauchst du eine andere Logik, implementierst du CdmsFilterInterface<OrderDto> direkt und lieferst in get() einen eigenen Suchfilter. Legst du im Hub einen Zugriffsfilter an, erzeugt der Generator die Filterklasse selbst. Mehr unter Attributfilter und Eigene Datenfilter.

Eigene Controller und Services

Für fachliche Abläufe, die über Anlegen, Lesen, Ändern und Löschen hinausgehen, schreibst du einen normalen Spring-@RestController. Er ruft die generierten System-Layer auf. So laufen auch seine Zugriffe durch Rechteprüfung, Validierung und Hooks.

Den generierten OrderApi erweiterst oder ersetzt du dagegen nicht. Die generierten Beans haben feste Namen. Eine zweite Bean mit demselben Namen verhindert den Start der Anwendung.

Konfiguration

Was sich an CDMS einstellen lässt, steht in application.yaml oder kommt aus der Umgebung:

Fallen