Ankündigung

Einklappen
Keine Ankündigung bisher.

Controller <-> Model: Wohin mit der Logik?

Einklappen

Neue Werbung 2019

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

  • #16
    Die Setter sind dabei so abgesichert, daß bei ungültigen Werten eine z.B. InvalidArgumentException geworfen wird.

    Und das ist keine Validierung?
    Ich würde es nicht als Validierung bezeichnen, genau so wenig wie man z.B. bei TypeHinting von Validierung sprechen würde.

    Bei einer atomaren Operation die aus mehreren aufeinanderfolgenden Teilprozessen besteht, bei denen mindestens einer der Prozesse kein Validierungsprozess ist (z.B. Validierung + das Werfen einer Exception) kann man nicht mehr nur von Validierung sprechen. Genau so, wie man bei einer Firewall auch nicht vom Validator sprechen kann.

    WO wäre die Validierung der Daten deiner Meinung nach am Besten aufgehoben? Warum nicht dem Model überlassen?�*
    Möchtest Du Dein Model vor ungültigen Daten beschützen oder möchtest Du nur wissen ob diese Daten gültig sind? Es sind zwei komplett verschiedene Aufgaben. Ersteres sollte immer im inneren eines Models geschehen und kann sich intern natürlich auch eines Validators bedienen. Aber es geht hierbei nicht nur um Validierung, sondern vor allem um den Schutz des Modells. Eine PropertyFirewall sozusagen. Letzteres sollte meiner Ansicht nach extern, also außerhalb des Models passieren und ist die Aufgabe eines Validators. Weshalb, na weil es z.B. die zu prüfenden Modell-Daten schon geben kann, noch bevor das Modell existiert

    PHP-Code:
    $user = new User($input);
    If(!
    $user->isValid()) {
        unset(
    $user);

    oder

    PHP-Code:
    if($validator->isValid($input)) {
        
    $user = new User($input);

    vg
    jack
    -

    Kommentar


    • #17
      Du kannst auch mal auf laracasts.com nachschauen. Besonders empfehlenswert für den Einstieg finde ich die 2 SerienLaravel from Scratch und Digging In. Bei der zweiten Serie ist offenbar nur (noch?) das erste Video gratis, zeigt aber die Dinge in der Praxis. Validation ist da unter anderem ein Schwerpunkt, und der Vorteil ist das es direkt in Laravel umgesetzt wird. Kurz gefasst: Er hält die Models und die Controller klein, indem Dinge wie z.B. Validation-Logik in eigene Services/ServiceProvider ausgelagert wird. Auch wenn du die Videos ohne Abo (ist vermutlich aber auch sehr empfehlenswert, wenn ich mir die Titel der Videos anschaue) nicht ansehen kannst, gibt es denke ich auf GitHub oder bei den Kommentaren zumindest den Quelltext, damit du dir das ansehen kannst.

      Kommentar


      • #18
        also ich gehe da zb einen anderen weg, ich schreibe mir eine abstrakte validator klasse und eine Datenstruktur(Klasse mit Public eigenschaften). Dann einen abstrakten validator der ein typehint zu der Datenstruktur bereitstellt und eine Konkreten framework validator wrapper, dessen aufgabe besteht darin, die datenstruktur zu validieren.

        im Controller(bzw Interaktor) uebergebe ich daten aus dem Request und aus der Repository an meine Datenstruktur. Die Datenstruktur ist ein Mix aus formularfeldern und einigen booleans aus der Datenbank. ich sammle quasi zunaechst alle daten die fuer den validator notwendig sind zusammen und lasse es dann vom framework validator validieren.

        Aktuell habe ich es noch sehr umstaendlich geloest aber daran arbeite ich noch.

        Konkret sieht das ganze etwa so aus:
        Datenstruktur der Registrierung zb
        https://github.com/Opentribes/Core/b...gistration.php

        Abstrakter validator fue meine geschaeftslogik
        https://github.com/Opentribes/Core/b.../Validator.php

        Typehint validator, damit da kein Quatsch ubergeben wird
        https://github.com/Opentribes/Core/b...gistration.php

        Framework validator wrapper
        https://github.com/Opentribes/Core/b...gistration.php

        da muesste ich eigentlich noch configurationen und fehlermeldung als objekt im constructor uebergeben(steht auf meiner Todo)

        Zuweisen der Validator daten im Controller/Interactor

        https://github.com/Opentribes/Core/b...ration.php#L73

        Der vorteil aktuell ist, dass du keine komischen verbiegungen in bestimmten usecases machen musst irgendwie ein Model laden und dann doch nicht und dinge ueberpruefen wie password wiederholen, obwohl das Model dieses feld nicht hat usw usw. du hast halt eine Datenstruktur mit speziellen feldern, auch wenn viele der felder dem model aehneln, haste da auch speziall dinge und der validator validiert nur das Objekt, es ist nur von der Datenstruktur abhaengig aber nicht von der Datenbank.

        Nachteil, es ist irgendwie scheisse umgesetzt bei mir da ich fuer jeden usecase eine eigene datenstruktur + typehint validator baue + die konkrete umsetzung dann
        apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

        Kommentar


        • #19
          Zitat von G.Schuster Beitrag anzeigen
          Ein von mir entwickeltes Model-Konzept setzt dazu eben auf Settern auf, wobei die Validatoren beim Init des Models angelegt werden und damit auch für eine "Array-Befüllung" problemlos zur Verfügung stehen.
          Wie bildest du dann aber "komplexe" Regeln ab? Z.B. es kann kein gelbes Auto von VW geben, aber das Auto muss gelb sein wenn es von BMW kommt?

          Kommentar


          • #20
            Zitat von erc Beitrag anzeigen
            Wie bildest du dann aber "komplexe" Regeln ab? Z.B. es kann kein gelbes Auto von VW geben, aber das Auto muss gelb sein wenn es von BMW kommt?
            eine property $isValidatColor im datenmodel und im controller dann anhand von daten von irgendwoher die dann setzen
            apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

            Kommentar


            • #21
              Wie bildest du dann aber "komplexe" Regeln ab? Z.B. es kann kein gelbes Auto von VW geben, aber das Auto muss gelb sein wenn es von BMW kommt?
              Strenggenommen ist das keine Aufgabe für einen Validator, das sind Geschäftsregeln der Domain und

              eine property $isValidatColor im datenmodel und im controller dann anhand von daten von irgendwoher die dann setzen
              Geschäftsregeln gehören meiner Ansicht nach nicht in irgendwelche Controller sondern in entsprechende Geschäftsobjekte.

              vg
              jack
              -

              Kommentar


              • #22
                Zitat von jack88 Beitrag anzeigen
                Geschäftsregeln gehören meiner Ansicht nach nicht in irgendwelche Controller sondern in entsprechende Geschäftsobjekte.
                jo, dann man eben eine CarColorRepository mit einer Methode colorExistsForModel('gelb','vw');

                solange dem validator nur darum geht ob die farbe valide ist oder nicht und er das nicht herausfinden muss ob valide, ist alles fein
                apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                Kommentar


                • #23
                  solange dem validator nur darum geht ob die farbe valide ist oder nicht
                  Wo hast Du das denn her - Farbe valide??? Die Rede war von komplexen Regeln – plural - es geht hier nicht um Validiereung von Farben.

                  Ein Validator ist nicht dafür da um logische Zusammenhänge einer Domain abzubilden oder diese zu prüfen und ein Controller ebenso wenig. Natürlich erscheint es erstmal schneller und einfacher alles in den Controller reinzuknallen. Aber sobald Du diese Logik auch noch an anderen Stellen brauchst hast Du bereits ein Problem.

                  vg
                  jack
                  -

                  Kommentar


                  • #24
                    Zitat von jack88 Beitrag anzeigen
                    Ein Validator ist nicht dafür da um logische Zusammenhänge einer Domain abzubilden oder diese zu prüfen und ein Controller ebenso wenig. Natürlich erscheint es erstmal schneller und einfacher alles in den Controller reinzuknallen. Aber sobald Du diese Logik auch noch an anderen Stellen brauchst hast Du bereits ein Problem.
                    ich habe mich mittlerweile so eingestellt, dass ich mich auf den aktuellen usecase konzentriere und dabei versuche, einigermasen flexibel zu sein, ich habe mir schon ziemlich oft total komplexe konstrukte aus den fingern gesaugt, weil es koennte ja sein dass ich das anderswo noch mal verwenden koennen muss und die faelle traten wirklich selten auf, wenn die aufgetreten sind, war ich sehr dankbar dass ich automatisierte tests hatte und somit relativ schnell refaktorisieren konnte, ALS ich die Logik auch irgendwo anders gebraucht habe.

                    habe halt oeffters ganz triviale dinge so kompliziert umgesetz, dass es kein mehrwert hatte und der zeitliche aufwand wesentlich groesser war
                    apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                    Kommentar


                    • #25
                      Zitat von BlackScorp Beitrag anzeigen
                      eine property $isValidatColor im datenmodel und im controller dann anhand von daten von irgendwoher die dann setzen
                      Mir sind andere Lösungsansätze durch aus bekannt. Ich bin vor längerer Zeit auch mal auf den Zug aufgesprungen in den getter/setter validieren zu wollen und damit überhaupt nicht glücklich gewessen. Daher würde mich ebend ein Lösungsansatz dafür interessieren.

                      Zitat von jack88 Beitrag anzeigen
                      Strenggenommen ist das keine Aufgabe für einen Validator, das sind Geschäftsregeln der Domain und
                      Wo fangen Geschäftsregeln an, wo hören sie auf?! Oder anderes gefragt, was validierst du den mit einem Validator? Das sind alles Geschäftsregeln...

                      Kommentar


                      • #26
                        Zitat von erc Beitrag anzeigen
                        Wie bildest du dann aber "komplexe" Regeln ab? Z.B. es kann kein gelbes Auto von VW geben, aber das Auto muss gelb sein wenn es von BMW kommt?
                        Da das alles über Validator-Chains läuft schreib ich zur Not einen Callback-Validator, der die Regeln anhand kombinierter Daten überprüfen kann.
                        VokeIT GmbH & Co. KG - VokeIT-oss @ github

                        Kommentar


                        • #27
                          Bei einem Formular komtm es z.B. darauf an, ob ein Geburtsdatum einem gewissen Alter entspricht, für das Model ist dagegen eher entscheidend, dass es ein valides Datum ist.
                          this.

                          Ich stelle hier noch eine -vielleicht Alternative- in den Raum: benutze eine spezialisierte Factory zur Erzeugung Deiner Objekte. An die kannst Du dann beliebige Datenquellen und Filter und Validatoren knüpfen. Einziges Manko: Du kannst das Userobjekt nicht davor schützen, auf "natürlichem" Weg erstellt zu werden (jedenfalls nicht ohne Handstände). Das wäre dann eine Konvention, um konsistente User zu erhalten, diese nur über eine Factory zu erzeugen.

                          Grundlegend bin ich bei einem einfachen Datentypprüfung im Setter noch dabei (siehe Zitat oben), mehr gehört für mich aber einfach nicht mehr in die jeweiligen Klassen. ABER wir dürfen hier auch nicht Model und (bspw.) User verwechseln. Ein Model kann aus vielen Objekten bestehen. Auch Validität kann verschiedene Ausprägungen haben: Anforderungen der Domäne (z.B. nur gelbe Autos), Anforderungen/Gegebenheiten der Datenstruktur (max. Feldlänge 100 Zeichen o.ä.). Letzteres bildet wiederum die Grundlage für die Eingabefelder im Formular und die Formularvalidierung.
                          [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


                          • #28
                            Das System läuft so bereits, da braucht#s derzeit keine Alternativen.
                            Models bestehen da auch durchaus aus mehreren Objekten und -Collections, ich war da mit dem Begriff "Model" und "Validator" vielleicht etwas "unvorsichtig".
                            Wir haben da Entities und ValueObjects im Einsatz, die grundsätzlich erstmal nur auf Rahmenbedingungen abprüfen, z.B. Datentyp, ggfls. Stringlänge, enthalten in einem bestimmten Set.

                            Mich auf Konventionen zu verlassen ist im Übrigen leider der denkbar schlechteste Weg, denn dann kommt am Ende wieder genau das dabei raus, wovon ich das Projekt wegentwickle: der Nächste schiebt mal da ein paar Daten rein, dann dort und am Ende wundert ersich, warum er auf Seite 100 falsche Daten zu sehen bekommt oder es einfach mal kracht.
                            Dann lieber frühzeitig mit Exceptions auf die Finger hauen, wenn mal wieder ein X für ein U verkauft werden soll.
                            VokeIT GmbH & Co. KG - VokeIT-oss @ github

                            Kommentar


                            • #29
                              Keine Ahnung von welchem "System" Du gerade redest, aber meine Antwort bezog sich jetzt nicht auf Dich.

                              erstmal nur auf Rahmenbedingungen abprüfen, z.B. Datentyp, ggfls. Stringlänge, enthalten in einem bestimmten Set.
                              Mich auf Konventionen zu verlassen ist im Übrigen leider der denkbar schlechteste Weg,
                              Wie die beiden Punkte zusammengehen, kannst Du dann mal erklären. Letztlich ist jede von aussen angestoßene Aktion, die man unterlassen kann bereits eine Konvention. Z.B. die Validierung eines Value-Objekts, statt in einem Value-Objekt. Auch die Konfiguration eines Validators kann man unterlassen. Das ist schlicht fehlerhafte Programmlogik. Wie also prüfst Du Model-Integrität jenseits der "erstmal nur auf Rahmenbedingungen"?
                              [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


                              • #30
                                Verstehe ich alles nicht.

                                Ich habe ein Objekt. Ob es "valide" ist, liegt in der Perspektive.

                                Ich hatte das in einem anderen Thread schon mal beschrieben. Nehmen wir an, es steht ein Userobjekt. Das hat ein "Alter". Zumindest jetzt für dieses Beispiel. Das "Alter" einer lebenden Person ist valide, wenn es zwischen 0 und 200 liegt.

                                Nun ist ein Johann Wolfgang von Goethe heute um die 265 Jahre alt. Der ist schon tot, das macht ihn aber nicht jünger. Blöd, wenn das jetzt invalid wäre.

                                Dann haben wir da den Sexshop. Da kommt man nur rein, wenn man 18 ist. Ein User, dessen Alter kleiner ist als 18 kommt da nicht rein.

                                Wogegen man ins Ikea Smålland nur reinkommt, wenn man nicht älter als 10 (oder so) ist.

                                Das bringt mich nach dieser Darstellung zu der Erkenntnis, dass ich jemand Außenstehenden fragen muss, ob das Userobjekt valide ist. Für mich ist ein Userobjekt damit valide, wenn im "Alter" eine Zahl steht. In einer Geschäftslogik kann ich dann spezialisiere Objekte haben, die eine genauere Validierung des Userobjekts erlauben. Das ermöglicht es mir ein relativ generisches Userobjekt in vielen Situationen einzusetzen und eine situationsspezifische Validierung vorzunehmen.

                                Ich kann sowas schon nicht mehr anders denken.

                                Kommentar

                                Lädt...
                                X