Wieviel Validierung muss sein? - 3 Konzepte kurz vorgestellt

Validierung. Eine der wichtigsten Dinge in der Datenverarbeitung und besonders in der IT. Man findet sie überall, oft sehr restriktiv, oft gar etwas zu übervorsichtig. An anderen Stellen scheint jede sinnvolle Validierung nicht vorhanden. Da stellt sich die Frage, wie weit soll man den Anwender selbst entscheiden lassen?

Motiviaton für diesen Post und Inhalt

Das ganze soll eine kurze Auflistung werden, wie validiert werden kann mit einer kurzen Betrachtung der Vor- und Nachteile. Nicht für jede Anwendung ist immer die gleiche Strategie anwendbar. Das ganze richtet sich primär an weniger erfahrene Entwickler, vielleicht ist aber doch für den ein oder anderen Fortgeschrittenen etwas zum Mitnehmen dabei.

Naive-Approach

Man validiert sehr rudimentär ausschliesslich auf Pflichtfelder, vielleicht noch die Maximallänge oder Zahlenräume. Hierbei kann es aber sein das bei der Verarbeitung der Daten die Qualität sehr schlecht ist. Vielleicht komplett ungültige Zeichen, sogar fehlerhafte und damit komplett Unbrauchbare Eingaben.

Vorteile

• der Anwender hat es ziemlich leicht Schrott einzugeben
• für den Entwickler ist der Aufwand ziemlich gering

Nachteile

• Die Datenqualität ist sehr vom Endanwender abhängig
• Problem: Was tun bei unbrauchbaren, aber notwendigen Daten?

User-oriented Approach

Die Daten werden so validiert, das der Nutzer zwar nicht die volle Kontrolle erhält, allerdings eine gute Datenqualität gewährleitstet wird. Dabei wird aber nicht jede Annahme getroffen, wie z. B. mögliche Obergrenzen, die zwar vielleicht unrealistisch, aber dennoch real sein können. Man schränkt technische Limitierungen also schon vor der Verarbeitung ein. So hat man einen guten Datenbestand bei zugleich gesunder Eigenverantwortung des Anwenders.

Vorteile

• der Nutzer ist mündig, bekommt aber dennoch die Sicherheit der Software oben drauf
• der Entwickler hat einen moderaten Aufwand bei hoher Datenqualität

Nachteile

• Mögliche "unrealistische" Werte, werden nicht gefiltert
• höheres Risiko durch den Anwender bei unrealistischen Werten

Bullet-Proof-Approach

Alle Eingaben werden sowohl auf die technsichen Limitierungen abgeprüft, als auch auf möglicherweise unrealistische Werte, fehlerhafte Kombinationen oder schlichtweg zu "schlechte" Daten, z. B. zu kurze Artikeltexte etc. Der Nutzer hat hierbei nur einen sehr geringen Fehlerraum, allerdings auch im Falle des Falles keine Möglichkeit Daten so zu erfassen, wie sie tatsächlich vorliegen. Für unbedarfte Anwender ist dies allerdings oft die beste Lösung.

Vorteile

• geringe Wahrscheinlichkeit das invalide Daten irgendeiner Art erfasst werden

Nachteile

• hoher Aufwand in der Entwicklung
• starke Bevormundung der Nutzer

Summary

Nicht jede Strategie eignet sich für jeden Use-Case. Das ganze soll aber vorallem Programmieranfängern helfen, besser zu entscheiden und alle Möglichkeiten zu erkennen.

Natürlich sind das nicht alle Möglichkeiten zu validieren, doch das sind die 3 simpelsten Ausprägungen, wie vorgegangen werden kann.