Ankündigung

Einklappen
Keine Ankündigung bisher.

Kritik und Ratschläge gesucht für MVC Projekt

Einklappen

Neue Werbung 2019

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

  • Kritik und Ratschläge gesucht für MVC Projekt

    Hi Leute,

    ich habe heute ein neues Projekt gestartet. Es beinhaltet zur Zeit wenig Logik und wird natürlich noch komplexer und ausführlicher. Aber dennoch würde ich mich schon auf ein wenig Kritik der Spezialisten unter Euch freuen ob ich mich in die richtige Richtung bewege.

    Was noch hinzu kommen wird:
    -Dependency Injection, da würde ich mich über Tipps oder Beispiele in Bezug auf Best Practices von Euch freuen!
    -Möglichkeit der Definition von Routen und deren auswertung.
    -Datenbank Anbindung mit einer Querybuilder Klasse.
    -Modelsystem, ORM Sinnvoll oder nicht?
    -Templatesystem mit Cachingfunktion
    -Grid- und Formhelper
    -JS und CSS (möglicherweise auch Unterstützung von SASS, LESS) minifier.

    Github:
    https://github.com/kingjojo23/MVCBegin


  • #2
    Gibt's doch alles schon?

    Kommentar


    • #3
      Sag blos...
      Das es solche Systeme bereits gibt sollte jedem klar sein, dennoch würde ich gerne Tipps und Ratschläge bekommen und nicht solch Kommentare, denn diese bringen mich in Hinsicht auf die Projektarbeit in keinster Weise weiter.

      Kommentar


      • #4
        Na ja, du willst Kritik und Ratschläge zu einem halbgaren Projekt, dessen wichtigste Komponenten noch fehlen. Aber gut, ok:

        - Halte dich an Standards (http://www.php-fig.org/)
        - Nutze bspw. Composer (https://getcomposer.org/)
        - Mir ist schleierhaft, wie ich das Framework sinnvoll in meine Projekte integrieren soll
        - Die Datei web/index.php halte ich aktuell für nutzlos.
        - PHP-Includes niemals ohne __DIR__
        - Wieso definiert Application.php Konstanten?
        - Wieso wird dem Application-Objekt nicht direkt ein InterfaceConfig-Objekt übergeben?
        - Es ist üblich Interfaces umgekehrt zu benennen: ConfigInterface
        - ConfigInterface kannst du eigt. auch streichen und direkt ein Array reinwerfen
        - Das Design deiner Routing-Komponente ist ziemlich rudimentär
        - Die Abhängigkeiten zum Application-Objekt halte ich für suboptimal
        - Wozu der CoreController gut sein soll, erschließt sich mir nicht. Halte die Klassenhierarchie so flach als möglich.
        - Komponentisierung ist aktuell in.

        Viele Grüße,
        lotti

        Kommentar


        • #5
          Zitat von lottikarotti Beitrag anzeigen
          Na ja, du willst Kritik und Ratschläge zu einem halbgaren Projekt, dessen wichtigste Komponenten noch fehlen. Aber gut, ok:

          - Halte dich an Standards (http://www.php-fig.org/)
          Danke für den Link, werde ich mir auf alle Fälle ansehen.

          - Nutze bspw. Composer (https://getcomposer.org/)
          Werde ich wenn nötig.

          - Wieso wird dem Application-Objekt nicht direkt ein InterfaceConfig-Objekt übergeben?
          - Es ist üblich Interfaces umgekehrt zu benennen: ConfigInterface
          - ConfigInterface kannst du eigt. auch streichen und direkt ein Array reinwerfen
          Ich hätte das jetzt so gelöst:
          PHP-Code:
          $app = new Application();

          $xmlConfig = new XmlConfig("app.config.xml");
          $app->setConfiguration($xmlConfig->toArray()); 
          - Das Design deiner Routing-Komponente ist ziemlich rudimentär
          Ist noch eine Baustelle.

          - Die Abhängigkeiten zum Application-Objekt halte ich für suboptimal
          Was genau meinst Du damit?
          Die Übergebung der $app per Konstruktor? Wenn ja, wie könnte ich das anders gestalten? Die Applikation als Singleton oder Global zu registrieren ist glaube ich nicht wirklich toll.

          - Wozu der CoreController gut sein soll, erschließt sich mir nicht. Halte die Klassenhierarchie so flach als möglich.
          Bis jetzt nur für den Konstruktor, danke für den Tipp.

          Das nenne ich einen guten Beitrag lotti, ich nehme deine Tipps dankend an. Ich habe natürlich nicht jetzt jeden Punkt zitiert aber natürlich werde ich mir auch diese zu Herzen nehmen.

          Kommentar


          • #6
            Zitat von kingjojo23 Beitrag anzeigen
            Werde ich wenn nötig.
            Das ist bereits dann nötig, wenn du dein Framework anderen Nutzern zur Verfügung stellen willst. Composer macht die Installation dessen zum Kinderspiel und ist heute ein Quasi-Standard.

            Zitat von kingjojo23 Beitrag anzeigen
            Ich hätte das jetzt so gelöst:
            PHP-Code:
            $app = new Application();

            $xmlConfig = new XmlConfig("app.config.xml");
            $app->setConfiguration($xmlConfig->toArray()); 
            Irgendwie besser..

            Zitat von kingjojo23 Beitrag anzeigen
            Was genau meinst Du damit?
            Die Übergebung der $app per Konstruktor? Wenn ja, wie könnte ich das anders gestalten? Die Applikation als Singleton oder Global zu registrieren ist glaube ich nicht wirklich toll.
            Ich finde es generell unschön, dass das Application-Objekt überall sein Nase reinsteckt und somit unnötige Abhängigkeiten entstehen. Deine Dispatcher-Klasse benötigt doch nur ein Subset der Anwendungskonfiguration, also regel das doch direkt im Konstruktor oder über entsprechende Setter. Das Application-Objekt interessiert deinen Dispatcher doch nicht die Bohne.

            Ach ja: deine Namespaces solltest du mit einem Vendor-Name ausstatten: <Vendor Name>\Core\..

            Viele Grüße,
            lotti

            Kommentar


            • #7
              denn diese bringen mich in Hinsicht auf die Projektarbeit in keinster Weise weiter.
              Deine ablehnende Haltung gegenüber existierenden Lösungen auch nicht.

              Dieses Framework ist bereits jetzt unflexibel und steckt jetzt schon halb in einer Sackgasse.

              * Nur xml-Configs möglich
              * Festgelegtes Controller-Verzeichnis
              * Nur /-separierte Routen möglich
              * ...

              Hättest Du Dir vorher mal andere Frameworks angeschaut, dann wären Dir solche Dinge aufgefallen. Dieses Framework hier orientiert sich ausschließlich an Deinen Bedürfnissen und so speziell wie das alles ist, hättest Du es Dir auch sparen können.

              Es gibt z. B. den psr-Standard für's Autoloading. Es gibt Composer. Was ist der Vorteil Deines Frameworks gegenüber z. B. Silex?

              Kommentar


              • #8
                * Nur /-separierte Routen möglich
                ?
                Ich dachte diese Clean-URLs sind doch sauberste, was geht?

                -Modelsystem, ORM Sinnvoll oder nicht?
                Wenn ja nicht via Annotationen...

                -Templatesystem mit Cachingfunktion
                Twig ist imo die beste und flexibleste Template Engine. Ich würde versuchen, im Allgemeinen Third-Party Libs einbinden zu können und Twig als Engine nutzen (die natürlich austauschbar ist)

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

                Kommentar


                • #9
                  Ich dachte diese Clean-URLs sind doch sauberste, was geht?
                  Nein, wieso? Das hängt ganz von den Anforderungen ab.

                  Twig ist imo die beste und flexibleste Template Engine.
                  Superlative sind immer mit Vorsicht zu gebrauchen. Und in der Softwareentwicklung am besten gar nicht.

                  Wenn ja nicht via Annotationen...
                  Warum denn nicht? Annotationen sind doch sehr praktisch?

                  Kommentar


                  • #10
                    Twig ist tatsächlich sehr gut, aber auch sehr komplex. Von mit aus gibt es nur Empfehlungen für Twig.

                    Annotationen sind nicht "standardisiert" in PHP. Es gibt keine Definition, wie eine Annotation auszusehen hat oder welchen Scope/Definitionsbereich sie hat. Es ist mehr "Goodwill"...
                    GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

                    Kommentar


                    • #11
                      Twig ist tatsächlich sehr gut, aber auch sehr komplex.
                      Finde ich jetzt eigentlich nicht. Zumal beim Templating ja alles kann, nichts muss ist. Aber was die Engine kann, kann einem später mal sehr nützlich sein, wenn die Projekte wachsen. Und sowas wie Templatevererbung oder Custom-Filter sind irre nützlich.
                      --

                      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                      Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                      --

                      Kommentar


                      • #12
                        Ich hänge an Plates. Gerade auch, weil ich viel mit angular mache und Twig blöderweise das gleiche Set an Delimitern verwendet. Ich weiss, kann man alles ändern, aber vielleicht funktioniert dann irgendwas in Twig nicht mehr richtig oder Twig ist irgendwann vielleicht nicht mehr updatefähig. Ka
                        Standards - Best Practices - AwesomePHP - Guideline für WebApps

                        Kommentar


                        • #13
                          und Twig blöderweise das gleiche Set an Delimitern verwendet
                          Das hört sich grad so an, als würdest du nur auf Twig-Seite die Delimiter änder wollen.
                          Warum machst du das nicht auf Angular-Seite?
                          http://stackoverflow.com/questions/1...stom-delimiter

                          @xm22,
                          also gegen Annotationen selbst habe ich ja nichts. Aber in PHP funktionieren diese nur via DocBlock und DocBlocks sind nunmal zur API Dokumentation (PHPDoc und so) da und nicht, um das Verhalten oder so etwas zu steuern

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

                          Kommentar


                          • #14
                            Ungerne. Bei Angular bekomme ich eher vorgefertigte Templates als bei Twig. Kommt nachher sicher auch auf das Projekt an, denn diese Annahme kann auch genau umgekehrt richtig sein.

                            Wenn ich mit Angular arbeite, habe ich tendenziell mehr Geschäftslogik im Browser und erzeuge häufiger Json-Output, seltener Html-Code. Daher ist für mich Twig eher die Komponente, die sich anpassen muss.
                            Standards - Best Practices - AwesomePHP - Guideline für WebApps

                            Kommentar


                            • #15
                              Zitat von kingjojo23 Beitrag anzeigen
                              -Dependency Injection, da würde ich mich über Tipps oder Beispiele in Bezug auf Best Practices von Euch freuen!
                              https://github.com/illuminate/container
                              http://laravel.com/docs/ioc

                              Zitat von kingjojo23 Beitrag anzeigen
                              -Möglichkeit der Definition von Routen und deren auswertung.
                              https://github.com/nikic/FastRoute
                              https://github.com/anandkunal/ToroPHP

                              Zitat von kingjojo23 Beitrag anzeigen
                              -Datenbank Anbindung mit einer Querybuilder Klasse.
                              https://gist.github.com/Golpha/8446061
                              https://github.com/doctrine/doctrine...eryBuilder.php

                              http://laravel.com/docs/queries
                              https://github.com/illuminate/database

                              Zitat von kingjojo23 Beitrag anzeigen
                              -Modelsystem, ORM Sinnvoll oder nicht?
                              Ja.

                              Zitat von kingjojo23 Beitrag anzeigen
                              -Templatesystem mit Cachingfunktion
                              https://github.com/fabpot/Twig

                              http://laravel.com/docs/templates
                              https://github.com/illuminate/view

                              Zitat von kingjojo23 Beitrag anzeigen
                              -Grid- und Formhelper
                              View Helper, Data Objects.

                              Zitat von kingjojo23 Beitrag anzeigen
                              -JS und CSS (möglicherweise auch Unterstützung von SASS, LESS) minifier.
                              https://github.com/ceesvanegmond/minify

                              - Du hast das Exception-Modell nicht verstanden.
                              - Request und Response sind unzulänglich
                              - Magische Konfiguration über Konstanten ist schwer wartbar und oldschool
                              - Das Wort "unregistriert" ist ein linguistischer Unfall
                              - Composer Autoloading - Autoloading Standards
                              [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

                              Lädt...
                              X