Ankündigung

Einklappen
Keine Ankündigung bisher.

Models filtern

Einklappen

Neue Werbung 2019

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

  • Models filtern

    Hi,

    eine Frage, mit der ich mich kürzlich befassen durfte, ist folgende:
    Gehen wir davon aus, dass wir ein Model haben, welches alle User beinhaltet. Ich will jetzt nur die User haben, auf die ein bestimmtes Kriterium zutrifft.

    Alles kein Problem - jedoch stellt sich mir dabei eine "designtechnische" Frage: sollte MVC folgend eigentlich das Model sich selbst filtern können, oder sollte der Controller das Model filtern?
    Prinzipiell würde ich Logik ja in den Controller werfen. Problem hierbei: was, wenn der Filter an verschiedenen Stellen verwendet wird? Sehr fiktives Beispiel, aber wenn ich jetzt 2 unterschiedliche Userlisten hätte - dann müsste ich den Filter in den Controllern entweder 2 mal basteln (würde DRY ja widersprechen) oder eine eigene Funktion dafür verfassen (was auch irgendwo hässlich klingt).
    Wüsste das Model selbst, wie es sich filtern kann, spare ich mir das. Problem dann aber ist, dass Business Logik im Model wäre - ist das als "bad practise" anzusehen?

    Schöne Grüße


  • #2
    Das Model selbst implementiert die Filtermethoden. Was du dann filtern willst, entscheidet der Controller.

    Schau mal hier, evtl. hilft dir das etwas weiter.

    Kommentar


    • #3
      Okay, dachte ich schon - klingt irgendwie auch sinniger.
      Dann direkt eine Frage, vielleicht weiß es ja wer:

      Nachdem ich momentan mit Laravel arbeite, würde ich die Filtermethoden gern implementieren.

      Es gibt ein User-Model und ein Article-Model. Ein User kann beliebig viele Articles haben (umgesetzt über hasMany innerhalb des User Models). Wie kann ich denn nun die Artikel filtern? Irgendwie finde ich nicht raus, wie ich vom User Model auf Methoden des Article Models zugreifen kann.
      Wer eine Idee?

      Kommentar


      • #4
        (Mal in die Ecke gestellt, ob dein Vorhaben sinnvoll sein soll) Indem du dem User Model eine Referenz des Article Models übergibst und dann die Methoden aufrufst. Kleine Kontrollfrage: Du hast doch die Methode public gemacht? - Dann dürfte es kein Problem sein.

        Kommentar


        • #5
          Gehen wir davon aus, dass wir ein Model haben, welches alle User beinhaltet.
          Das ist kein Model, sondern eine Collection mit Models/Domain Objekten. Eine solche Collection-Klasse findet man z.B. bei Doctrine:

          http://www.doctrine-project.org/api/...ollection.html

          Man kann diese Klasse auch unabhängig vom Doctrine-Framework verwenden.

          vg
          jack
          -

          Kommentar


          • #6
            Und was macht man, wenn ein User tausende Artikel hat? Werden die dann alle erst mal geladen, bevor sie gefiltert werden?
            Standards - Best Practices - AwesomePHP - Guideline für WebApps

            Kommentar


            • #7
              Zitat von jack88 Beitrag anzeigen
              Das ist kein Model, sondern eine Collection mit Models/Domain Objekten.
              Dazu würde mich mal interessieren, was genau ein Model ist und wo das von wem normativ festgelegt wurde.

              Kommentar


              • #8
                Zitat von mermshaus Beitrag anzeigen
                Dazu würde mich mal interessieren, was genau ein Model ist und wo das von wem normativ festgelegt wurde.
                Im Buch "Software-Engineering - Grundlagen, Menschen, Techniken" von Ludewig und Lichter.

                TL;DR: Alles ist ein Modell von etwas. Controller, View, Collection, Popo etc. Ein MVC-"Model" ist mehr so eine Art "Not yet defined"-Model...
                Standards - Best Practices - AwesomePHP - Guideline für WebApps

                Kommentar


                • #9
                  Ich bin zu der Erkenntnis gekommen das (MVC-)Models Klassen sind die Daten aus einer Datenbank holen, ob das nun ein Repository ist, ein Klasse mit Funktionen die SQL-Queries ausführen oder eine Collection aus Domain-Objects ist dabei Jacke wie Hose. Bei dem MVC-Paradigma geht es vielmehr um die Zuständigkeitstrennung als um das festlegen eines spezifischen Handlungsspielraums.

                  Model = Soll Daten Besorgen
                  View = Soll Daten darstellen
                  Controller = Soll dafür sorgen das besorgte Daten dargestellt werden
                  [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                  Kommentar


                  • #10
                    Die Modell-Schicht nur auf Daten zu beziehen wird der Bedeutung nicht gerecht. Wie ich oben schon sagte, ist im Grunde alles ein Model (Modell).

                    View verkörpert das Modell der Darstellung von Informationen.
                    Controller koordinieren Zugriffe und Zuständigkeiten und stellen damit das Modell des Routings von Informationen dar.
                    Models umfassen alle Arten von Modellen, die im MVC-Muster keiner Vorgabe unterliegen.

                    Model steht dabei nicht für Datensatzobjekt für Datenbanktabelle, sondern schlicht nur für ein Modell für "irgendwas". Weiter kann man das mEn nicht konkretisieren. Neben Datenmodellen gibt es ja beispielsweise auch noch das Modell der Ausführung. Und natürlich auch weitere. Ich kann z.B. die Berechnung von etwas als Model haben, ohne dass dieses Modell zwingend selbst einen State halten muss. Es ist häufig noch nicht mal gut, Models so zu designen, dass sie einer Datenbankstruktur entsprechen. OO ist an sich eigentlich nicht mal wirklich gut für die Entwicklung von Datenbankanwendungen.
                    Standards - Best Practices - AwesomePHP - Guideline für WebApps

                    Kommentar


                    • #11
                      Zitat von rkr Beitrag anzeigen
                      Die Modell-Schicht nur auf Daten zu beziehen wird der Bedeutung nicht gerecht. Wie ich oben schon sagte, ist im Grunde alles ein Model (Modell).
                      Jede Interaktion mit irgendetwas resultiert in Daten oder wenn es konkreter werden soll in Zustandsdaten. Im Grunde ist ein Model also nichts anderes als ein Objekt das Daten besorgt. Ich gebe dir recht, wenn du sagst das alles im Grunde ein Model sein kann. Mit unter auch ein Controller, denn der besorgt eigentlich auch nur "Daten" die der Request anfordert um ein Response zu liefern. Für mich ist die Bedeutung ( egal wie weit man in der Betrachtungsweise "herauszoomed" ) also durchaus ausreichend ( gerecht ) erklärt.

                      DCI spezifiziert das ganze besser. Aber nunja, DCI mit MVC zu vergleichen halte ich für etwas zu weit aus dem Fenster gelehnt, aus dem Grund versuche ich das erst nicht.
                      [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                      Kommentar


                      • #12
                        @mermhaus

                        Dazu würde mich mal interessieren, was genau ein Model ist und wo das von wem normativ festgelegt wurde.
                        Hast recht, daß es kein Model ist kann man an der Stelle nicht sagen – ist nicht richtig.

                        @troy
                        Ich bin zu der Erkenntnis gekommen das (MVC-)Models Klassen sind die Daten aus einer Datenbank holen,
                        Model = Soll Daten Besorgen
                        Nein, Models besorgen keine Daten, das machen DAOs.

                        Das Problem ist, daß der Begriff Model oft falsch verwendet wird. Unter einem Model versteht man strenggenommen das Domain Model. Es ist ein konzeptionelles Gebilde aus Daten + Logik die erforderlich sind um ein Problem/Aufgabe zu lösen.

                        Objekte wie User oder Artikel werden oft auch als Models bezeichnet, aber es sind in Wirklichkeit nur Geschäftsobjekte/Business Objects eines Domain Models.

                        vg
                        jack
                        -

                        Kommentar


                        • #13
                          Du hast auch sicher Verweise auf Informationen von Reenskaug, Gamma, Helm, Johnson, Vlissides oder meinetwegen auch heute publizierter Autoren die deine Aussagen untermauern ? Wikipedia, als beispiel, stellt einen Übersetzungsbezug des "Model" zu "Datenmodell" her, um mal nur ein Beispiel zu geben.

                          Setzt man dann die Lesefrequenzen von Wikipedia als Gewicht dagegen und dem Fakt das die Erklärung des Models seit mehreren Jahren nicht modifiziert wurde, komme zumindest ich zu dem Entschluss, dass das wohl gültig ist.

                          Etwas entfernter von dem deutschen Artikel ist, das der englische Artikel nicht so spezifisch auf das Model eingeht und nur deren Interaktions-Position erklärt und somit sehr viel Spielraum für Interpretations lässt.

                          Ich lege mich aber nicht auf die Spezifische Erklärung von Wikipedia fest. Eilebrecht und Starke erklären das Model als Datenverwalter und Datenbeschaffer in ihrer Ausgabe von 2013, bestätigen also das "Datenmodell" als Model.
                          [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                          Kommentar


                          • #14
                            Wikipedia, als beispiel, stellt einen Übersetzungsbezug des "Model" zu "Datenmodell"
                            Gibt es zu dieser Behauptung evtl. auch einen Link?

                            vg
                            jack
                            -

                            Kommentar


                            • #15
                              Zitat von tr0y Beitrag anzeigen
                              Jede Interaktion mit irgendetwas resultiert in Daten oder wenn es konkreter werden soll in Zustandsdaten. Im Grunde ist ein Model also nichts anderes als ein Objekt das Daten besorgt.
                              Ein Model hat nicht zwingend etwas mit dem Auslesen, Halten und Speichern von Daten zu tun. Daten können auch "nur" verarbeitet werden. Alles was mit EDV gemacht wird, hat mit Daten zu tun. Jedoch sind Models keine reinen Datenbankgateways die nur dazu dienen, Daten aus einer externen Datenquelle zu ziehen, zu verarbeiten und wieder zu speichern.

                              Wann immer du ein konkretes Vorgehen, eine fremdbestimmte Datenstruktur oder einen fertig implementierten Vermittler hast, liegt hier ein abstraktes Modell der jeweiligen Idee zugrunde. Und das ist idR auch das, was man mit dem Namen einer Klasse beschreibt.

                              Zitat von tr0y Beitrag anzeigen
                              Ich gebe dir recht, wenn du sagst das alles im Grunde ein Model sein kann.
                              Was ist in der Softwareentwicklung denn kein "Modell"?
                              Standards - Best Practices - AwesomePHP - Guideline für WebApps

                              Kommentar

                              Lädt...
                              X