Ankündigung

Einklappen
Keine Ankündigung bisher.

Fehler von Model -> View

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • 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?

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

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

    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

    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.
    Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
    [URL]http://www.lit-web.de[/URL]

    Kommentar


    • #3
      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.
      [url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
      Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]

      Kommentar


      • #4
        Zitat von mepeisen Beitrag anzeigen
        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?
        Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
        [URL]http://www.lit-web.de[/URL]

        Kommentar


        • #5
          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);
              }

          [url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
          Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]

          Kommentar


          • #6
            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).

            Kommentar


            • #7
              Oh doch, das ist durchaus eine mögliche Lösung dafür. Guck dir meinen zweiten Beitrag noch einmal genau an
              [url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
              Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]

              Kommentar


              • #8
                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.ä.
                [COLOR="#F5F5FF"]--[/COLOR]
                [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                [COLOR="#F5F5FF"]
                --[/COLOR]

                Kommentar


                • #9
                  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.

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

                  Kommentar


                  • #10
                    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.
                    [COLOR="#F5F5FF"]--[/COLOR]
                    [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                    [COLOR="#F5F5FF"]
                    --[/COLOR]

                    Kommentar


                    • #11
                      Zitat von xm22 Beitrag anzeigen
                      Aber trotzdem sagt das noch nichts darüber aus, wie der User die konkreten Messages zu Gesicht bekommt.
                      Ähhm.
                      http://www.pp-blogsberg.de/2007/03/2...orderlich.html
                      Vielleicht in der Art? http://tobias-sch.de/images/content/fehler.gif

                      Also die Präsentation obliegt der View (dachte ich).
                      [url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
                      Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]

                      Kommentar


                      • #12
                        Nee Das meine ich auch nicht. Ich versuche mal, es etwas zu präzisieren.
                        Man hat eine MVC-Applikation.
                        Man hat ein Formular, mit dem man sich registriert. Um das zu vereinheitlichen gehen wir mal davon aus, dass es kein Formular-Objekt im Sinne von Zend_Form o. ä. gibt. Der Controller nimmt also die Daten entgegen und übergibt sie einem Model zur Validierung (Wie sinnvoll oder nicht sinnvoll das ist, sei für dieses Bsp. mal dahin gestellt). Nun validiert das Model die Daten und es treten Fehler auf (z. B. ist der Benutzername schon vergeben, die E-Mail-Adresse ist ungültig - so was in der Richtung.

                        Wie würdet ihr diese Fehler dem View zugänglich machen, damit dieses diese dem User anzeigen kann?

                        Kommentar


                        • #13
                          Zitat von xm22 Beitrag anzeigen
                          Nee Das meine ich auch nicht. Ich versuche mal, es etwas zu präzisieren.
                          Man hat eine MVC-Applikation.
                          Man hat ein Formular, mit dem man sich registriert. Um das zu vereinheitlichen gehen wir mal davon aus, dass es kein Formular-Objekt im Sinne von Zend_Form o. ä. gibt. Der Controller nimmt also die Daten entgegen und übergibt sie einem Model zur Validierung (Wie sinnvoll oder nicht sinnvoll das ist, sei für dieses Bsp. mal dahin gestellt). Nun validiert das Model die Daten und es treten Fehler auf (z. B. ist der Benutzername schon vergeben, die E-Mail-Adresse ist ungültig - so was in der Richtung.

                          Wie würdet ihr diese Fehler dem View zugänglich machen, damit dieses diese dem User anzeigen kann?
                          Na man kann doch zum Beispiel wenn man will (ob das so Sinn macht weiß ich nicht) ein Modeul zur Error Verarbeitung machen. Da hast du einen ErrorController drin und ne ErrorView. Du kannst mit einer Helfer Methode / Klasse im Model auf den Error Modul - Controller - Action weiterleiten und den Fehler ausgeben.
                          Man muss hier eben nur drauf achten keinen harten Redirect zu machen.
                          Anderer Weg wäre das du im Fehlerauftritt die View aus dem ErrorController an die View deine Registrierung übergibst und da dann einblendest.
                          Was anderes würde mir dann nun so nicht einfallen, bin ja alles andere als ein Profim aber zumindest ein bisschen Wissen habe ich nun mittlerweile.
                          Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
                          [URL]http://www.lit-web.de[/URL]

                          Kommentar


                          • #14
                            Und wo zwischenspeicherst Du die Fehlermeldungen?

                            Kommentar


                            • #15
                              Zitat von xm22 Beitrag anzeigen
                              Und wo zwischenspeicherst Du die Fehlermeldungen?
                              Das könntest du doch über einen Session Manager mittels eines dafür angelegten Session Namespace tun.
                              Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
                              [URL]http://www.lit-web.de[/URL]

                              Kommentar

                              Lädt...
                              X