Daten für Datenbank validieren - Wer übernimmt: Model oder Controller?

2nd

Aktives Mitglied
Thread Starter
Dabei seit
25.07.2004
Beiträge
9.018
Reaktionspunkte
243
Moin,

wie ich ja woanders schrub (;)), bastle ich gerade mit MVC rum.

Über eine Frage sinniere ich seit längerem und finde zu keiner zufrieden stellenden Antwort.

Nehmen wir mal an, mein Model heisst "news".

Das Model "news" hat folgende Methoden:

• news->insert()
• news->update()

Ich bewege mich im entsprechenden Controller meiner Anwendung, dieser ist mit $this referenziert. Ferner habe ich noch eine Inputklasse, die die $_POST Daten "vor"gereinigt enthält.

Es geht nun um diese Daten, die aus einem Userformular kommen: Wer validiert diese? Soll die Validierung fest ans Model gebunden werden:

PHP:
$errorCode = $this->news->insert($this->input);
if ( $errorCode > 0 )
{
   $viewdata['errorCode'] = $errorCode;
}
else
{
   // alles super!
}

Oder sollte die Validierung der Controller übernehmen, zum Bsp. so:

PHP:
if ( $this->input->validation() == false )
{
   viewdata['errorCode'] = $this->input->errorCode;
}
else
{
   $this->news->insert($this->input);
}


Die Validierung ans Model zu binden behagt mir mehr, da man so aus allen möglichen Controllern die Möglichkeit hätte, auf CRUD-Operationen eines betehenden Models zurückzugreifen, ohne die Validierung jedes Mal neu an den entsprechenden Controller zu binden.

Ich brauche 'ne Offenbarung :=)

Cheers,

2nd
 
Wenn Du Dir das STRUTS-Framework der 1.x Version anschaust, dann liegt die Valisierung im Model. Dabei handelt es sich um eine Methode, die den Request prüft bevor der Controller gerufen wird.
 
Bei den PHP Frameworks ist es oft so, dass der aufgerufene URI via Bootstrapper (index.php) zum entsprechenden Controller geroutet wird, der dann die benötigten Klassen/Models/Libaries instanziert/läd. Davor einzugreifen wäre meiner Meinung nach ein Bruch mit der Philosophie. Aber meine Meinung heisst nichts :p.

Das mit dem Model und der Validierung ist ja schonmal eine Ansage.

Wahrscheinlich ist es bei STRUTS so, dass man im Model die Fields, dazugehörigen Datentypen und Validierungsregeln festlegt oder?

Cheers,

2nd
 
zu Struts kann ich nichts sagen, ich nutze JSF. Dort ist es üblich das man das Datenmodell in einer BackingBean ( entspricht quasi einer simplen PHP-Klasse die eben nur die verschiedenen Daten nebst Getter() und Setter() bereithält) hält.

Validatoren im View prüfen auf passendes Eingabeformat und Converter konvertieren String-Eingaben in passende Datentypen. Es werden also Converter und Validator-Klassen geschrieben die dann per XML eingebunden werden. Das die teilweise auch im View passiert macht insofern Sinn, als ich da ja auch wieder hin muß um den Benutzer zu informieren und um korrigierte Eingabe zu bitten! Wenn ich erst prüfe unmittelbar bevor ich schreibe ist das IMHO zu spät. Ein Objekt muß immer konsistent sein, auch bevor ich schreibe. Will sagen: das Formular ist ein View und nach Beendigung des Views hat das Objekt korrekt zu sein. Somit muß die Validierung bis in den View greifen. Die Logik dazu steht IMHO mit beim Modell.

EDIT: JSF hält alle Komponenten eines Views in einem Baum den es für jeden Request aktualisiert und dabei geziehlt Phasen durchläuft, beschrieben z.B. hier:

http://www.fh-wedel.de/~si/seminare/ws06/Ausarbeitung/10.JavaServerFaces/jsf2.html
 
Zuletzt bearbeitet:
Die Logik dazu steht IMHO mit beim Modell.

Was meinst du genau mit Logik wegus? Darunter versteht irgendwie jeder etwas anderes. Meinst Du damit die Datentypen und Validierungsregeln?

So weit ich das bzgl. des JSF Ansatzes verstehe:

1. gibt es ein Model mit Datenfeldern und dazugehörigen Rules ('required', 'string' usw.) -> Datenmatrix
2. diese "Datenmatrix" wird an den View übergeben, der daraufhin so lange das Formular durchläuft, bis die Datenmatrix den 'valid state' erreicht hat.
3. anschliessend wandert die Datenmatrix gefüllt mit Inhalte in das Model zurück und wird persistent gemacht?

Ist das richtig?

Dieses Vorgehen unterstützt meine Motivation, den ganzen Quatsch nicht doppelt und dreifach schreiben zu müssen. Zur Zeit lege ich die Datenfelder im Model (MySQL DB) fest und muss parallel dazu die Validerungsregeln in der Inputklasse anlegen. Danach schreibe ich das alles nochmal in die Views in Form von HTML-Inputs, -Textareas usw.. Das ist gar nicht DRY...

Beispiel:

DB mit Spalte: news.title
Input mit Regel: title[required|alphanumerical|min_length[5]]
View mit Input: input type="text" name="title"


Cheers,

2nd
 
2nd schrieb:
1. gibt es ein Model mit Datenfeldern und dazugehörigen Rules ('required', 'string' usw.) -> Datenmatrix
2. diese "Datenmatrix" wird an den View übergeben, der daraufhin so lange das Formular durchläuft, bis die Datenmatrix den 'valid state' erreicht hat.
3. anschliessend wandert die Datenmatrix gefüllt mit Inhalte in das Model zurück und wird persistent gemacht?

Ist das richtig?

Nicht ganz! Im Gegensatz zu PHP läuft die Java VM halt ständig, also nicht nur beim Request oder beim ausliefern der Response für den Browser. Du hast dann mehre Dinge. Zum einen die Klasse die Deine Datenstruktur kapselt ( das was Du Matrix nennst). Konverterklassen, die z.b. ein Inputfeld in ein Java GregorianCalendar umwandeln o .Ä., Du hast Validatorklassen die z.B. prüfen ob ein gegebener String auch die Form eines z.B. Datums hat (TT.MM.JJJJ).

All dies sind zunächst Java-Klassen die man Job-unabhängig erstellt ( gerade Validatoren und Konverter kann man ja x-mal verwenden).

Damm erstellt man eine JSP (Java-ServerPage) die man um JSF-Tags erweitert ( einfach in dem man eine weitere Tag-Library hinzufügt). Das ist dann quasi erweitertes HTML, es gibt einfach mehr Tags.

Die einzelnen Inputfelder bekommen dann Validatoren ( bei Bedarf mit Max/Min-Werten) zugewiesen, sowie Konverter soweit das nötig ist. Auch ein error-Message-Feld wird definiert ( etwa "125,- ist kein Datum!"). Ebenfalls wird definiert mit welchem Element aus Deiner Datenklasse dieses Feld verbunden ist.

Lesen des wertes ( für Vorgaben) aus der Klasse, sowie das Schreiben in die Klasse erfolgt automatisch ab da und zwar mit Hilfe des Konverters. Fehler beim Konvertieren ( oder auch schon beim validieren) führen dazu das die Ursprungsseite erneut dargestellt wird. Konverter oder Validator nutzen das Error-Feld um zu beschreiben was falsch war.

Sind die Daten korrekt wird, gemäß Navigationsregeln, eine Zielseite angesprungen. Diese Regeln können statisch sein oder das Resultat einer Methode. Entwder der Datenklasse oder aber einer Request-, Session oder gar Applikationsklasse.

Dabei erstellt man halt alle Logik in einem Source-Baum - egal ob Datenmodell (Fachklasse) oder Konverter/Validator und man erstellt Views in Form von speziellen JSP-Seiten (JSF in diesem Fall).

Die Verbindung zwischen all dem wird mit XML-Dokumenten hergestellt. So werden etwa Fachklassen mit ihren Sichtbarkeiten ( Request,Session,Applikaton) definiert und Verzweigungsregeln definiert. Dies geschieht unabhängig von den Source-Klassen. Die Programmier von Letzteren brauchen nichtmal Ahnung von JSF zu haben.

Der Vorteil eines Applikationsservers ist halt das die Applikation weiterläuft - jederzeit. Und es so eine Instanz über der Session gibt, die z.B. DB-Connects teilen kann...

Der Aufwand ist um einiges größer, ab einer gewissen Projektgröße jedoch mehr als sinnvoll und leider kann PHP da nicht in allen Belangen mitziehen. Mit PHP hat man ein Projekt sicher deutlich schneller fertig, aber es ist nicht ganz so wart- und skalierbar.


hier hab ich das mal gelernt:

http://www.jsftutorials.net/

Nötig ist eine Java IDE (Netbeans oder Eclipse), Ein Java-Appserver ( Apache Tomcat - am Anfang nicht komplexer) und die Web-Tools und JSF-Libs der IDE. Für den Anfang ( da all in one) ist Netbeans am einfachsten, später flexibler ( und leider QUasistandard) ist Eclipse ( das Windows der IDEs :D ). Struts war früher mal der Stand der Dinge und es hat einen etwas anderen Ansatz. Heute stürzt sich alle Java-Welt auf JSF das etwas flexibler und IMHO auch eingängier ist. Nichtsdestotrotz gibt es Struts weiterhin und auch den Versuch einer PHP-Version davon.

2nd schrieb:
Beispiel:

DB mit Spalte: news.title
Input mit Regel: title[required|alphanumerical|min_length[5]]
View mit Input: input type="text" name="title"

In Ermangelung eines JSF für PHP (kann es technisch so gar nicht geben!) tue ich dies dort auch! Wobei es eben gute Frameworks gibt die zumindest MVC erleichtern. Persistenz habe ich mir sowohl unter Java als auch unter PHP selbst entickelt. Wobei der Java-Part in der Umsetzung von einem Kollegen von mir stammt ( dem ich eh 99% meines Java-Wissens verdanke :) )
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: 2nd
Danke wegus für Deine megaausführliche Antwort. Das Stichwort ist wohl bei Java Runtime-Environment - das gleich Prinzip wie im Flash. Deswegen kann man über Listener permanent des Zustand eines Objektes abfragen und auswerten.

Damit komme ich natürlich bei PHP nicht weit. Aber muss ich auch nicht, da ich nicht vorhabe, auf Java umzusteigen.

Mir geht es um einen Lösungsansatz, der mein freiberufliches Forschungsleben in Richtung nachhaltiger Konzepte lenkt.

Auf jeden Fall habe ich bis jetzt aus diesem Thread ein paar wertvolle Anregungen herauslesen können - vielen Dank dafür an alle.

Den Django-Artikel habe ich zum grossen Teil gelesen, das ist auch ganz schnieke. Ich denke, ich werde mal in die Richtung coden, also eine Formularklasse, an die ich die Fields aus dem Model binden kann. Validiert wird dann direkt in der Formularklasse, allerdings nach den Vorgaben vom Model. So kriege ich wahrscheinlich auch den View automatisiert...

Cheers,


2nd
 
Zurück
Oben Unten