Bei der Entwicklung meiner Schnittstellen (Verträge) und deren konkreten Implementierungen, sowohl der Datenmodelle als auch der Repositories, frage ich mich, wo die Validierungslogik hingehen sollte. Ein Teil von mir (der dazu neigt, sich durchzusetzen) sagt, dass die Klasse selbst für ihre eigene Validierung verantwortlich sein sollte (max. Länge der Zeichenfolge, Datumspuffer usw.), aber der andere Teil von mir sagt, dass dies in das Repository verschoben werden sollte Beim Persistenzspeicher können sich diese Werte basierend auf Ihrer Repository-Implementierung ändern.
Ich denke, es gibt einige Validierungen, die auf Klassenebene gemacht werden müssen und denken, dass sie wahrscheinlich zusammengehalten werden sollten und sich nicht ändern, selbst wenn das Repository dies tut, weshalb ich es in der Klasse halte.
Ich bin dabei, eine UI-Validierung durchzuführen, aber das reicht nie aus, da ein Großteil der UI-Validierung umgangen werden kann.
Neugierig, was die Leute denken und was dahinter steckt.
Validierungsregeln sollten auf Klassenebene abstrakt definiert werden, die sowohl 1) in der nativen Umgebung der Klasse ausgeführt werden können 2) je nach Bedarf als Regeln für andere abhängige Umgebungen wie UI-Scripting oder Repository-Prozeduren gerendert werden können.
Dadurch erhalten Sie die zentralisierte Logik, wo sie sein sollte, in der Klasse und die zusätzliche Validierung in der UI und wo auch immer - leicht wartbar, da sie von der Klasse abgeleitet ist und nicht losgelöste Logik ist, die an einem getrennten Ort lebt. Alleskönner gewinnen.
Wo sollte die Validierungslogik implementiert werden?
Überall.
Es mag eine Menge Arbeit oder zusätzlicher Overhead sein, aber die Realität ist, dass es gute Gründe gibt, alles entlang der Kette erneut zu validieren, von denen die wenigsten Bugs fangen, bevor sie zu einem Problem werden.
>-Adam
Ich hatte viel Erfolg damit, all meine Validierung so nahe an den Ort zu bringen, an dem die Daten in der Business-Schicht gespeichert werden. Z.B. in den Grundstücksverteilern. Dies garantiert, dass Sie nur gültige Daten innerhalb Ihrer Business-Schicht weitergeben und außerdem sicherstellen, dass die Benutzeroberfläche gültige Daten von der Business-Schicht erhält.
Zu einem gewissen Grad wird dadurch auch die Notwendigkeit einer hohen Validierung in Ihrer Datenschicht vermieden, wenn Ihr Code immer Ihre Business-Schicht durchläuft.
Die einzige Regel, über die ich dogmatisch bin, ist, niemals der Überprüfung der Benutzeroberflächenebene zu vertrauen, da diese Ebene am leichtesten kompromittiert ist (besonders in einer Webanwendung). Die Validierung auf der Benutzerebene ist eine Süßkraft, um Ihre Benutzerfreundlichkeit zu verbessern.
Ein Vertrag (Schnittstelle) zwischen zwei Parteien besagt, A und B, so dass beide bestimmte Verpflichtungen haben. Was sagt der Vertrag? Soll B validierte Daten erhalten? Wenn dies der Fall ist, sollte B keine Validierung durchführen. Aber was, wenn A die Benutzeroberfläche ist? Natürlich wollen Sie die Validierung nicht dort ablegen. Gewöhnlich ist es das Beste, eine dritte Partei einzuführen, sagen wir C. A hat einen Vertrag mit C, der wiederum einen Vertrag mit B hat. B erwartet validierte Daten. A könnte Mist senden. C führt die Validierung durch.
Wenn Verträge gut gestaltet sind, ist das fast nie ein Problem. Überarbeiten Sie den Vertrag und legen Sie Verpflichtungen für jede der Parteien fest. Wenn eine bestimmte Partei zu viele Verpflichtungen hat, dann führen Sie eine dritte Partei ein.
Sicherlich kann in einer Web-Umgebung alles, was Sie zur Validierung auf die Client-Seite legen, umgangen werden.
Im Allgemeinen habe ich die Validierung im Unterricht abgelegt. Lassen Sie dann die Setter eine Ausnahme auslösen oder werfen oder wenn Sie einen Rückgabewert verwenden möchten. Ich verwende Ausnahmen in der .Net-Welt, da ich eine Reihe von benutzerdefinierten Ausnahmen mit klaren Validierungsregelnachrichten haben kann, die an den Consumer / Client zurückgegeben werden.
Die Validierung sollte Teil des Objekts sein. Machen Sie die Umgebung zu einem Teil der Parameter für den Konstruktor des Objekts. Auf diese Weise können Sie die Validierungslogik für die Umgebung anpassen, aber das Objekt muss nicht herausfinden, wo es ausgeführt wird.
Ich benutze immer die UI-Validierung, obwohl es im besten Fall eine schwache Sicherheit ist. Es spart Rundreisen zum Server (die Bandbreite summiert sich) und erlaubt Ihnen, benutzerfreundlicher mit Fehlermeldungen zu sein. Aber es sollte niemals die einzige Ebene der Validierung sein.
Tags und Links standards oop validation