Bei Back-End-Validierungen meine ich während der Trigger, CHECK, Prozedur (Insert, Update, Delete) usw. Wie praktisch oder notwendig sind sie jetzt, wo heutzutage die meisten dieser Validierungen im Front-End streng gehandhabt werden. Wie viele Back-End-Validierungen sind für ein Programm geeignet? Sollten kleine Dinge aus Back-End-Validierungen herausfallen?
Zum Beispiel: Nehmen wir an, wir haben eine Altersbarriere von Menschen, um Daten einzugeben. Dies kann im Backend mithilfe von Triggern oder Prüfen in der Spalte "Alter" erfolgen. Es kann / wird auch im Frontend gemacht. Ist es also notwendig, eine Back-End-Validierung zu haben, wenn das Alter im Front-End strikt validiert wird?
Dies ist eine konzeptionelle Frage. Im Allgemeinen sind moderne Programme in 3 Schichten aufgebaut:
In der Regel kann Schicht 1 alle Eingaben in einer modernen Anwendung validieren und dem Benutzer ein schnelles Feedback zu möglichen Problemen geben (z. B. ein JS-Popup mit der Aussage "dies ist nicht möglich eine gültige E-Mail-Adresse ").
Ebene 2 immer muss die vollständige Validierung durchführen. Es ist das Gateway zum Backend und kann komplexe relationale Einschränkungen überprüfen. Es stellt sicher, dass keine beschädigten Daten in irgendeiner Weise in die Datenbank gelangen, die gegen die Einschränkungen der Anwendung validiert werden. Diese Einschränkungen sind oft komplexer als das, was Sie ohnehin in einer Datenbank überprüfen können (zum Beispiel muss eine Bankkontonummer hier in den Niederlanden entweder 3 bis 7 Zahlen sein, oder 9 oder 10 und mit einem <übereinstimmen a href="http://en.wikipedia.org/wiki/Check_digit"> Prüfstellentest ).
Ebene 3 kann eine Validierung durchführen. Wenn es nur einen "Client" gibt, ist es nicht unbedingt notwendig, wenn es mehr gibt (besonders wenn es weniger vertrauenswürdige Benutzer derselben Datenbank gibt), sollte es definitiv auch in der Datenbank sein. Wenn es sich um eine unternehmenskritische Anwendung handelt, wird empfohlen, die Datenbank auch vollständig mit Triggern und Einschränkungen zu validieren, um sich doppelt vor Fehlern in der Geschäftslogik zu schützen. Die Aufgabe der Datenbank besteht darin, ihre eigene Integrität sicherzustellen und nicht die Einhaltung bestimmter Geschäftsregeln.
Es gibt keine eindeutigen Antworten auf diese Frage, es hängt davon ab, was Ihre Anwendung tut und wie wichtig sie ist. In einer Banking-Anwendung - Validierung auf allen 3 Ebenen. In einem Internetforum - nur dort überprüfen, wo es benötigt wird, und zusätzliche Benutzer mit den Leistungsvorteilen bedienen.
Dies könnte helfen:
Frontend (Interface) Validierung ist für die Dateneingabe Hilfe und kontextuelle Nachrichten. Dies stellt sicher, dass der Benutzer eine problemlose Dateneingabeerfahrung hat; und minimiert den für validate Korrektheit erforderlichen Roundtrip.
Die Validierung auf Anwendungsebene dient zur Validierung von Geschäftslogik. Die Werte sind korrekt, aber machen sie Sinn . Dies ist die Art von Validierung, die Sie hier durchführen, und die meisten Ihrer Bemühungen sollten in diesem Bereich liegen.
Datenbanken führen keine Validierung durch. Sie stellen Methoden für constraint -Daten bereit, deren Umfang sicherstellen sollte, dass referentielle Integrität gewährleistet ist. Die referenzielle Integrität stellt sicher, dass Ihre Abfragen (insbesondere Kreuztabellenabfragen) wie erwartet funktionieren. Genau wie kein Datenbankserver Sie davon abhält, 4000 in einer numerischen Spalte einzugeben, sollte es auch nicht der Ort sein, um zu überprüfen, ob Alter & lt; Dies hat keinen Einfluss auf die Integrität der Daten. Wenn Sie jedoch sicherstellen, dass eine Zeile gelöscht wird, bleiben keine Waisen zurück - dies ist referenzielle Integrität und sollte auf Datenbankebene erzwungen werden.
Back-End-Validierungen sind notwendig!
Wenn das Frontend JavaScript-Validierung verwendet und der Benutzer das JavaScript im Browser deaktiviert, wird die Validierung deaktiviert. Daher ist eine Back-End-Validierung erforderlich.
Setzen Sie Constraints in Ihre Datenbank. Dies ist NICHT eine Geschäftsvalidierung, sondern eher eine Datenvalidierung, z. B. Fremdschlüsseleinschränkungen oder die Sicherstellung, dass Ihre Primärschlüssel eindeutig sind. Es stellt sicher, dass Ihre Daten konsistent sind.
Die Validierung, über die Sie sprechen, ist die Business Validierung. Diese Art der Validierung sollte in Ihrer Business Ebene sein, beispielsweise in Ihrer Domain, und sollte die wichtigste sein Quelle für die Validierung. Wenn sich diese Regeln ändern, ändern Sie sie in der Business-Schicht, und alle Ihre Clients sind sofort betroffen.
In der UI können / sollten Sie auch eine einfache Eingabe Validierung durchführen - wie die Überprüfung von Pflichtfeldern oder die Gültigkeit einer E-Mail-Adresse; und darauf basierende UI-Steuerelemente aktualisieren oder deaktivieren. Ich würde sagen, dass dies die Art von Validierung ist, die sich nicht (sehr) ändert.
Die uralte Antwort: es kommt darauf an .
Es hängt wirklich von Ihren Bedürfnissen ab. Wenn Benutzer die Datenbank direkt ändern, würde ich sagen, dass Sie unbedingt Ihre Datenbank einschränken müssen. Das heißt, eine große Anzahl von Datenbanken wird nur durch eine Webanwendung modifiziert. Während Sie die serverseitige Validierung in der Webanwendung selbst benötigen, können Benutzer Ihre Webseiten möglicherweise nicht umgehen, da Sie keine Datenbankeinschränkungen benötigen.
Sie sollten die Überprüfung auf der Clientseite immer noch als eine Annehmlichkeit für den Client durchführen.
Wenn Sie Bedenken hinsichtlich der Sicherheit haben, sollte alles auf dem Server validiert werden, um zu verhindern, dass jemand einen alternativen Client für den Zugriff / die Manipulation Ihrer Datenbank erstellt. Das Frontend ist ebenfalls notwendig, da es die Effizienz erhöht und verhindert, dass der Server mit unangemessenen Daten angesprochen wird.