Wo tun Sie Ihre Validierung? model, controller oder view
Worauf legen Sie Benutzer-Eingabe-Validierung in einer web form-Anwendung?
- Anzeigen: JavaScript-client-Seite
- Controller: Server-side-Sprache (C#...)
- Modell: Datenbank (gespeicherte Prozeduren oder Abhängigkeiten)
Ich denke, es ist eine Validierung erforderlich, die von jeder Ebene:
- Hat der Benutzer die Eingabe ein vernünftiger Wert
- sind Termine aktuelle Termine, zahlen sind wirklich zahlen ...
- Tun alle Prüfungen im 1. wieder plus Kontrollen für böswillige Angriffe(IE XSS oder SQL-injection)
- Der durchgeführten Prüfungen im 1. sind, hauptsächlich, um ein server-roundtrip, wenn der Benutzer einen Fehler macht.
- Da Sie fertig sind, auf der client-Seite in javascript, die Sie nicht Vertrauen können, dass Sie ausgeführt wurden. Überprüfen Sie diese Werte wieder aufhören wird zu einigen gefährlichen Angriffen.
- Sind Abhängigkeiten erfüllt sind (dh. hat der Benutzer einen Kommentar hinzufügen, um eine berechtigte Frage)
- Ein gutes interface macht diese sehr schwer zu verletzen. Wenn etwas gefangen wird, hier etwas sehr schief ging.
[inspiriert von diese Antwort]
- *Wo *Controller-Bitte Korrekturlesen.
- Dank Rich B. Korrekturen vorgenommen.
- mehr Korrekturlesen erforderlich: "mianly"="hauptsächlich"
- Das Modell ist nicht nur die Datenbank, es ist die business-Logik der Anwendung. Um nicht gegen das TROCKEN die Validierung sollte durchgeführt werden in der Modell-Ebene.
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich überprüfen, in allen Ebenen, jedoch würde ich mag zu beachten, eine Validierung trick, die ich benutze.
Ich bestätigen in der Datenbank-Schicht, ordnungsgemäße Einschränkungen auf Ihrem Modell werden automatisch die Integrität der Daten-Validierung.
Dies ist eine Kunst, die verloren zu sein scheint auf den meisten web-Programmierer.
Validierung im Modell, Optional automatisierte Abläufe in der Benutzeroberfläche, die nehmen Ihre Hinweise aus dem Modell und verbessern die user experience.
Durch automatisierte Routinen, ich meine, dass es eigentlich keine pro-model-Validierung code in das Benutzer-interface. Wenn Sie eine Bibliothek der Validierung von Methoden, wie RoR (die hat Methoden wie validates_presence_of :username (Benutzername) der controller oder die Sicht in der Lage sein sollten diese zu Lesen und anzuwenden entsprechenden javascript (oder was auch immer ist bequem) - Methoden.
Das bedeutet, dass Sie auf duplizieren Sie die komplette Validierungs-Bibliothek in der Benutzeroberfläche, oder zumindest ein mapping wenn Sie eine bereits vorhandene ein. Aber sobald das erledigt ist werden Sie nicht haben, zu schreiben Validierung Logik außerhalb des Modells.
Validierung durchgeführt werden kann, auf allen Ebenen.
Überprüfen der Eingaben, die aus einem web-Formular (alle Zeichenfolgen Umwandlung in den richtigen Typ, etc) unterscheidet sich von der Validierung der Eingabe von einem webservice oder XML-Datei, etc. Jeder hat seine eigenen speziellen Fällen. Sie können erstellen Sie ein Validator helper-Klasse natürlich, so externalising die Validierung und ermöglicht es, geteilt zu werden, von Ansichten.
Dann haben Sie die DAO-layer-Validierung - ist es genug Daten, die im Modell bestehen (treffen not null-Einschränkungen, etc) und so weiter. Sie können sogar check constraints in der Datenbank (status in ('N', 'A', 'S', 'D') usw.).
Dies ist interessant. Für die längste Zeit, die ich durchgeführt alle Validierung im Modell, rechts oben, was ich denken würde, DAL (data access layer). Meine Modelle sind in der Regel Muster wird nach der Tabelle Daten-gateway mit einem DAL Bereitstellung der Abstraktion und low-level-API.
In der Seite, die der TDG-ich würde Sie implementieren die business-Logik und Validierungen, wie:
Als mein Antrag wuchs in Komplexität, begann ich zu erkennen, dass viel für die Prüfung getan werden könnte, auf der Clientseite mit JavaScript. Also ich umgestaltet werden, die meisten Validierungs-Logik in JS und cleanuped meine Modelle.
Dann merkte ich, dass server-side validation (nicht-Filterung/escaping -- die halte ich für anderes) sollte probalby getan werden, den server als gut und nur client-Seite als Sahnehäubchen auf dem Kuchen.
Also wieder die Validierungslogik ging, als ich merkte wieder, dass es wahrscheinlich war eine deutliche Differenz zwischen INPUT-Validierung/assertion und Geschäftsregeln/Logik.
Grundsätzlich, wenn es getan werden kann, in der die client-Seite der Anwendung (mit JS) ich denke, dass das INPUT-Validierung...wenn es MUSS getan werden, um das Modell (ist dieser Eintrag bereits vorhanden ist, etc?) dann würde ich prüfen, die business-Logik. Was ist verwirrend ist, dass Sie beide protecte die Integrität der Daten zu Modell.
Wenn Sie dont' überprüft die Länge eines Benutzernamens dann, was zu stoppen, die Menschen von der Schaffung eines einheitlichen Charakter Benutzername?
Ich habe noch nicht ganz entschieden, wo man diese Logik weiter, ich denke, es hängt wirklich davon ab, was Sie bevorzugen mehr, thin Controller, schwere Modelle, oder Visum-versa...
Controller, in meinem Fall in der Regel viel mehr anwendungsbezogen, in der Erwägung, dass Modelle, wenn sorgfältig gestaltete, kann ich oft die Wiederverwendung in "anderen" Projekte nicht nur intern, also ich bevorzuge die Modelle geringes Gewicht und Controllern, die auf der schwereren Seite.
Welche Kräfte Sie fahren in jede Richtung sind wirklich persönliche Meinung, Anforderungen, Erfahrungen, etc...
Interessantes Thema 🙂
Validierung muss getan werden in der controller - es ist der einzige Ort, der für Sicherheit und Antwort.
Validierung sollte getan werden in der Ansicht - es ist der Punkt von Kontakt und stellen die beste UE und speichern Sie Ihre server zusätzliche Arbeit.
Validierung wird werden auf dem Modell gemacht - aber nur für einen bestimmten Kern Niveau der Kontrollen. Datenbanken sollten unbedingt entsprechende Einschränkungen, aber es ist ineffizient zu lassen, diese stehen für die eigentliche Validierung, noch ist es immer möglich, eine Datenbank zum bestimmen Gültiger Eingaben mit einfachen constraints.
Alle Validierung geschehen soll mindestens ein mal, und dies sollte in der middle tier, ob es in Ihrer value-Objekte (im DDD Sinne, nicht zu verwechseln mit DTO ' s), oder durch die business-Objekt der entity selbst. Client-seitige Validierung auftreten können, um user experience zu verbessern. Ich Neige dazu, nicht client-seitige Validierung, da kann ich nur aussetzen all die Dinge, die falsch sind und auf die form auf einmal, aber das ist nur meine persönliche Präferenz Der Datenbank Validierung auftreten können, zu versichern, die Integrität der Daten im Fall, dass Sie vermasselt die Logik in der middle tier-oder zurück-beendet etwas.
Ich mache das nur in der View und Controller, die Datenbank erzwingt einige, die durch Ihre Datentypen und so weiter, aber ich würde lieber es nicht so weit kommen ohne mich fangen einen Fehler.
Haben Sie ziemlich viel beantwortet Ihre eigene Frage aber die wichtige Sache zu wissen ist, dass man nie Vertrauen in die Ansicht, aber das ist die einfachste route, um geben von feedback an den Benutzer, so dass Sie müssen zu bereinigen auf mindestens eine weitere Ebene.
Hmmmm, sicher nicht. Hätte ich gesagt, der Controller, bis ich diesen Artikel gelesen re: skinny Controller, fat-Modelle
http://blog.astrumfutura.com/archives/373-The-M-in-MVC-Why-Models-are-Misunderstood-and-Unappreciated.html
Da die meisten der überprüfungen hängt von business-Regeln, ich mache die Validierung auf der business-Schicht als third-party-tool-Klassen. Es gibt andere Arten von Validierungen, wie Benutzereingaben, in der Erwägung, dass es erforderlich ist, muss in der Steuerung, aber Sie können die Kapseln die Validierungsregeln in den Dritten Klassen zu. Wirklich, es hängt davon ab, was zu überprüfen.
Clientseitigen Validierungen sind die kleinen, nur zum Bau eines leichten input-Validierung, aber die server-seitige Validierung ist benötigt immer. Man kann nie das Vertrauen in die Benutzer-Eingabe 😉
.NET haben schöne Steuerelemente zum erstellen von Validierungen, aber die business-Schicht immer muss der bessere Ansatz ist, um die Daten zu überprüfen und diese Kontrollen sind nicht genug, um die Aufgabe.
Einfache überprüfung der Eingaben in der Ansicht. Eine volle Validierung des Modells. Grund? Wenn Sie Ihre Ansicht ändern Technologie, und die Validierung ist in der view/controller haben, müssen Sie umschreiben Ihre Validierung für die neue Ansicht. Dies kann die Einführung bugs. Legen Sie es in das Modell, und das ist, wiederverwendet wird, indem alle Ansichten...
Aber, wie gesagt, einfache Validierung in der Ansicht für die Geschwindigkeit und Leichtigkeit.