Ankündigung

Einklappen
Keine Ankündigung bisher.

php mvc's zusammenfassen

Einklappen

Neue Werbung 2019

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

  • php mvc's zusammenfassen

    Ich hab ne blöde frage: Und zwar hab ich viele verschiedene mvc's: Hört sich vllt ein bisschen unverständlich an, aber es ein mvc-Konstrukt für Login, ein MVC-Konstrukt für Registration, ... Wie kann ich es nun am besten machen, dass ich die einzelnen Dinger anspreche, und dabei die Vorteile von OOP geschickt ausnutze? Hat jemand Vorschläge, gerne auch Codebeispiele. Ich denk mir ein FrontController, der jede View, Model, Controller einzeln je nach Action instanziiert, ist zu heavy, oder wie sehen das die andren?

  • #2
    Baue doch einen Router: http://symfony.com/doc/current/book/routing.html

    Sieh dir mal die Lösungen von gängigen Frameworks an, da lernt man viel.

    Falls du dich für HMVC interessierst und kein Fan vom statischen Routing bist, wäre das APF (http://adventure-php-framework.org/) sehenswert, da es auf eine recht generische Implementierung setzt, aber frag hierzu am besten mal den doc

    LG
    https://github.com/Ma27
    Javascript Logic is funny:
    [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

    Kommentar


    • #3
      ich vergas zu sagen, dass es in reinem php stattfinden sollte, aber ich weiss deine mühe sehr zu schätzen. Wenn wir uns kennen würden, würde ich dir einen ausgeben

      Kommentar


      • #4
        ich vergas zu sagen, dass es in reinem php stattfinden sollte
        ähm ich verstehe grad nicht so ganz, was du meinst

        LG
        https://github.com/Ma27
        Javascript Logic is funny:
        [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

        Kommentar


        • #5
          sorry, überlesen. Mein fehler ^^

          Kommentar


          • #6
            Was mir gerade noch einfällt: http://www.php.de/software-design/10...die-tonne.html

            Da sieht man ja auch teilweise, dass MVC nicht die allerschönste Lösung ist, da es sich nicht richtig für Webanwendungen eignet: http://phpmagazin.de/artikel/Was-nic...-Teil-2-171917

            LG
            https://github.com/Ma27
            Javascript Logic is funny:
            [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

            Kommentar


            • #7
              Nunja, MVC wurde vielleicht etwas "aktualisiert" für den aktuellen Kontext, das Grundprinzip bleibt ja das gleiche: Teilung von View, Daten und Kontrollfluss.
              [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

              Kommentar


              • #8
                @ChristianK,

                hast du den Artikel aus dem PHPMagazin gelesen?

                LG
                https://github.com/Ma27
                Javascript Logic is funny:
                [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

                Kommentar


                • #9
                  php mvc's zusammenfassen

                  Ja, habe ich . Nur muss c h deswegen ja nicht gleicher Meinung sein.
                  [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

                  Kommentar


                  • #10
                    Nur muss c h deswegen ja nicht gleicher Meinung sein
                    Keine Frage - das ist klar. Darf ich denn dann nach deinen konkreten Gegenargumenten fragen

                    LG
                    https://github.com/Ma27
                    Javascript Logic is funny:
                    [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

                    Kommentar


                    • #11
                      Wie ich bereits schrieb, das Prinzip von der Trennung von Datenmodell, Präsentation und Programmsteuerung halte ich nach wie vor für aktuell. Das sich das Prinzip anders verhält wie vor 30 Jahren ist logisch. Die Ausdehnung ist klar anders und die Grenzen und Detaildefinitionen des Musters sind anders.
                      [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

                      Kommentar


                      • #12
                        Wie ich bereits schrieb, das Prinzip von der Trennung von Datenmodell, Präsentation und Programmsteuerung
                        Da hast du auf jedenfall Recht aber geht das nicht in die Richtung "drei Schichten Architektur"?

                        MVC ist doch nur ein Pattern für die Präsentationsschicht.

                        LG
                        https://github.com/Ma27
                        Javascript Logic is funny:
                        [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

                        Kommentar


                        • #13
                          Zitat von Phpyton Beitrag anzeigen
                          Ich hab ne blöde frage: Und zwar hab ich viele verschiedene mvc's: Hört sich vllt ein bisschen unverständlich an, aber es ein mvc-Konstrukt für Login, ein MVC-Konstrukt für Registration, ... Wie kann ich es nun am besten machen, dass ich die einzelnen Dinger anspreche, und dabei die Vorteile von OOP geschickt ausnutze? Hat jemand Vorschläge, gerne auch Codebeispiele. Ich denk mir ein FrontController, der jede View, Model, Controller einzeln je nach Action instanziiert, ist zu heavy, oder wie sehen das die andren?
                          Was ist die Problematik dabei? Du führst ja nicht alle Actions auf einmal aus, d.h. es werden auch nicht alle Objekte dabei instantiiert. Oder ich verstehe dich falsch. Aber anstatt Code-Beispiele von uns sehen zu wollen, wäre es eher hilfreich mal deinen Code zu sehen damit wir wissen was du überhaupt vor hast.

                          @Ma27: Sehe ich anders. Die Schichten kann es ja innerhalb des MVC (nach PHP-Verständnis) auch noch geben. Typischerweise innerhalb des Models.

                          Der Schlussabsatz des Artikels fasst das "Problem" aber gut zusammen:
                          Auf der Serverseite gibt es an sich keinen Grund dafür, überhaupt noch von MVC zu sprechen. Wir haben gesehen, dass die Komponenten eines Web-MVC mit dem ursprünglichen MVC-Entwurfsmuster nur noch die Bezeichnungen gemeinsam haben. Die einzelnen Bestandteile haben völlig andere Verantwortlichkeiten, und MVC allein gibt keine Antwort auf viele der Fragen, die sich bei der Entwicklung von Webanwendungen stellen.
                          Der Vorschlag ist also offensichtlich nur das man es anders benennt. Dagegen wäre grundsätzlich nichts einzuwenden, nur das jeder diese im Artikel angesprochene "Anpassung" des MVC anders durchführt. Und die Bezeichnung MVC ist eben der gemeinsame Nenner davon. Meinetwegen nennen wir's dann halt wie in der JS-Welt MV* oder ähnlich. Vielleicht ***.

                          Kommentar


                          • #14
                            @Ma27: Sehe ich anders. Die Schichten kann es ja innerhalb des MVC (nach PHP-Verständnis) auch noch geben. Typischerweise innerhalb des Models.
                            Also nach dem, was ich gehört habe ist es ein Pattern für die Präsentationsschicht und nicht die Dreischichtenarchitektur.

                            Sie sollten auf keinen Fall MVC mit der Schichtenarchitektur verwechseln. Das Modell ist nämlich nicht für die Umsetzung der Schicht der Anwendungslogik zuständig. Natürlich können beide Aufgaben (Bereitstellung der Anwendungslogik und Darstellbarkeit in der Präsentationsschicht) in der Praxis von denselben Objekten übernommen werden. So können Sie natürlich eine Enterprise Java Bean als Modell verwenden, um diese direkt über die Präsentationsschicht darzustellen. Die Modell-Eigenschaft ist dabei aber nach wie vor völlig unabhängig von den anderen Eigenschaften der EJB, wie z. B. die Fähigkeit, Daten persistent zu machen.
                            [Quelle: http://openbook.galileocomputing.de/...tektur_001.htm ]

                            LG
                            https://github.com/Ma27
                            Javascript Logic is funny:
                            [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

                            Kommentar

                            Lädt...
                            X