Ein Vorgang, der Hunderte von Datensätzen ändert, kann den Regeln entsprechen und dennoch mehr Daten betreffen als erwartet. Eine allgemeine Bestätigung wie „Sind Sie sicher?“ macht es nicht möglich, den Umfang einzuschätzen oder unerwartete Bedingungen zu erkennen. Eine Vorschau von Änderungen in PHP sollte zeigen, welche Datensätze betroffen wären, welche Werte sich ändern würden und unter welchen Bedingungen der Vorgang ausgeführt werden könnte.
Eine Vorschau verringert Überraschungen, garantiert aber nicht, dass die spätere Ausführung genau dasselbe Ergebnis liefert. Zwischen beiden Phasen können sich Daten, Berechtigungen oder der Umfang des Vorgangs ändern. Das Design sollte diese Unsicherheit sichtbar machen und vor dem Schreiben alles Erforderliche erneut validieren.
Wann eine Vorschau Mehrwert bietet
Bei umfangreichen, sensiblen oder schwer rückgängig zu machenden Vorgängen empfiehlt sich eine Vorschau: etwa beim Aktualisieren von Preisen, Ändern von Statuswerten, Neuzuweisen von Konten, Löschen von Informationen oder Neuberechnen abgeleiteter Daten. Sie ist auch dann nützlich, wenn die Person, die den Vorgang startet, dessen Auswirkungen prüfen oder vor der Ausführung eine Genehmigung einholen muss.
Nicht jede Aktion benötigt eine Vorschauoberfläche. Ist ein Vorgang klein, lässt er sich rückgängig machen und ist sein Ergebnis eindeutig, kann eine kontextbezogene Bestätigung genügen. Kann dagegen nicht erkannt werden, was eine Bestätigung bedeutet, müssen konkrete Daten angezeigt werden, statt einen weiteren Dialog hinzuzufügen.
Eine Vorschau ersetzt weder eine Sicherung noch einen Rücksetzmechanismus oder eine Genehmigungsrichtlinie. Kann ein Fehler schwerwiegende Folgen haben, sollten zusätzliche Kontrollen erwogen werden, etwa die Genehmigung durch eine weitere Person, eine schrittweise Ausführung oder ein erprobter Wiederherstellungsprozess.
Berechnung und Anwendung trennen
Die Geschäftsregel sollte einen Änderungsvorschlag berechnen können, ohne die Datenbank zu ändern. Ein praktikabler Ansatz besteht darin, Auswahl und Berechnung in zwei Modi gemeinsam zu nutzen: Ein Modus beschreibt die Änderung, der andere wendet sie an. Werden zwei unabhängige Implementierungen vermieden, sinkt das Risiko, dass Vorschau und Ausführung unterschiedliche Regeln auslegen.
Der Vorschlag kann für jedes betroffene Element Folgendes enthalten:
- Einen Bezeichner, mit dem sich der Datensatz erkennen lässt.
- Die relevanten aktuellen und erwarteten Werte.
- Den Grund für die Aufnahme oder den Ausschluss.
- Die durchgeführten Prüfungen und erkannten Konflikte.
- Den Umfang des Vorgangs, etwa Filter, Konto oder Zeitraum.
Ein Vorgang zum Ändern des Status von Bestellungen kann beispielsweise den aktuellen Status, den vorgeschlagenen Status und den Grund dafür anzeigen, dass ein Datensatz berücksichtigt wird. Gibt es zu viele Elemente, um sie alle auf dem Bildschirm darzustellen, können Summen und eine Stichprobe angeboten werden. Dabei muss klar sein, was angezeigt wird; außerdem muss sich der Detailumfang bei Bedarf prüfen oder exportieren lassen.
In PHP empfiehlt es sich, Auswahl und Berechnung in Komponenten mit klar abgegrenzten Zuständigkeiten zu kapseln. Ein Domänendienst kann vorgeschlagene Änderungen erzeugen, eine andere Komponente kann sie darstellen, und eine Anwendungsroute kann für Validierung und Persistierung zuständig sein. Die Vorschau sollte nicht indirekt durch Seiteneffekte des Lesens Schreibvorgänge auslösen.
Daten, Berechtigungen und Umfang validieren
Ein nützlicher Vorschlag erklärt nicht nur, was sich ändern würde, sondern auch, warum die Änderung zulässig ist. Die Geschäftsbedingungen sind anhand der aktuellen Daten zu prüfen; außerdem ist zu prüfen, ob der Benutzer berechtigt ist, den Vorgang anzusehen und auszuführen. Die Berechtigung, Datensätze abzufragen, bedeutet nicht zwangsläufig, dass sie auch geändert werden dürfen.
Der Umfang muss eindeutig sein. Hängt die Aktion von Filtern, einer Auswahl oder einer Dateiübertragung ab, sind diese Parameter verständlich festzuhalten und Grenzen, Ausschlüsse und Fehler mitzuteilen. Zu verhindern ist, dass eine weit gefasste Suche oder ein ausgelassener Filter eine begrenzte Aktion versehentlich in eine globale Änderung verwandelt.
Außerdem ist kenntlich zu machen, was sich nicht zuverlässig vorhersagen lässt. Eine Vorschau nimmt Änderungen durch andere Prozesse, Regeln in externen Systemen oder vom künftigen Zustand abhängige Seiteneffekte nicht automatisch vorweg. Gibt es Integrationen, Warteschlangen oder nachgelagerte Berechnungen, sind diese Auswirkungen getrennt zu beschreiben und nicht als bestätigter Bestandteil des Ergebnisses darzustellen.
Veraltete Vorschläge nicht anwenden
Eine Vorschau bildet die Daten zu einem bestimmten Zeitpunkt ab. Ändern sie sich vor der Ausführung, erfüllt eine Bestellung möglicherweise die Bedingungen nicht mehr, kann ein Benutzer Berechtigungen verlieren oder kann ein Datensatz von einem anderen Prozess aktualisiert worden sein. Das angezeigte Ergebnis darf daher nicht als dauerhafte Schreibberechtigung behandelt werden.
Bei der Ausführung sind die Bedingungen dafür, ob ein Datensatz berücksichtigt werden kann, sowie die Zugriffsrechte erneut zu prüfen. Je nach Fall kann eine Datensatzversion, ein Zeitstempel oder können die relevanten Werte mit den bei der Berechnung des Vorschlags erfassten Angaben verglichen werden. Bei Abweichungen darf nicht stillschweigend eine andere Entscheidung angewendet werden: Der Konflikt ist mitzuteilen, und es ist eine neue Vorschau zu erstellen oder der Konflikt ausdrücklich zu klären.
Bei Prozessen, die eine strikte Übereinstimmung erfordern, sollte eine Referenz auf den Vorschlag aufbewahrt und validiert werden, dass die Anwendung weiterhin dessen Umfang und Regeln verwendet. Eine Transaktion kann eine Gruppe von Schreibvorgängen vor zwischenzeitlichen Fehlern schützen, beseitigt aber nicht von selbst die Zeitspanne zwischen Vorschau und Ausführung. Die Strategie für Nebenläufigkeit muss dem Risiko und dem Volumen des Vorgangs entsprechen.
In Stapeln ausführen und Ergebnisse protokollieren
Bei großen Datenmengen kann die Anwendung in einem einzigen Vorgang die Sperrdauer verlängern und die Wiederherstellung erschweren. Es sind passende Stapelgrößen für die Datenbank und das Verhalten der Anwendung festzulegen. Bei Teilausfällen muss sich erkennen lassen, welche Datensätze angewendet, übersprungen wurden und welche überprüft werden müssen.
Ausreichend Informationen sind zu protokollieren, um das Ergebnis untersuchen zu können: wer den Vorgang gestartet und genehmigt hat, wann er vorbereitet und ausgeführt wurde, welcher Umfang angefordert war, wie viele Elemente verarbeitet wurden und welche Fehler aufgetreten sind. Personenbezogene Daten oder sensible Werte sind nicht ohne Notwendigkeit zu speichern; auch für Prüfprotokolle müssen die geltenden Zugriffs- und Aufbewahrungskontrollen gelten.
Bei einer Wiederholung des Vorgangs ist die Idempotenz zu berücksichtigen: Das Wiederholen eines Vorgangs sollte keine unerwarteten Effekte duplizieren. Eine Vorgangs-ID und Ausführungsstatus können helfen, wiederholte Vorgänge zu erkennen und Vorbereitung, Genehmigung, Ausführung und Abschluss voneinander zu trennen. Das Deployment des Codes darf nicht so dargestellt werden, als wäre es gleichbedeutend mit der Freigabe oder Aktivierung des Vorgangs: Das sind unterschiedliche Entscheidungen, für die jeweils eigene Kontrollen erforderlich sind.
Prüfen, dass die Vorschau keine Daten ändert
Tests sollten sowohl die Berechnung als auch das Ausbleiben von Schreibvorgängen im Vorschaumodus prüfen. Mit repräsentativen Daten sind Aufnahme und Ausschluss, aktuelle und vorgeschlagene Werte, unzureichende Berechtigungen und fehlgeschlagene Validierungen zu überprüfen.
Außerdem ist zu prüfen, ob die Ausführung den erwarteten Vorschlag anwendet und Änderungen durch parallele Vorgänge das festgelegte Verhalten auslösen. Gegebenenfalls sind Fehler innerhalb eines Stapels, Wiederholungsversuche und Integrationsfehler zu testen. Integrationstests mit der Datenbank sind wichtig: Ein Unit-Test der Berechnung beweist nicht, dass eine Vorschau-Route keine Seiteneffekte hat.
Zu den Grenzfällen sollten leere Filter, große Datenmengen, zwischen den Phasen gelöschte oder geänderte Datensätze sowie Benutzer mit unterschiedlichen Zugriffsbereichen gehören. Außerdem ist zu prüfen, dass die Oberfläche nicht behauptet „genau diese Elemente werden aktualisiert“, wenn die Anwendung die Menge zum Ausführungszeitpunkt erneut berechnet.
Checkliste zur Wahl der erforderlichen Kontrollen
- Betrifft der Vorgang viele Datensätze, hat er schwer rückgängig zu machende Auswirkungen oder erfordert er eine Genehmigung?
- Werden Umfang, betroffene Elemente sowie aktuelle und erwartete Werte angezeigt?
- Ist die Vorschau von Schreibvorgängen und deren Seiteneffekten getrennt?
- Werden Berechtigungen, Geschäftsregeln und Daten sowohl bei der Vorbereitung als auch bei der Ausführung geprüft?
- Werden relevante Änderungen erkannt, die zwischen den beiden Phasen aufgetreten sind?
- Gibt es Stapelgrenzen, einen festgelegten Umgang mit Teilausfällen und angemessene Prüfprotokolle?
- Bestätigen die Tests, dass die Vorschau keine Daten ändert und die Ausführung das validierte Ergebnis einhält?
Eine Vorschau ist dann geeignet, wenn sie eine fundierte Entscheidung unterstützt und ihre Grenzen klar sind. Lässt sich keine verlässliche Schätzung der Auswirkungen bereitstellen, ist es besser, den Umfang zu verkleinern, zunächst in einer kontrollierten Umgebung auszuführen oder eine zusätzliche Prüfung zu verlangen, statt eine Zahl oder Teilliste als Ergebnisgarantie auszugeben.
