Ankündigung

Einklappen
Keine Ankündigung bisher.

Großprojekt - Brain-Storming zur Architektur

Einklappen

Neue Werbung 2019

Einklappen
Dieses Thema ist geschlossen.
X
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Großprojekt - Brain-Storming zur Architektur

    Hallo Leute,

    ich stehe mit einem kleinen Team aus 3 Entwicklern zurzeit vor einem größeren Projekt. Das ganze wird ein größeres Portal, dass insgesamt 6 verschiedene Bereiche beherbergen wird. Näher ins Detail kann ich nicht genau eingehen, ich hoffe ich schaffe es aber im weiteren Verlauf rüber zu bringen wo mein Problem ist.

    Und zwar habe ich früher sehr viel in PHP entwickelt, auch größere Anwendungen zu einer Zeit wo es noch nicht so überladene Frameworks gab. Da hat man sich ein paar Klassen geschrieben und irgendwie drauf los programmiert und am Ende kam was anständiges dabei raus. Allerdings war da der Wartungsaufwand doch meistens etwas höher als geplant^^

    Nun habe ich die letzten Jahre nur noch Desktopentwicklung gemacht und bin sozusagen etwas raus aus der Web-Entwicklung mit PHP. Die Sprache selbst beherrsche ich noch, mir fällt zurzeit aber das umdenken etwas schwer wie das im Web so abläuft (Request, Response etc.)...

    Nun sind wir auf der Suche nach einem passenden Konzept, wie man eine recht große Seite aufbauen könnte. Ich habe mir nun zahlreiche Frameworks angesehen, kann mich aber mit dem zurzeit beliebten MVC Framework nicht so richtig anfreunden. Für meinen Geschmack bietet das Konzept mir zu wenig Freiraum im Anzeigen von dynamischen Inhalten. HMVC wäre eine Alternative, aber irgendwie ist mir das einfach zu kompliziert aufgebaut. Da muss ich ständig mit Kanonen auf Spatzen schießen um ne Liste der Benutzer anzuzeigen (View anlegen, Controller anlegen etc. pp.)...

    Mich würde nun mal interessieren, wie ihr eure Großprojekte so aufbaut. Setzt ihr immer auf Frameworks? Ich möchte keine Grundsatzdiskussion über MVC oder Frameworks hier auslösen, mir ist bewusst das ein Framework zahlreiche Vorteile hat, genau wie MVC Vor- und Nachteile hat. Mich würde im allgemeinen einfach interessieren, was ich noch für Möglichkeiten habe das ganze aufzubauen. Früher hätte ich einfach drauf los gelegt, aber irgendwie bin ich zurzeit durch die Desktopentwicklung so vorbelastet und gedanklich eingefahren, dass ich keinen Einstieg finde, der mir beim programmieren Spaß bereitet....

    Danke schonmal für Tipps, Anregungen und Hilfen

    Beste Grüße
    ViperNeo

  • #2
    Ja, immer Framework und ja, immer (H)MVC. Eine Alternative wäre noch MVVM, aber das ist bei PHP doch eher unüblich und recht komplex.

    Kommentar


    • #3
      und am Ende kam was anständiges dabei raus. Allerdings war da der Wartungsaufwand doch meistens etwas höher als geplant
      Ist doch ein Widerspruch in sich..

      Setzt ihr immer auf Frameworks?
      Ich habe seit ewigen Zeiten kein Projekt mehr gehabt, das nicht auf einem Framework aufgesetzt hätte. Es ist genau die selbe Sache wie bei den anderen Diskussionen: Du musst von einem Framework nicht alles benutzen, aber es hat durchaus Vorteile, wenn Du ein - für den Anfang - überdimensioniertes Framework benutzt, dass allerdings schon alle Bestandteile beinhaltet, die Du mal brauchst.

      Da muss ich ständig mit Kanonen auf Spatzen schießen um ne Liste der Benutzer anzuzeigen (View anlegen, Controller anlegen etc. pp.)...
      und am Ende kam was anständiges dabei raus. Allerdings war da der Wartungsaufwand doch meistens etwas höher als geplant^^
      Überleg mal, warum

      Wenn es nicht gerade eine statische Website ist, für die man ein CMS benutzen kann oder eine wirklich kleine Applikation ohne Ambitionen, zu wachsen, dann natürlich kein Framework - sonst schon. Wie bereits gesagt: Ein Projekt unterliegt immer der "Gefahr", zu wachsen und wenn man dann von vorherein auf ein Framework setzt, hat man wesentlich bessere Karten.

      Kommentar


      • #4
        Die Sprache selbst beherrsche ich noch, mir fällt zurzeit aber das umdenken etwas schwer wie das im Web so abläuft (Request, Response etc.)
        Mit folgende Dingen solltest du anfangen:

        http://de.wikipedia.org/wiki/Client-Server-Modell
        http://de.wikipedia.org/wiki/Http


        MVC Framework
        Weder (H)MVC ist ein Framework noch ist es auf Serveranwendungen beschränkt und auf gar keinen Fall ist das eine Modeerscheinung:

        http://de.wikipedia.org/wiki/Model_View_Controller
        http://framework.zend.com/manual/de/...ontroller.html

        Kommentar


        • #5
          (H)MVC ist kein in Beton gegossenes Architekturmodell, sondern eine Organisationsstruktur. Zu MVC kommen ja noch Service-Layer, Bibliotheken usw. hinzu.

          Ich sehe gar nicht wie man ohne Framework und MVC (und ähnliche Konzepten) eine große Webseite erfolgreich weiterentwickeln will, es sei denn aus konzeptionellen Gründen eine Eigenimplementierung von GRUNDLEGENDEN Dingen nützlicher ist.

          Die Code-Qualität kann auch in einem solchen Projekt leiden. Es gibt Organisatorische (Agile Softwareentwicklung, QA, Dokumentation usw), technische (PHPUnit, Agile Dokumentation, Selenium) und disziplinarische Methoden (Test-driven Devlopment, PHPCs, Code-Reports) um dem entgegen zu wirken. Letztlich obliegt es dem Team-Leiter das zu organisieren.

          Aus dem Desktop-Bereich müsstest du solche Methoden gewöhnt sein, die gibt's auch im PHP-Umfeld.

          > Da muss ich ständig mit Kanonen auf Spatzen schießen um ne Liste der Benutzer anzuzeigen (View anlegen, Controller anlegen etc. pp.)...
          User wäre ein Model, was du sowieso brauchst. Mit Zend_Db müsste man dieses erst einmal erzeugen (leider bisher manuell) in Doctrine würde man das Model aus einer Yaml/XML/PHP-Datei erzeugen. Danach wäre es ein simple Action, welche einfach mit Zend_Paginator die Liste in Seiten aufteilt. Könnte man in 5 Minuten erledigt haben.

          Kommentar


          • #6
            Sofern ich programmiere, programmiere ich NUR noch mit Hilfe eines Frameworks!

            http://adventure-php-framework.org/

            Schau es dir mal an.

            Kommentar


            • #7
              So, ich stimme euch größtenteils zu, ihr wisst schon, dass zum Beispiel Facebook ohne MVC auskommt?

              Was spricht zum Beispiel dagegen ein Objektorientiertes Kernmodell zu schreiben, auf das ich Prozedural zugreife und mithilfe von zum Beispiel Smarty darstelle? Dann hätte ich halt für jede Seite eine eigene Datei, die prozedural den Content aufbaut und am Schluss mit Smarty raus haut. Um Code duplizierung hier zu vermeiden, kann man ja das meiste in andere Files kapseln, die bei bedarf includet werden. Sollte doch grundsätzlich machbar sein und auch übersichtlich.

              Ich verstehe einfach nicht ganz, wie man in MVC ein sinnvolles View Management umsetzt. Ich will nicht kompliziert 10 Controller aufrufen müssen über neue Request, um verschiedene Boxen auf meiner Seite mit Leben zu füllen. Schreibe ihc alles in eine Controller Methode hab ich wieder Code-Duplizierung ohne Ende. Ich finde MVC hat schon riesen Vorteile, jedoch sehe ich gerade in der Ausgabe von komplexen GUIs große Schwächen was die Views anbelangt. Das ganze dann mit Subcontrollern aufzublasen halte ich wieder für zu komplex und mit Kanonen auf Spatzen geschossen.

              Beispiel:

              Controller Authentication Methode Login.

              Eigentlich sollte diese Methode sich meiner Meinung nach nur um Sachen Login kümmern... Ich möchte aber auf meiner Seite noch einen News-Feed anzeigen, möchte die zuletzt aktivsten Benutzer anzeigen, möchte Informationen aus Katalogen anzeigen, eventuell Werbung einblenden. Wie würdet ihr das denn anstellen? Für jedes Einzelteil einen neuen Request an einen anderen Controller? Alles in der Login Methode abrufen und ins View blasen? Das ist glaueb ich zurzeit mein größtes gedankliches Problem....

              Kommentar


              • #8
                Zitat von ViperNeo Beitrag anzeigen
                ihr wisst schon, dass zum Beispiel Facebook ohne MVC auskommt?
                Und woher weißt du das? Ohne Quelle halte ich das erstmal für Bullshit.

                Zitat von ViperNeo Beitrag anzeigen
                Was spricht zum Beispiel dagegen ein Objektorientiertes Kernmodell zu schreiben, auf das ich Prozedural zugreife und mithilfe von zum Beispiel Smarty darstelle? Dann hätte ich halt für jede Seite eine eigene Datei, die prozedural den Content aufbaut und am Schluss mit Smarty raus haut. Um Code duplizierung hier zu vermeiden, kann man ja das meiste in andere Files kapseln, die bei bedarf includet werden. Sollte doch grundsätzlich machbar sein und auch übersichtlich.
                Wenn du das richtig machst, nutzt du eigentlich auch MVC, wie schon gesagt wurde ist das ein Konzept auf hoher Abstraktionsebene welches in erster Linie Separation of Concerns auf GUI Ebene sicherstellen soll.

                Smarty: View
                Prezedurale Datei: Controller
                OO Modell: Model

                Zitat von ViperNeo Beitrag anzeigen
                Eigentlich sollte diese Methode sich meiner Meinung nach nur um Sachen Login kümmern... Ich möchte aber auf meiner Seite noch einen News-Feed anzeigen, möchte die zuletzt aktivsten Benutzer anzeigen, möchte Informationen aus Katalogen anzeigen, eventuell Werbung einblenden. Wie würdet ihr das denn anstellen? Für jedes Einzelteil einen neuen Request an einen anderen Controller? Alles in der Login Methode abrufen und ins View blasen? Das ist glaueb ich zurzeit mein größtes gedankliches Problem....
                Ich würde es wahrscheinlich mit View Centric HMVC angehen. Im obersten View wird bestimmt, welche Unter-Komponenten eingefügt werdne und ja, diese haben alle ihre eigenen Controller. Ich sehe aber auch nicht das Problem darin. Was du als "Neuer Request" bezeichnest ist doch nichts als ein Methodenaufruf. Das muss nicht kompliziert sein.
                [IMG]https://g.twimg.com/twitter-bird-16x16.png[/IMG][URL="https://twitter.com/fschmengler"]@fschmengler[/URL] - [IMG]https://i.stack.imgur.com/qh235.png[/IMG][URL="https://stackoverflow.com/users/664108/fschmengler"]@fschmengler[/URL] - [IMG]http://i.imgur.com/ZEqflLv.png[/IMG] [URL="https://github.com/schmengler/"]@schmengler[/URL]
                [URL="http://www.schmengler-se.de/"]PHP Blog[/URL] - [URL="http://www.schmengler-se.de/magento-entwicklung/"]Magento Entwicklung[/URL] - [URL="http://www.css3d.net/"]CSS Ribbon Generator[/URL]

                Kommentar


                • #9
                  Bei Facebook lagen kurzzeitig mal Quellen offen, wer da mal reingeschaut hat weiß mehr

                  Ansonsten schaue ich wohl einfach mal wie ich herangehe... Danke soweit

                  Kommentar


                  • #10
                    Ich will nicht kompliziert 10 Controller aufrufen müssen über neue Request, um verschiedene Boxen auf meiner Seite mit Leben zu füllen. Schreibe ihc alles in eine Controller Methode hab ich wieder Code-Duplizierung ohne Ende.
                    Wie würdet ihr das denn anstellen? Für jedes Einzelteil einen neuen Request an einen anderen Controller?
                    Ich habe mein Projekt mittlerweile auf Google-Code gehostet (Eigentlich nutze ich es bisher nur als Code-Repository). Damit habe ich versucht, die Aufrufe möglichst schlank zu halten. Allerdings fehlt da noch einiges an Dokumentation, wass jetzt langsam kommen soll. Aber vielleicht bietet es Dir etwas Inspiration für Dein Vorhaben: http://code.google.com/p/zn-php-framework/ Bei Fragen kannst Du Dich gerne an mich wenden.
                    Einen "Sub-Controller" (Nennt sich bei mir Node) lässt sich so einbinden:
                    PHP-Code:
                    echo $this->getNodeManager()->assembleNode('...')->run() 
                    Dabei werden keine weiteren Pseudo-Requests ausgeführt und behält man trotzdem volle Flexibilität.. Du kannst es Dir ja mal anschauen..

                    Nachtrag: Das APF, das Jens P. angesprochen hat, bietet einen ähnlichen Mechanismus an, allerdings auf der Basis von Taglibs.

                    Der Vorteil von Bootstrapping gegenüber Deiner Lösung ist, dass man _einen_ Einsprung in die Applikation hat und auch nur eine Stelle, wo wahrscheinlich alle Initialisierungen gemacht werden, ohne dass das in irgendwelchen Includes gemacht wird, wo man darauf achten muss, dass das nach einer Änderung auch noch in den ganzen Einsprungdateien hinhaut.
                    Weiterer Vorteil gegenüber Deiner prozeduralen Variante: Man hat wenig globale Variablen rum fliegen, was unbeabsichtigte Nebeneffekte reduziert.


                    EDIT: Und ja - momentan läuft die Test-Applikation meines Frameworks nicht. Ist leider der Hektik und einem Fehler beim letzten Commit geschuldet. Aber es soll auch nur Anschauungszwecken dienen

                    Kommentar


                    • #11
                      Eigentlich soll man das Aufrufen von mehreren Actions (forwarding) vermeiden. Wie man die Views einbinden kommt auf den Sachverhalt an. Entweder ein View-Helper, ein Service der etwas entsprechend rendert oder am einfachsten einfach ein Partial der eingebunden wird.

                      Smarty! Gott bitte nimm was anständiges wie HAML oder Twig!

                      Prozeduraler Code lässt sich zudem schwieriger Testen, da PHPUnit sowas z.B. nicht mocken kann. Wenn dann komplett OOP.

                      Ich sehe da mit gängigen Frameworks kein Problem. Adventure würde ich nicht einsetzen, da dem Framework die Unit-Tests fehlen, so fällt es schwer die Code-Qualität einzuschätzen (auch zukünftig).

                      Ich würde bei großen Projekten bei Symfony, Zend Framework und Doctrine bleiben, weil es hier auch einfacher fällt Fachkräfte anzuwerben und diese schnell einsteigen können.

                      Kommentar


                      • #12
                        Eigentlich soll man das Aufrufen von mehreren Actions (forwarding) vermeiden.
                        Warum? Forwarding ist was anderes, als das, was mit HMVC gemeint ist.

                        Kommentar


                        • #13
                          Weil's den Code unübersichtlich macht, langsam ist* und i.d.R. davon zeugt dass die Controller fett sind (oberstes Gebot: Thin Controllers, fat Models).

                          *im Zend Framework weil ein _forward() einen komplett neuen Dispatching-Prozess startet (was an sich eine gute Sache ist).

                          Kommentar


                          • #14
                            Weil's den Code unübersichtlich macht
                            Eigentlich nicht... Wo vermutest Du da Unübersichtlichkeit?
                            langsam ist*
                            Ok, das kommt auf die Implementierung an und ist bei einigen Frameworks tatsächlich unglücklich gelöst.
                            davon zeugt dass die Controller fett sind
                            Was hat das eine mit dem anderen zu tun? Forwarding gehört eindeutig zur Ablaufsteuerung und hat nichts mit fett oder nicht fett zu tun.
                            oberstes Gebot: Thin Controllers, fat Models
                            Was immer noch Ansichtssache ist

                            Das mit der Performance ist tatsächlich _oft_ ein Grund, aber der Rest der Argumentation ist in meinen Augen ziemlich konstruiert.

                            Kommentar


                            • #15
                              Bei einem einfachen Forward mit wenig Code der da ausgeführt wird mag das noch übersichtlich bleiben. Aber spätestens wenn du hin- und herspringst, wird's hässlich.

                              Unglücklich würde ich nicht sagen. Wenn wir von Zend Framework ausgehen wird der Forward wie ein Request behandelt und Routen etc. wirken. Das macht den Forward sehr einfach und sicher.

                              Doch es ist ein Indiz für Fat Controllers. Lieber solchen Code in einen Helper oder in einem Service Layer auslagern. Lässt sich dann auch einfacher testen.

                              Was immer noch Ansichtssache ist
                              Naja es zeigt sich schnell, dass solcher Code schwer zu testen und zu warten ist. Besser ist eben, wenn der Controller nur Daten weiterleitet und diese an anderer Stelle verarbeitet werden.

                              Das ganze aber natürlich erst ab einem gewissen Grad an Komplexität. Um einfach ein Model aufzurufen und Abfragen zu machen und dieses ans View weiterleiten kann man auch direkt im Controller machen. Wenn's auch ein paar Zeilen mehr werden ist das auch nicht schlimm. Ausgelagert gehört es auf jeden Fall wenn's mehrfach genutzt werden soll (als wo man normalerweise forwarden würde). Validierung, Formulare und Datenbankabfragen gehören meiner Meinung nach überhaupt nicht in einen Controller.

                              Wenn man vernünftig arbeitet braucht man Forwarding dann überhaupt nicht.

                              Kommentar

                              Lädt...
                              X