MVC Frage: Sollte ich die Regeln für die Formularvalidierung in den Controller oder in das Modell aufnehmen?

Question

Einerseits könnte die Formularvalidierung als Teil der Anwendungslogik betrachtet werden und daher in das Modell gehören.

Auf der anderen Seite befasst es sich direkt mit den Eingaben, die von der Ansicht kommen, und behandelt die Anzeige von Fehlern usw. Unter diesem Gesichtspunkt ist es sinnvoller, sie in Controllern unterzubringen.

Welches ist der richtige Ansatz aus MVC-Sicht?

P.S. meine Formularvalidierung besteht eigentlich nur aus dem Schreiben einer Liste von Feldern, deren Regeln und der Weitergabe an eine Formularvalidierungsbibliothek, die wahr/falsch zurückgibt, ob sie die Validierung bestanden hat oder nicht.

Beispiel:

$this->load->library('form_validation');
$this->form_validation->set_rules('name', 'Name', 'required');
$this->form_validation->set_rules('email', 'Email', 'required|valid_email');
//........
if ($this->form_validation->validate())
    // Process data
else
    $this->register_form(); //A controller action that will show a view with errors

Sollte dies in einen Controller oder ein Modell eingebaut werden?

Answer 1

Idealerweise sollten Sie 3 Ebenen der Validierung verwenden:

1. Ansicht: Client-Seite (Javascript, html5-Validierung, etc.). Dies fängt offensichtliche Fehler und Auslassungen ab, bevor die Daten den Controller erreichen, was die Zeit des Nutzers verschwendet und bei Fehlern ein unnötiges Laden der Seite auslöst.
2. Controller : Dies ist Ihr Formular Validierungsebene. Controller sind in der Regel dazu gedacht, Eingaben direkt zu verarbeiten und an das Modell weiterzuleiten. Es ist sehr selten, dass jedes Feld in Ihrem Formular eine direkt verwandte Spalte in Ihrer DB hat, müssen Sie in der Regel die Daten in irgendeiner Weise zu ändern, bevor sie an das Modell übergeben. Nur weil Sie ein Feld mit dem Namen "confirm email" validieren müssen, bedeutet das nicht, dass Ihr Modell mit einem "confirm email"-Wert umgehen wird. Manchmal ist dies der letzte Validierungsschritt.
3. Modell : Dies ist Ihre letzte Verteidigungslinie für die Validierung, und möglicherweise Ihre einzige Validierung im Falle der Übermittlung von Daten an das Modell ohne es kommt direkt aus einer Formularsendung. Es gibt viele Fälle, in denen Sie Daten von einem Controller-Aufruf an die DB senden müssen, oder mit Daten, die keine Benutzereingaben sind. Wir wollen keine DB-Fehler sehen, sondern Fehler, die von der Anwendung selbst ausgelöst werden. Modelle sollten normalerweise nicht direkt mit $_POST-Daten oder Benutzereingaben umgehen, sondern Daten vom Controller erhalten. Sie wollen hier nicht mit nutzlosen Daten wie der E-Mail-Bestätigung umgehen.

Answer 2

Die Validierung ist Sache des Modells. Nur das Modell weiß, wie Ihre Daten aussehen sollen. Sie beschreiben Ihre Datenfelder im Modell, also sollten Sie auch die Validierungsregeln für diese Felder an der gleichen Stelle beschreiben.

Für mich scheint es offensichtlich zu sein, aber ich höre mir gerne die Gegner an.

Answer 3

Ich würde sagen, das Formular Validierung Code sollte in den Controller (nicht das Modell) in den meisten Fällen sein.

Madmartigan hat es in seinem obigen Kommentar am besten ausgedrückt: "Form validation !== Data validation. Nicht alle Formulare interagieren mit einem Modell"

Webformulare sind logischerweise Teil des View/Controller-Teils von MVC, da der Benutzer in der View mit ihnen interagiert.

Answer 4

Es scheint, als ob jeder auf diese Frage immer "Model Hands Down" sagt, was seine Vorteile hat (im Vergleich zum Gegenteil), aber ich denke, die Antwort auf die Frage ist subtiler. Validierung der Daten selbst an dem Modell durchgeführt werden sollte.

Es gibt aber auch andere Arten der Validierung so z. B., ob das Formular mit unerwarteten Feldern eingereicht wurde (natürlich aus Sicherheitsgründen) oder ob ein Benutzer die Erlaubnis hat, die angeforderte Operation durchzuführen. Indem diese Arten der Validierung in das Modell aufgenommen werden, wird das Modell (eine Abstraktion der Daten) mit völlig anderen Dingen verknüpft, z. B. wie das Benutzersystem funktioniert oder wie Formularübermittlungen zu Sicherheitszwecken bewertet werden.

Sie können sich vorstellen, dass Sie eine dieser Klassen oder Klassensysteme ändern und dann ein Chaos haben, weil Sie auch alle Ihre Modelle ändern müssen. Controller hingegen sind der Vermittler zwischen den Eingaben des Clients und den Daten: In dieser Rolle sind sie die eigentlichen Validierer der obigen Beispiele und wahrscheinlich vieler anderer.

Answer 5

Unter Berücksichtigung anderer Antworten (und einiger Nachforschungen), wenn Sie Daten mit Regeln wie nicht leeren Feldern, E-Mail-Validierung und so weiter validieren müssen, sollte der Controller diese Daten nicht selbst durchlassen, aber wenn Sie Regeln wie "nur ein Benutzer mit einem Ansehen von mehr als 150 kann eine Antwort ablehnen" haben, sollten Sie dies in der Modellschicht tun.

Wenn Sie Geschäftsregeln validieren möchten, empfehle ich Ihnen, ein Objekt wie das Business-Objekt-Muster Damit haben Sie in jedem Teil der Software, in dem Sie eine Antwort "ablehnen" wollen, Ihre Geschäftslogik erhalten und zentralisiert.