it-swarm.com.de

Bester Ort für die Validierung im Modell/Ansicht/Controller-Modell?

Ich arbeite an einem PHP -Projekt, das das MVC-Designmuster umfassend verwendet. Ich freue mich auf die Validierung eines Formulars und bin gespannt, was der richtige Ort für die Validierung ist.

Aufgrund der Art und Weise, wie Formulare generiert werden, ist die Validierung von Postback-Daten in Ansichtskomponenten viel einfacher und weniger wiederholend. Ist es akzeptabel, dass die Ansicht Antwortdaten validiert, oder sollte dies in der Steuerung oder sogar im Modell implementiert werden?

Was sind die Vorteile?

49
Lea Hayes

Wenn Sie die Daten auf Clientseite validieren (d. H. Javascript-Validierung), was absolut nicht ausreichend und überhaupt nicht sicher ist, sollten Sie sie in View implementieren.

Wenn Sie Daten auf dem Server überprüfen und Ihre Überprüfung keine Anwendungsgeschäftslogik erfordert (d. H. Sie prüfen nicht, ob der Benutzer über ein ausreichendes Guthaben in seinem Konto verfügt), sollten Sie die Überprüfung im Controller vornehmen.

Wenn für die Validierung Geschäftslogik erforderlich ist, implementieren Sie sie im Modell und rufen Sie sie über den Controller auf.

Die Postback-Validierung ist nicht gut, da sie viel Druck und Verzögerung verursacht. Der einzige Vorteil ist für den Programmierer (nicht zu berücksichtigen).

Sie können Regex für die meisten Validierungen verwenden, die dieselbe Syntax (fast) für PHP und JS haben.

29
AbiusX

Der richtige Ort für die Validierung ist das Model .

Dies ist am sinnvollsten, da Sie die Daten validieren, was das Modell darstellt. In Bezug auf die CRUD-Aktualisierungen sollte das Modell immer irgendwie verwendet werden. 

  • Wenn Sie Daten in der -Ansicht ändern, sollten Validierungen Überprüft werden. 

  • Wenn sich Controller ändern, __.data, sollten Validierungen __. Überprüft werden. 

  • Und schließlich, wenn Sie das Modell selbst haben, um Daten zu ändern, sollten Sie Noch über Validierungen verfügen.

Die einzige Möglichkeit, diesen Zustand zu erreichen, besteht darin, die Validierung in das Modell einfließen zu lassen.

Aufgrund der Leistung und der schnelleren Reaktion sollten Sie nach der Implementierung der Validierungen im Modell versuchen, eine Art clientseitiger Komponente (JS) hinzuzufügen, um den Endbenutzer sofort zu benachrichtigen.

Bei der Validierung geht es immer um die Daten. Warum validieren Sie Daten? So können Sie die Integrität der von Ihnen gespeicherten Informationen beibehalten. Durch die Validierungen auf Modellebene können Daten theoretisch immer korrekt sein. Dies ist immer eine Notwendigkeit. Von dort aus können Sie zusätzliche Validierungen in Ihre Geschäftslogik und auf Ihre Clientseite aufnehmen, um Ihre Anwendung benutzerfreundlicher zu machen.

92
Mike Lewis

Die Validierung im Modell scheint der gebräuchlichste Ansatz zu sein (Sie enden mit etwas wie $obj->isValid()) und ist in vielen Situationen geeignet.

Abhängig von Ihrem Anwendungsfall kann es jedoch gute Gründe geben, die Validierung außerhalb des Modells durchzuführen, entweder mit separatem Validierungscode oder im Controller usw.:

  • Wenn ein Großteil des gesamten Validierungsproblems Informationen beinhaltet, auf die das Modell nicht zugreifen kann (wenn beispielsweise ein Administratorbenutzer Transformationen durchführen kann, die ein regulärer Benutzer nicht kann, oder bestimmte Eigenschaften nach einem bestimmten Datum nicht geändert werden können), möchten Sie möglicherweise alle prüfen diese Einschränkungen an derselben Stelle.
  • Es kann auch zweckmäßig oder notwendig sein, beim Erstellen von Testobjekten sehr laxe Validierungsregeln anzuwenden. (Ein "Warenkorb" -Objekt erfordert normalerweise einen zugehörigen Benutzer, der wiederum eine gültige E-Mail-Adresse benötigt, usw. Ein 100% gültiges Warenkorbobjekt ist möglicherweise unpraktisch, um in Warenkorb-Einheitstests aufgebaut zu werden.)
  • Aus historischen Gründen können sich Validierungsregeln ändern (z. B. Erzwingen eines "Geschlechts", für das zuvor kein Geschlecht erforderlich war). Daher können unterschiedliche Versionen von Daten verwendet werden, die unterschiedlich behandelt werden müssen. (Für den Massendatenimport können auch andere Validierungsregeln gelten.)
  • Wenn die Überprüfung sehr komplex ist, möchten Sie möglicherweise andere Fehlermeldungen (oder keine) angeben, je nachdem, was für den Anrufer am nützlichsten ist. In anderen Situationen reicht möglicherweise true oder false aus. 

Es ist zwar möglich, diese unterschiedlichen Anwendungsfälle über Argumente der isValid()-Methode des Modells zu behandeln, dies wird jedoch mit zunehmender Anzahl von Validierungsstilen immer unhandlicher. (Und ich denke, es ist fast garantiert, dass eine einzelne "one size fits all" isValid()-Methode für die meisten nicht-trivialen Projekte letztendlich unzureichend ist.)

1
mjs

Verwechseln Sie nicht mit der Desinfektion oder Reinigung des angegebenen Werts durch Validierung. Sie sollten die veröffentlichten Werte abrufen und bereinigen, indem Sie schädliche Elemente aus den Werten im Controller entfernen. Senden Sie dann die Daten an das Modell, um die erwarteten Werte oder das Format zu überprüfen. Durch das Aufteilen dieser Aktionen in zwei Verfahren wird das Risiko verringert, dass schädlicher Code implementiert wird. Diese Methode funktioniert gut, wenn Sie die Richtlinie "Keine Eingabe vertrauen" verwenden. zu wissen, dass einige Programmierer schlampig oder faul werden können. Eine weitere positive Seite ist, dass Ihr Modell nicht aufgebläht und überarbeitet wird. Wenn ja, dann verwenden Sie einen Modellhelfer, um die Drecksarbeit zu erledigen. Dieser Ansatz hilft auch dabei, die Anwendungslast auszugleichen und die Leistung zu verbessern. 

0
Carl Barrett