Ich versuche, zwischen zwei Mustern bezüglich der Datenvalidierung zu entscheiden:
Ich versuche, dem nominellen Workflow zu folgen und Ausnahmen abzufangen, die von meinen Modellen und Diensten ausgelöst werden: eindeutige / fremde Constraint-Verletzung, leere Felder, ungültige Argumente usw. (!! Ich fange nur Ausnahmen dass ich weiß, ich sollte)
pros: Sehr wenig Code zum Schreiben in meinen Controllern und Diensten: Ich muss nur Ausnahmen behandeln und sie in eine benutzerverständliche Nachricht umwandeln. Code sehr einfach und lesbar .
Nachteile: Ich muss bestimmte Ausnahmen schreiben , die manchmal sehr viele verschiedene Ausnahmen sein können. Ich muss auch generische PDO / Doctrine-Ausnahmen für Datenbankausnahmen (Constraint-Verletzungen, usw.) abfangen und analysieren, um sie in sinnvolle Ausnahmen zu übersetzen (zB: DuplicateEntryException ). Ich kann auch einige Validierung nicht umgehen : sagen wir, ein Objekt meines Modells ist als gesperrt markiert: zu versuchen, es zu löschen, wird eine Ausnahme auslösen. Ich möchte jedoch das Löschen erzwingen (zB mit einem Bestätigungsdialog). Ich werde die Ausnahme hier nicht umgehen können.
Ich testen und vorab alles explizit mit Code- und DB-Abfragen überprüfen. Zum Beispiel werde ich testen, dass etwas nicht null ist und eine Ganzzahl ist, bevor ich es als ein Attribut in meinem Modell setze. Oder ich mache eine DB-Abfrage, um zu überprüfen, dass ich keinen doppelten Eintrag erstellen werde.
pros: Es ist nicht nötig, bestimmte Ausnahmen zu schreiben , da ich alles vorher validiere, also sollte ich sowieso nicht viel versuchen / fangen. Auch Ich kann eine Validierung umgehen wenn ich möchte.
Nachteile: Viele Tests und Validierung zu schreiben in den Controllern, Diensten und Modellen. Ich werde mehr Abfragen durchführen (der Validierungsteil). Die DB führt bereits die Validierung für Fremdschlüssel, eindeutige Integritätsbedingungen und nicht für Null-Spalten durch ... Ich sollte das nicht ignorieren und selbst rekodieren. Auch dies führt zu sehr langweiligem Code !
Ich würde lieber ein Muster oder das andere verwenden, nicht eine Mischung, um die Dinge so einfach wie möglich zu halten.
Die erste Lösung scheint mir die beste zu sein, aber ich befürchte, es könnte eine Art Anti-Pattern sein? oder vielleicht hinter seiner theoretischen Einfachheit versteckt es Situationen sehr schwer zu handhaben?
Ich würde vorschlagen, dass die Datenvalidierung am Rand einer Anwendung stattfinden sollte. Das heißt, dass alle eingehenden Daten überprüft werden sollten, um sicherzustellen, dass sie Ihren Erwartungen entsprechen. Sobald es in der Anwendung erlaubt ist, wird es nicht mehr validiert, aber es wird immer nach Kontext (Datenbank, E-Mail usw.) escaped. Dies ermöglicht Ihnen, die gesamte Validierung zusammen zu halten und vermeidet die mögliche Duplizierung von Validierungsarbeiten (es ist einfach zu kommen mit Beispielen, wo Daten zweimal durch zwei Modelle validiert werden konnten, die beide verwenden.) Joe Armstrong fördert diesen Ansatz in seinem Buch über Erlang, und die Software, die er für Telcom-Stationen geschrieben hat, läuft seit Jahren ohne Neustart, also scheint es gut zu funktionieren: )
Außerdem stimmen die Modellerwartungen nicht immer perfekt mit den Erwartungen überein, die von einer bestimmten Schnittstelle ausgehen (vielleicht zeigt das Formular nur eine Teilmenge der möglichen Optionen, oder vielleicht hat die Schnittstelle ein Drop-down der US-Bundesstaaten und der Modellspeicher Staaten aus vielen verschiedenen Ländern usw.) Manchmal können komplexe Schnittstellen mehrere verschiedene Modellobjekte in einer Weise integrieren, die die Benutzererfahrung verbessert. Obwohl es für den Benutzer angenehm ist, kann die Interaktion dieser Modelle unter Verwendung des Ausnahmeansatzes sehr schwierig zu handhaben sein, da einige der Eingaben hybride Eingaben sein können, die kein Modell allein validieren kann. Sie möchten immer sicherstellen, dass die Validierung in erster Linie den Erwartungen der Benutzeroberfläche entspricht, und der zweite Ansatz ermöglicht Ihnen, dies selbst an den komplexesten Schnittstellen zu tun.
Auch die Ausnahmebehandlung ist in Bezug auf die Zyklen relativ teuer. Validierungsprobleme können ziemlich häufig auftreten, und ich würde versuchen, einen so teuren Vorgang für die Behandlung von Problemen zu vermeiden, als das Potential, ziemlich häufig zu sein.
Schließlich ist eine Validierung für das Modell nicht unbedingt notwendig, aber sie dient dazu, Angriffe zu verhindern. Während Sie diese Funktion dem Modell hinzufügen können, kann die zusätzliche Funktionalität den Modellcode schnell verschleiern.
Also, von diesen beiden Ansätzen würde ich den zweiten Ansatz vorschlagen, weil:
Tags und Links php exception-handling architecture exception validation