Fehler von Model -> View

xm22 · 28.09.2011, 14:17

Ich glaube, das wurde (zumindest am Rande) schon mal besprochen, aber ich finde es nicht mehr.

Und zwar stehe ich vor folgender Frage. Ich würde gerne Richtung Thin Controller, Fat Models tendieren. Das würde für mich bedeuten, auch (zumindest Teile der) Validierungen in das Model zu verlegen. Wie sollte man nun am besten Fehlermeldungen, die vom Model generiert werden, ans View übergeben. Dazu fallen mir drei Möglichkeiten ein:
- Ein globales "Message-Objekt", dass vom Model befüllt wird (Gefällt mir nicht besonders gut)
- Das Model speichert beim Validieren alle aufgetretenen Fehler in einem Array o. ä. und der Controller holt sie sich dann bei Bedarf via getLastErrors oder so was in der Richtung.
- Das Model bekommt ein Objekt, das es mit Meldungen befüllen kann - Hier stelle ich mir das aber etwas kompliziert vor, wenn es um mehrstufige Validierungen geht, denn dann müsste ja jedes Mal dieses Objekt mit durchgereicht werden..

Was ist eure Meinung dazu?

litterauspirna · 28.09.2011, 15:23

Naja bleibt die Frage offen von welchen Validierungen du hier überhaupt redest.

Zitat:

a) Validierungen die aus dem View heraus gemacht werden sollen, z.B. falsch Eingaben oder fehlende Eingaben.

oder aber

Zitat:

b) Plausibilitätsprüfungen, wie soll der Eintrag mit einem Datum gemacht werden was älter als das aktuelle ist, aber in einem speziellen Fall nicht älter sein darf.

oder

Zitat:

c) Datenbankseitig oder Dateiseitge Prüfung ob der Datensatz erfolgreich hinzugefügt oder bearbeitet wurde.

zu a) Diese Validierungen haben mMn nichts im Model zu suchen, dafür hast du den Action Controller wo das gemacht wird.

zu b) kann man durchaus im Model machen, da könntest du an die Modelmethode ein Request Objekt übergeben und dann einen Forward oder Redirect zu einem Error Action Conroller machen der dir dann deine jeweilige / n Error Message / s über ein Action View ausgibt.

zu c) Das sollte man mMn unbedingt im Model machen weil man da ja genau an dem Datenspeichermedium Prüfungen vornimmt, aber auch muss das Request Object an deine Modelmethode z.B. via DI übergeben werden.

Die Frage hier ist natürlich ob ein Request Object etwas im Model bzw. einer Model Methode zu suchen hat.

mepeisen · 28.09.2011, 15:41

zu a) Da würde ich teilweise widersprechen. ABER: Ich tendiere eher zu einer zusätzlichen Business-Schicht, die viele Validierungen übernimmt. Das Model selbst ist hingegen relativ dumm. Das hat vor allem den Hintergrund, dass ich eher modular und SOA-orientiert die Persistenzschicht anspreche und nicht von Controller ausgehend direkt in einem Model herumfurwerke.
Das hat auch den Vorteil, dass unterschiedlichste Controller (HTML, Ajax, SOAP) nicht alles doppelt und dreifach implementieren müssen.

litterauspirna · 28.09.2011, 15:46

Zitat:

Zitat von mepeisen

zu a) Da würde ich teilweise widersprechen.

Warum und in welchen Bezug? Ich bin ja auch immer am dazu lernen und da würde mich die Aussage dann begründet schon interessieren. Danke schon mal dafür.

Mit der zusätzlichen Buiseness Schicht meinst da damit Helfer Klassen?

mepeisen · 28.09.2011, 16:25

Eine Begründung habe ich ja bereits gegeben. Es gibt u.U. mehrere Controller, die am gleichen Modell herumfurwerken. Beispielsweise pfuscht die Registrierung am "User-Objekt" herum, es pfuscht der Admin-Bereich am User herum. Vielleicht gibt es noch einen Open-ID-Login. Es gibt vielleicht eine programmierbare XML-Schnittstelle, die von einer iPhone-App bedient wird. Und bevor ich an 5 verschiedenen Ecken die Länge des Benutzernamens auf 50 Zeichen begrenze wandert das viel lieber in eine zentrale Ecke.
Das sieht dann (in Prosa) folgendermaßen aus:

Code:

Client -> Server: Tu mal registrieren
Server -> Controller: Tu mal Anfrage verarbeiten
Controller: Aufbereten der Daten aus dem Request und aus dem Formular, Nicht-Modell-bezogene Prüfungen (Beispielsweise Häckchen AGB)
Controller -> Business-Helferlein: Lege mal Benutzer an bitte
Business-Helferlein: Benutzername valide? Benutzername doppelt?
Business-Helferlein -> Persistenz: Alles OK, dann tu mal abspeichern

Im Prinzip ist die Business-Schicht natürlich eine einfache Hilfsklasse, an die man einen Teil der Arbeit delegiert. Es bietet sich an, das dann SOA-basierend aufzubauen, das ist aber kein Zwang.

Ich persönlich habe diese Businness-Schicht im Sinn von Services. Dort gibt es dann in der UserService-Klasse eine Methode "createUser". azu gibt es Request- und Response-Klassen (einfache Container sind das). Im Response ist zudem eine Vererbung zu einer Basis-Response-Klassen. Fehler sollen von der Business-Klasse immer mittels eines Codes zurückgegeben werden.

So wird dann in etwa folgendes aus Sicht des Controllers daraus:

PHP-Code:

  $userData['username'] = isset($_POST['username']) ? $_POST['username'] : null; // null kann man hier bereits abfangen bevor man an die Businness-Logik geht, generell sollte die Business-Logik aber auch leere Benutzernamen abweisen.

$request = new UserCreateRequest();

$request->setUserData($userData);

$response = $userService->createUser($request);

if ($response->successful()) {

    $view->assign('OK', true);

}

else {

    $view->assign('OK', false);

    $view->assign('ErrorCode', $response->getErrorCode());

    $view->assign('ErrorMsg', $response->getErrorMessage());

    if ($response->hasErrorCode('DUPLICATE_USER_NAME')) {

        $view->assign('DuplicateUser', true);

        $suggestions = $this->getOtherSuggestedUserNames(5); // soll beispielsweise 5 neue und noch nicht vergebene Vorschläge ermitteln

        $view->assign('Suggestions', $suggestions);

    }

}

xm22 · 28.09.2011, 16:51

Die Antworten sind sehr interessant, aber das war nicht die Fragestellung

Ich wollte wissen, wir ihr Meldungen in das View bringt, wenn _im_ Model eine Validierung einen Fehler erzeugt hat (Irgendeiner, der dem User angezeigt werden soll).

mepeisen · 28.09.2011, 17:10

Oh doch, das ist durchaus eine mögliche Lösung dafür. Guck dir meinen zweiten Beitrag noch einmal genau an

nikosch · 28.09.2011, 17:44

Ich würde die Validierung im Model verorten, allerdings als eigenständiges Objekt, möglicherweise verknüpft mit einem ebenfalls eigenständigen Form-Elemente-Modell(-objekt). Die konkrete Validierung enthält dann das Ergebnis - wie viele Felder fehlgeschlagen sind, welche Felder, welche spezifischen Messages für die einzelnen Fehlerfälle definiert sind. Man darf nicht vergessen, diese Nachrichten hängen u.U. ab von
- Name/Label des Elements
- i18n
- Validierungsproblem/methode (leer obwohl NOT NULL, ungültiges Format, zu lang, zu kurz…)
- dem Vergleich mit anderen Elementen (Passwortwiederholung…), dementsprechnd eine individuelle Meldung

Die View kennt das Model, holt sich bei Bedarf (direkt oder über eine Methode) das Validierungsobjekt und dort a) die Menge ungültiger Felder, b) die Messages, c) nur die erste Message o.ä.

xm22 · 28.09.2011, 17:51

Zitat:

Oh doch, das ist durchaus eine mögliche Lösung dafür. Guck dir meinen zweiten Beitrag noch einmal genau an

Eine Antwort zu meiner Frage habe ich jetzt nur in b erkannt

Dort schreibst Du ja von einem Forwarding, was ja auch ok ist. Aber trotzdem sagt das noch nichts darüber aus, wie der User die konkreten Messages zu Gesicht bekommt.

Zitat:

Die View kennt das Model

Was meinst Du hier mit Model? Das genannte Model oder das Form-Objekt?

nikosch · 28.09.2011, 18:01

Der Client adressiert mit seinem Request (Form Submit) als Nachricht den Controller
Dieser weist das Model an, anfallende Formdaten zu validieren. Je nach Erfolg wählt er eine geeignete View an oder stößt einen Subcontroller für eine Folgeaktion aus.
Betrachtet man das MVC als Pattern der Präsentationsschicht, dann stellt für mich das Model die Gesamtheit der Struktur- und Geschäftslogik des Forms dar, während die View die Art der Darstellung bestimmt.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
[Erledigt] Zip Archive mit PHP erstellen - Kein Fehler, aber ZIP Archiv ist nicht da	robat	PHP Tipps 2010	34	09.03.2011 20:17
[Erledigt] session_start - Fehler	Schmuse	PHP Einsteiger	6	03.03.2011 13:42
Sqlite3 "Update", Fehler bei mehr als 1 "Set" Anweisung	skerge12	Datenbanken	4	21.12.2010 09:45
Funktion rename() auf USB-Festplatten bringt Fehler	Wing	PHP Tipps 2010	13	16.07.2010 23:00
MySQL: Fehler 10046 keine Datenbank ausgewählt	aschunk	Datenbanken	5	22.04.2010 12:27
[Erledigt] Syntax Error - Wo ist der Fehler?	Extremefall	PHP Tipps 2009	5	14.12.2009 17:46
[Erledigt] vista, windows update Fehler 80070422	Screeze	Off-Topic Diskussionen	3	23.09.2009 18:24
Zend_Controller_Router_Route routet nach der View	boolean	PHP-Fortgeschrittene	10	13.08.2009 11:12
[Erledigt] Fehler bei Array ausgabe	newWorldOrder	PHP Tipps 2009	2	23.02.2009 17:29
[Erledigt] Seite wird nicht angezeigt, untersch. Fehler bei IE/FF/Safar		PHP-Fortgeschrittene	19	31.05.2005 14:52
Blöder MySQL Fehler		PHP Tipps 2005	3	15.05.2005 03:14
Fehlermeldung - aber kein fehler...	Tschuu	HTML, Usability und Barrierefreiheit	16	14.03.2005 15:56
Wo liegt der fehler??		PHP-Fortgeschrittene	5	22.12.2004 09:54
array_push nur in begrenzter Anzahl ausführen ?		PHP Tipps 2004	2	07.09.2004 09:05

28.09.2011, 14:17
xm22 Erfahrener Benutzer Registriert seit: 30.07.2008 Beiträge: 1.169 PHP-Kenntnisse: Fortgeschritten	Fehler von Model -> View Ich glaube, das wurde (zumindest am Rande) schon mal besprochen, aber ich finde es nicht mehr. Und zwar stehe ich vor folgender Frage. Ich würde gerne Richtung Thin Controller, Fat Models tendieren. Das würde für mich bedeuten, auch (zumindest Teile der) Validierungen in das Model zu verlegen. Wie sollte man nun am besten Fehlermeldungen, die vom Model generiert werden, ans View übergeben. Dazu fallen mir drei Möglichkeiten ein: - Ein globales "Message-Objekt", dass vom Model befüllt wird (Gefällt mir nicht besonders gut) - Das Model speichert beim Validieren alle aufgetretenen Fehler in einem Array o. ä. und der Controller holt sie sich dann bei Bedarf via getLastErrors oder so was in der Richtung. - Das Model bekommt ein Objekt, das es mit Meldungen befüllen kann - Hier stelle ich mir das aber etwas kompliziert vor, wenn es um mehrstufige Validierungen geht, denn dann müsste ja jedes Mal dieses Objekt mit durchgereicht werden.. Was ist eure Meinung dazu?


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

28.09.2011, 15:41
mepeisen Erfahrener Benutzer Registriert seit: 21.12.2004 Beiträge: 5.246 PHP-Kenntnisse: Fortgeschritten	zu a) Da würde ich teilweise widersprechen. ABER: Ich tendiere eher zu einer zusätzlichen Business-Schicht, die viele Validierungen übernimmt. Das Model selbst ist hingegen relativ dumm. Das hat vor allem den Hintergrund, dass ich eher modular und SOA-orientiert die Persistenzschicht anspreche und nicht von Controller ausgehend direkt in einem Model herumfurwerke. Das hat auch den Vorteil, dass unterschiedlichste Controller (HTML, Ajax, SOAP) nicht alles doppelt und dreifach implementieren müssen. __________________ www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

28.09.2011, 16:25
mepeisen Erfahrener Benutzer Registriert seit: 21.12.2004 Beiträge: 5.246 PHP-Kenntnisse: Fortgeschritten	Eine Begründung habe ich ja bereits gegeben. Es gibt u.U. mehrere Controller, die am gleichen Modell herumfurwerken. Beispielsweise pfuscht die Registrierung am "User-Objekt" herum, es pfuscht der Admin-Bereich am User herum. Vielleicht gibt es noch einen Open-ID-Login. Es gibt vielleicht eine programmierbare XML-Schnittstelle, die von einer iPhone-App bedient wird. Und bevor ich an 5 verschiedenen Ecken die Länge des Benutzernamens auf 50 Zeichen begrenze wandert das viel lieber in eine zentrale Ecke. Das sieht dann (in Prosa) folgendermaßen aus: Code: Client -> Server: Tu mal registrieren Server -> Controller: Tu mal Anfrage verarbeiten Controller: Aufbereten der Daten aus dem Request und aus dem Formular, Nicht-Modell-bezogene Prüfungen (Beispielsweise Häckchen AGB) Controller -> Business-Helferlein: Lege mal Benutzer an bitte Business-Helferlein: Benutzername valide? Benutzername doppelt? Business-Helferlein -> Persistenz: Alles OK, dann tu mal abspeichern Im Prinzip ist die Business-Schicht natürlich eine einfache Hilfsklasse, an die man einen Teil der Arbeit delegiert. Es bietet sich an, das dann SOA-basierend aufzubauen, das ist aber kein Zwang. Ich persönlich habe diese Businness-Schicht im Sinn von Services. Dort gibt es dann in der UserService-Klasse eine Methode "createUser". azu gibt es Request- und Response-Klassen (einfache Container sind das). Im Response ist zudem eine Vererbung zu einer Basis-Response-Klassen. Fehler sollen von der Business-Klasse immer mittels eines Codes zurückgegeben werden. So wird dann in etwa folgendes aus Sicht des Controllers daraus: PHP-Code: $userData['username'] = isset($_POST['username']) ? $_POST['username'] : null; // null kann man hier bereits abfangen bevor man an die Businness-Logik geht, generell sollte die Business-Logik aber auch leere Benutzernamen abweisen. $request = new UserCreateRequest(); $request->setUserData($userData); $response = $userService->createUser($request); if ($response->successful()) { $view->assign('OK', true); } else { $view->assign('OK', false); $view->assign('ErrorCode', $response->getErrorCode()); $view->assign('ErrorMsg', $response->getErrorMessage()); if ($response->hasErrorCode('DUPLICATE_USER_NAME')) { $view->assign('DuplicateUser', true); $suggestions = $this->getOtherSuggestedUserNames(5); // soll beispielsweise 5 neue und noch nicht vergebene Vorschläge ermitteln $view->assign('Suggestions', $suggestions); } } __________________ www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

28.09.2011, 16:51
xm22 Erfahrener Benutzer Registriert seit: 30.07.2008 Beiträge: 1.169 PHP-Kenntnisse: Fortgeschritten	Die Antworten sind sehr interessant, aber das war nicht die Fragestellung Ich wollte wissen, wir ihr Meldungen in das View bringt, wenn _im_ Model eine Validierung einen Fehler erzeugt hat (Irgendeiner, der dem User angezeigt werden soll).

28.09.2011, 17:10
mepeisen Erfahrener Benutzer Registriert seit: 21.12.2004 Beiträge: 5.246 PHP-Kenntnisse: Fortgeschritten	Oh doch, das ist durchaus eine mögliche Lösung dafür. Guck dir meinen zweiten Beitrag noch einmal genau an __________________ www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

28.09.2011, 17:44
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.994 PHP-Kenntnisse: Fortgeschritten	Ich würde die Validierung im Model verorten, allerdings als eigenständiges Objekt, möglicherweise verknüpft mit einem ebenfalls eigenständigen Form-Elemente-Modell(-objekt). Die konkrete Validierung enthält dann das Ergebnis - wie viele Felder fehlgeschlagen sind, welche Felder, welche spezifischen Messages für die einzelnen Fehlerfälle definiert sind. Man darf nicht vergessen, diese Nachrichten hängen u.U. ab von - Name/Label des Elements - i18n - Validierungsproblem/methode (leer obwohl NOT NULL, ungültiges Format, zu lang, zu kurz…) - dem Vergleich mit anderen Elementen (Passwortwiederholung…), dementsprechnd eine individuelle Meldung Die View kennt das Model, holt sich bei Bedarf (direkt oder über eine Methode) das Validierungsobjekt und dort a) die Menge ungültiger Felder, b) die Messages, c) nur die erste Message o.ä. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

28.09.2011, 18:01
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.994 PHP-Kenntnisse: Fortgeschritten	Der Client adressiert mit seinem Request (Form Submit) als Nachricht den Controller Dieser weist das Model an, anfallende Formdaten zu validieren. Je nach Erfolg wählt er eine geeignete View an oder stößt einen Subcontroller für eine Folgeaktion aus. Betrachtet man das MVC als Pattern der Präsentationsschicht, dann stellt für mich das Model die Gesamtheit der Struktur- und Geschäftslogik des Forms dar, während die View die Art der Darstellung bestimmt. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --