Multi-User-Applikationen objektorientiert realisieren

Bisher hast du Programme für eine Person gebaut. In diesem Modul arbeiten mehrere Benutzerinnen und Benutzer mit unterschiedlichen Rollen gleichzeitig auf denselben Daten. Du strukturierst die Anwendung in Schichten, bildest dein Klassenmodell mit einem ORM auf die Datenbank ab und sicherst gleichzeitige Änderungen mit Transaktionen und Versionierung ab. Dazu kommen Login, Rollen und Berechtigungen, damit jede Person nur sieht und ändert, was sie darf.

Das sind die Fähigkeiten, die am Ende des Moduls sitzen sollten. Jedes Ziel mit einem Beispiel aus dem Lehrbetrieb.

1. 1

   Die Anwendung in klare Schichten gliedern

   Kompetenz A

   Du trennst Darstellung, Geschäftslogik und Datenzugriff in eigene Schichten. Controller nehmen Anfragen entgegen, Services enthalten die Regeln, Repositories sprechen mit der Datenbank. So bleibt die Logik testbar und austauschbar.

   Situation

   In der Ferienplanung einer Gemeindeverwaltung steckt die Prüfung 'maximal 2 Personen pro Team gleichzeitig abwesend' direkt im REST-Controller und zusätzlich nochmals im Frontend.

   Deine Aufgabe

   Verschiebe die Regel an die richtige Stelle und strukturiere das Projekt neu.

   Gutes Ergebnis

   Pakete 'controller', 'service', 'repository', 'domain'. Die Regel liegt in 'FerienService.beantragen()' und ist mit Unit-Tests abgedeckt. Controller und Frontend rufen nur noch den Service auf bzw. zeigen dessen Fehlermeldung.

   SchichtenarchitekturController / Service / RepositoryDTODependency Injection
2. 2

   Das Klassenmodell mit einem ORM auf die Datenbank abbilden

   Kompetenz B

   Du beschreibst mit Annotationen oder Konfiguration, wie Klassen und Beziehungen zu Tabellen und Fremdschlüsseln werden. Du kennst die Fallen beim Laden von Beziehungen und vermeidest unnötig viele Datenbankabfragen.

   Situation

   Ein Ticketing-Tool der IT-Abteilung eines Spitals lädt die Ticketliste mit 200 Einträgen in 6 Sekunden. Im Log stehen 201 SQL-Abfragen.

   Deine Aufgabe

   Finde die Ursache und optimiere das Laden.

   Gutes Ergebnis

   Die Beziehung Ticket zu Melder wird pro Ticket einzeln nachgeladen (N+1-Problem). Mit einem Fetch-Join bzw. 'Include' braucht es noch eine Abfrage, die Liste lädt in 0.3 Sekunden.

   Entity@OneToMany / @ManyToOneLazy vs. Eager LoadingN+1-ProblemMigration
3. 3

   Gleichzeitige Änderungen ohne Datenverlust behandeln

   Kompetenz C

   Wenn zwei Personen denselben Datensatz gleichzeitig bearbeiten, darf die zweite Speicherung die erste nicht still überschreiben. Du setzt Transaktionen und Optimistic Locking mit Versionsnummer ein und zeigst Benutzenden verständlich, was passiert ist.

   Situation

   In einem Lagerverwaltungstool eines Getränkehändlers in Rapperswil buchen zwei Mitarbeitende gleichzeitig Harasse aus. Danach stimmt der Bestand um 15 Harasse nicht.

   Deine Aufgabe

   Verhindere, dass sich gleichzeitige Buchungen gegenseitig überschreiben.

   Gutes Ergebnis

   Die Entity 'Artikel' bekommt ein '@Version'-Feld. Die zweite Buchung scheitert mit einer OptimisticLockException (in Spring: ObjectOptimisticLockingFailureException), der Service lädt den aktuellen Stand in einer neuen Transaktion und wiederholt die Buchung einmal. Im UI erscheint bei echten Konflikten: 'Der Bestand wurde inzwischen geändert, bitte prüfen.'

   TransaktionACIDOptimistic LockingPessimistic LockingLost Update
4. 4

   Login, Rollen und Berechtigungen umsetzen

   Kompetenz D

   Du baust eine Anmeldung ein und legst fest, welche Rolle welche Aktionen ausführen darf. Die Prüfung passiert immer serverseitig, auch wenn das Frontend Buttons bereits ausblendet.

   Situation

   In der Ferienplanung können normale Mitarbeitende über die API ihre eigenen Anträge selbst bewilligen, weil nur das Frontend den Button ausblendet.

   Deine Aufgabe

   Sichere die Bewilligung so ab, dass nur Teamleitende eigene Teammitglieder bewilligen können.

   Gutes Ergebnis

   Rollen 'MITARBEITER', 'TEAMLEITUNG', 'HR'. Der Endpunkt verlangt die Rolle TEAMLEITUNG, der Service prüft zusätzlich, ob der Antrag zum eigenen Team gehört. Ein Test mit einem Mitarbeiter-Token erwartet Status 403.

   AuthentifizierungAutorisierungRolleJWT / SessionPrinzip der minimalen Rechte
5. 5

   Daten pro Benutzer, Team oder Mandant sauber trennen

   Kompetenz D

   Viele Anwendungen bedienen mehrere Teams, Standorte oder Kunden. Du stellst sicher, dass jede Abfrage automatisch auf die Daten eingeschränkt wird, die zur angemeldeten Person gehören, statt dich auf IDs aus der URL zu verlassen.

   Situation

   Ein Treuhandunternehmen mit Filialen in Chur und Davos nutzt ein Tool für Kundendossiers. Wer in der URL die ID ändert, sieht Dossiers der anderen Filiale.

   Deine Aufgabe

   Verhindere den Zugriff auf fremde Dossiers zuverlässig.

   Gutes Ergebnis

   Alle Repository-Abfragen filtern nach der Filiale aus dem Login-Token. Zugriff auf eine fremde ID liefert 404. Ein Integrationstest prüft genau diesen Fall für Lesen, Ändern und Löschen.

   MandantenfähigkeitDatenisolationIDOROwner-Prüfung
6. 6

   Die Anwendung über alle Schichten testen und ausliefern

   Kompetenz E

   Neben Unit-Tests für die Services schreibst du Integrationstests gegen eine echte Testdatenbank und prüfst Berechtigungen und Konflikte automatisiert. Das Ganze lässt sich mit Docker reproduzierbar starten.

   Situation

   Vor dem Go-live des Ticketing-Tools will die Teamleitung Sicherheit, dass Rollen und gleichzeitige Bearbeitung funktionieren.

   Deine Aufgabe

   Erstelle eine Testsuite, die die kritischsten Fälle abdeckt.

   Gutes Ergebnis

   25 Unit-Tests für die Services, 12 Integrationstests mit Testcontainers und PostgreSQL, darunter Rollenprüfungen und ein Test mit zwei parallelen Updates. Ein 'docker compose up' startet App, DB und Keycloak für die Abnahme.

   IntegrationstestTestcontainersTestdatenDocker Compose

Die Kompetenzmatrix zerlegt das Modul in Themenstränge und drei Stufen. Für den Kompetenznachweis solltest du überall mindestens Stufe 2 erreichen. Dein Stand bleibt in diesem Browser gespeichert und färbt Lernweg und Übungen ein.

Ramon ist im 3. Lehrjahr als Informatiker Applikationsentwicklung bei der Infra Kommunal AG in Wil SG, einem IT-Dienstleister mit 85 Mitarbeitenden, der für zwölf Gemeinden arbeitet. Turnhallen und Gemeindesäle werden dort heute per Telefon und Excel reserviert, Doppelbelegungen sind an der Tagesordnung. Ramon soll eine Webapplikation bauen, über die Vereine reservieren und Hauswarte die Anfragen genehmigen.

1. Kapitel 1

   Saal, Verein, Reservation

   Ramon zeichnet ein Klassendiagramm mit Gemeinde, Raum, Verein, Reservation und Benutzer und baut darauf ein Spring-Boot-Projekt mit Controller, Service und Repository auf. In seinem ersten Entwurf liegt die Prüfung auf Überschneidungen im Controller. Sein Berufsbildner fragt, was passiert, wenn später eine App dieselbe Logik braucht, worauf Ramon die Regel in den Service verschiebt. Mit DTOs stellt er zudem sicher, dass keine Passwort-Hashes im JSON landen.

   Ziel 1

2. Kapitel 2

   Die langsame Wochenübersicht

   Ramon bildet die Entities mit JPA ab und verwaltet das Schema mit Flyway-Migrationen. Die Wochenübersicht einer Turnhalle braucht 2.8 Sekunden, und im SQL-Log zählt er 340 Abfragen, weil die Vereine der Reservationen einzeln nachgeladen werden (eine Abfrage pro Verein). Mit einem Fetch Join sind es noch drei Abfragen und 180 Millisekunden. Einen Index auf Raum und Datum ergänzt er gleich mit.

   Ziel 2

3. Kapitel 3

   Zwei Vereine, eine Turnhalle

   Beim Test reservieren zwei Vereine gleichzeitig die Turnhalle für Dienstag um 19 Uhr, und beide erhalten eine Bestätigung. Optimistic Locking hilft hier nicht, weil zwei neue Datensätze entstehen. Ramon ergänzt deshalb eine Exclusion-Constraint in PostgreSQL, die überlappende Zeiträume pro Raum verhindert. Für das Bearbeiten bestehender Reservationen führt er ein Versionsfeld ein und zeigt die Meldung "Diese Reservation wurde inzwischen geändert".

   Ziel 3

4. Kapitel 4

   Nur die eigene Gemeinde

   Ramon richtet Keycloak mit den Rollen Vereinsverantwortliche, Hauswart und Gemeindeadmin ein. Beim Test mit dem Token eines Hauswarts aus Gemeinde A sieht er über den Parameter gemeinde=7 alle Reservationen einer anderen Gemeinde. Er liest die Gemeinde nun ausschliesslich aus dem Token und setzt sie mit einem Hibernate-Filter in jede Abfrage. Im Frontend erscheint der Genehmigen-Button nur für Hauswarte, der Server prüft die Rolle aber zusätzlich.

   Ziel 4Ziel 5

5. Kapitel 5

   Abnahme mit der Gemeinde

   Ramon schreibt 24 Integrationstests mit Testcontainers für Rollen, Mandantentrennung und Doppelbuchungen, letztere mit zwei parallelen Threads. Mit Docker Compose startet er App, PostgreSQL, Keycloak und Frontend mit einem einzigen Befehl. Der Gemeindeschreiberin übergibt er einen Testplan mit zehn Szenarien. Sie findet, dass Serienreservationen für wöchentliche Trainings fehlen, was als nächster Punkt ins Backlog kommt, bevor zwei Gemeinden den Pilotbetrieb starten.

   Ziel 6

1. 1

   Architektur und Domänenmodell

   ca. 4 Std.

   Du planst die Anwendung: Klassenmodell, Schichten und Rollen, bevor du loslegst.

   • Für eine Ferienplanung das Klassendiagramm mit allen Beziehungen zeichnen
   • Eine Rollen-Rechte-Matrix für drei Rollen erstellen
   • Ein Spring-Boot- oder ASP.NET-Projekt mit sauberer Paketstruktur aufsetzen

   Trainiert Kompetenz A1A2

   Lernziel1

2. 2

   Persistenz mit ORM

   ca. 6 Std.

   Du bildest dein Modell auf eine relationale Datenbank ab und lernst, was das ORM im Hintergrund tut.

   • Entities mit 1:n- und n:m-Beziehungen definieren und Migrationen erzeugen
   • SQL-Logging einschalten und die erzeugten Abfragen lesen
   • Ein N+1-Problem absichtlich erzeugen und beheben

   Trainiert Kompetenz B1B2

   Lernziel2

3. 3

   Wenn zwei gleichzeitig klicken

   ca. 5 Std.

   Du erlebst Konflikte bei gleichzeitigen Änderungen und behebst sie mit Transaktionen und Versionierung.

   • Mit zwei Browserfenstern denselben Datensatz bearbeiten und den Verlust beobachten
   • Optimistic Locking einführen und eine verständliche Konfliktmeldung bauen
   • Transaktionsgrenzen im Service bewusst setzen und mit einem Test prüfen

   Trainiert Kompetenz C1C2

   Lernziel3

4. 4

   Wer darf was?

   ca. 6 Std.

   Du sicherst die Anwendung mit Login, Rollen und Datentrennung ab.

   • Anmeldung mit Spring Security, ASP.NET Identity oder Keycloak einrichten
   • Endpunkte nach Rollen absichern und Owner-Prüfungen im Service ergänzen
   • Mit Postman versuchen, fremde Daten über manipulierte IDs zu lesen

   Trainiert Kompetenz D1D2

   Lernziel45

5. 5

   Frontend anbinden

   ca. 5 Std.

   Du verbindest ein Frontend mit der API und zeigst je nach Rolle unterschiedliche Funktionen an.

   • Login-Ablauf im Frontend umsetzen und Token sicher verwenden
   • Konfliktmeldungen und 403-Fehler benutzerfreundlich anzeigen
   • Menüpunkte je nach Rolle ein- und ausblenden, ohne die Serverprüfung zu ersetzen

   Trainiert Kompetenz D2A3

   Lernziel41

6. 6

   Testen und ausliefern

   ca. 4 Std.

   Du sicherst die kritischen Fälle mit automatisierten Tests ab und machst die Anwendung reproduzierbar startbar.

   • Integrationstests mit Testcontainers für Rollen und Konflikte schreiben
   • Docker Compose mit App, Datenbank und Identity-Provider erstellen
   • Die Anwendung einer Kollegin vorführen und sie gezielt versuchen lassen, Regeln zu umgehen

   Trainiert Kompetenz E2E3C3D3

   Lernziel635

Multi-User-Applikation

Anwendung, die von mehreren Personen gleichzeitig mit gemeinsamen Daten genutzt wird.

ORM

Object-Relational Mapping: Technik, die Objekte automatisch in Tabellenzeilen übersetzt und umgekehrt.

DTO

Data Transfer Object: schlanke Klasse, die nur die Daten für eine Schnittstelle enthält.

Transaktion

Gruppe von Datenbankänderungen, die gemeinsam gelingen oder gemeinsam rückgängig gemacht werden.

Optimistic Locking

Konflikterkennung über eine Versionsnummer, ohne Datensätze vorher zu sperren.

Lost Update

Eine Änderung geht verloren, weil eine gleichzeitige zweite Änderung sie überschreibt.

IDOR

Insecure Direct Object Reference: Zugriff auf fremde Daten durch Ändern einer ID in der Anfrage.

Mandant

Abgegrenzte Organisationseinheit (z.B. Kunde oder Filiale), deren Daten von anderen getrennt bleiben müssen.

Passende Module