Best Practice zur Validierung von Eingabedaten für die mehrstufige Anwendung [geschlossen

Question

In unserer Bewerbung haben wir verschiedene Schichten. Serviceschicht, DAO -Ebene und -aktionen (Struts -Anwendungen).

Die Daten werden von einer Schicht zu einer anderen Ebene übergeben.

Wo sollten wir idealerweise Eingabevalidierung einsetzen?

Sagen Sie, userId, Telefonnummer kommt von der Benutzeroberfläche, sie sind obligatorisch. Wir führen also bereits auf der Kundenseite zur Validierung.

Jetzt, nach meiner Meinung, brauchen Sie alle, die Sie brauchen. Nein, wo sonst sollte es validiert werden.

Einer meiner Kollegen argumentiert jedoch, was ist, wenn der Kunde direkt Anfrage stellt. Wir müssen also auch Aktionen hinzufügen.

Jetzt, auch bei Dao

Oder, beispielsweise der Service -Ebene, sie könnte als Webdienst entlarvt werden, sodass auch U shd validiert werden kann.

Im Wesentlichen schlägt er vor. Wir haben überall Bestätigungen. Was für mich keinen Sinn macht. Seine Duplizierung über die Schicht.

Was ist ein idealer Ansatz dafür? Anhand der Validierung ist eine einfache Nullprüfung oder eine komplexe Validierung.

Answer 1

Stimmen Sie Pangaea zu, Sie sollten auf jeden Fall Validierungen in den Kunden- und Service -Endpunkten haben.

Ich würde hinzufügen, dass das Konzept der Validierungen "fehlgeschlagen" sein soll. Sie fügen jeder Ebene Validierungen hinzu, damit der Benutzer oder Anrufer ein sofortiges Feedback dafür erhalten würde, warum der Anruf fehlschlägt, anstatt möglicherweise eine Transaktion zu starten, komplexe Abfragen zu erstellen und ein Schreiben zu erstellen, um festzustellen, dass ein Feld zu kurz ist.

Auf der Client-Seite möchten Sie so viel Validierung wie möglich, damit Sie nicht die Zeit, die Bandbreite und die serverseitige Ressourcen des Benutzers verschwenden (die in vielen Fällen Inhalte haben). Normalerweise können Sie jedoch nicht alle Validierungen auf der Client-Seite durchführen (z. B. um zu überprüfen, ob bei der Anmeldung bereits ein solcher Benutzername verwendet wird) Drücken Sie die Serviceschicht.

Auf der Serverebene möchten Sie davon ausgehen, dass alle Eingaben potenziell gefährlich und falsch sind (und dies oftmals). Ich denke tatsächlich, dass es besser ist, umfassender und aggressiver zu sein, wenn es darum geht, Inputs für die Serviceschicht zu validieren, da dies Ihre letzte Verteidigungslinie ist. Wenn Sie auf der Client -Seite ein oder zwei Bestätigungen auslassen, benötigen Sie nur einen netten Mechanismus zur Handhabung, damit die Benutzer wissen, was falsch ist. Wenn Sie etwas auf der Serviceseite und auf Katastrophenangriffe verpassen, kann dies Stunden oder Tage des Debuggens und der Wiederherstellung der Datenbanksicherung bedeuten.

Es gibt einige Überprüfungen, die auch auf Datenbankebene durchgeführt werden, die Dinge wie referenzielle Integrität und dergleichen erzwingen. Normalerweise versuche ich so viel wie möglich, um sie zu überprüfen, bevor ich ein Schreiben versuche, da die Interpretation verschiedener RDBMS -Fehlermeldungen und der Versuch, sie in den Benutzer verständlich umzuwandeln, oft schwierig, wenn nicht unmöglich ist, zu konvertieren.

Answer 2

Wenn Ihre Anwendung mehrere Einstiegspunkte (Benutzeroberfläche oder System zu Systemoberflächen oder Stapelsystemen) bereitstellt, sollten Sie reinigen (NULL-Überprüfungen, Formatprüfungen, Erforderliche Ness usw.) Ihre Daten an all diesen Kanten und bevor sie die Serviceschicht erreicht. Dies bedeutet jedoch nicht, dass Sie Ihre Validierungslogik replizieren müssen. Sie können Frameworks verwenden, mit denen Sie Ihre Validierung zentralisieren können. Einige Beispiel -Validierungs -Frameworks finden Sie darin Post.

Es gibt jedoch geschäftliche Validierungen, die zu Ihrer Domänenschicht gehören sollten, und sie sollten in Ihrer Domain -Service -Ebene oder Domain -Objekte bleiben.

Ich bin nicht einverstanden, dass Sie in DAOs Validierung durchführen sollten. DAOs sollten nur für Crud Operations verantwortlich sein. Wenn sie mehr tun, haben Sie undichtende Schichten. Wenn Sie Dinge in Stapel verarbeiten müssen, sollten Sie sicherstellen, dass die Charge über die Serviceebene erfolgt, damit Ihre Charge auch dieselben Validierungen durchläuft.

Answer 3

Das einzige Stück Weisheit, das ich dem Gespräch hinzufügen kann, ist, dem Kunden niemals zu vertrauen. Egal, ob Ihr Kunde in HTML, Flash/Flex oder was auch immer, es besteht die Möglichkeit, dass jemand es hackt und versucht, etwas zu tun, das Sie nicht tun möchten. Das Follow -up hier ist: Wenn die Möglichkeit besteht, dass jemand es hackt, müssen wir als Software -Ingenieure davon ausgehen, dass er gehackt wird. Während die Überprüfungen am vorderen Ende gut sind und Ihre Anwendungswahrheitsfähigkeit unterstützen können Sie müssen alle Ihre Eingaben am hinteren Ende validieren, auch wenn dies zu doppelten Überprüfungen führt.