Ankündigung

Einklappen
Keine Ankündigung bisher.

Code wird zu komplex - Codedesign?

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

  • #31
    Zitat von paddelboot Beitrag anzeigen

    Darum geht es doch - der Kunde weiß selber nicht, wie genau sich die App noch weiter entwickeln wird. Also kann ich auch nicht einschätzen, welche "Bausteine" in Zukunft modifizierbar sein müssen. Daher habe ich mich entschloßen, die App neu aufzubauen - auf Grundlage eines Frameworks. Ob das jetzt Symfony oder Laravel oder was anderes sein wird, ist noch offen. Dazu muss ich erstmal die Formularkomponenten der Frameworks genauer anschauen. Und natürlich muss der Kunde diesen zusätzlichen Aufwand auch kaufen. Ich setze also quasi meine Murmeln auf ein MVC-Framework, weil ich annehme, damit aus der Sackgasse rauszukommen. Die Workflow-Engine hört sich interessant an, es ist mir aber auch nach Recherche nicht klar genug, wie das abläuft bzw. wie das zu implementieren wäre.
    .
    Junge, junge, hat das lange gedauert. Ich habe dir schon im Post vom 19.1. empfohlen auf ein handelsübliches Framework zu setzen und die Idee mit der Workflow Engine zu überlesen.

    Kommentar


    • #32
      Zitat von millcolin Beitrag anzeigen
      Junge, junge, hat das lange gedauert. Ich habe dir schon im Post vom 19.1. empfohlen auf ein handelsübliches Framework zu setzen und die Idee mit der Workflow Engine zu überlesen.
      Ich sehe hier immer noch keinen direkten Zusammenhang zwischen dem eingangs beschriebenen Problem und einem Framework. Ich selbst benutze auch kein Standardframework, weil unsere Kernapplikation mittlerweile schon recht alt ist - so alt, dass es zu deren Geburtsstunde noch gar kein Symfony gab. Mittlerweile wäre ein Umstieg auf Laravel oder Symfony (mit Ausnahme von Symfony 4) aber ein Schritt zurück.

      Zitat von derwunner Beitrag anzeigen
      Da muss ich dir widersprechen: Ich habe noch keine Anforderung gesehen und / oder selbst umgesetzt, die nicht auf Symfony mit Doctrine passen würde.
      Bei Symfony magst du recht haben. Aber Doctrine?
      Jeder in meinem Dunstkreis, der mal ernsthaft was mit Doctrine gemacht hat, hat es entweder aus ideologischen Gründen eingeführt und quält sich jetzt oder hat die Idee schnell wieder verworfen. Bei einfachen Sachen ist das sicher hilfreich und spart ein wenig Arbeit uns so. Aber sobald die Anwendung komplexer wird, hast du mit Doctrine nur noch ärger. Besonders, wenn man da noch Cross-Cutting-Concerns auf die Objekte projezieren muss wie "Darf der aktuell angemeldete User diese Entität überhaupt sehen?".
      Zumal wir heute in den Anwendungen, die für Doctrine eigentlich prädestiniert sind (weil einfach gestrickt) eigentlich kaum mehr mit Daten-Objekten arbeiten, weil die ja eh wieder sofort auf JSON projeziert werden müssen.
      Ich würde jetzt zwar nicht sagen, dass Doctrine generell immer eine schlechte Idee ist, aber ich wäre super vorsichtig zu sagen, dass man jede Anwendung damit beginnen sollte.
      Standards - Best Practices - AwesomePHP - Guideline für WebApps

      Kommentar


      • #33
        Zitat von rkr Beitrag anzeigen
        Bei Symfony magst du recht haben. Aber Doctrine?
        Jeder in meinem Dunstkreis, der mal ernsthaft was mit Doctrine gemacht hat, hat es entweder aus ideologischen Gründen eingeführt und quält sich jetzt oder hat die Idee schnell wieder verworfen. Bei einfachen Sachen ist das sicher hilfreich und spart ein wenig Arbeit uns so. Aber sobald die Anwendung komplexer wird, hast du mit Doctrine nur noch ärger. Besonders, wenn man da noch Cross-Cutting-Concerns auf die Objekte projezieren muss wie "Darf der aktuell angemeldete User diese Entität überhaupt sehen?".
        Zumal wir heute in den Anwendungen, die für Doctrine eigentlich prädestiniert sind (weil einfach gestrickt) eigentlich kaum mehr mit Daten-Objekten arbeiten, weil die ja eh wieder sofort auf JSON projeziert werden müssen.
        Ich würde jetzt zwar nicht sagen, dass Doctrine generell immer eine schlechte Idee ist, aber ich wäre super vorsichtig zu sagen, dass man jede Anwendung damit beginnen sollte.
        +1

        Ich habe hier ein größeres Projekt bei dem jede Menge komplexe SQL-Queries laufen. Ursprünglich lief das gesamte Projekt auf Doctrine, aber mit zunehmender Komplexität wurde daraus ein Stolperstein, die generierten Queries waren zum Großteil Müll und nur mühselig umzusetzen. Ich bevorzuge mittlerweile die Nähe zu blankem SQL, maximal durch einen Query-Builder abstrahiert.

        Kommentar


        • #34
          Ist Eloquent da besser ?

          Kommentar


          • #35
            Zitat von tomBuilder Beitrag anzeigen
            Ist Eloquent da besser ?
            Kann ich mich mangels Erfahrung nicht fundiert zu äußern.

            Ich habe gerade die Dokumentation von Eloquent überflogen und keine Möglichkeit gefunden, freie SQL-Queries über einen Query-Builder oder einen DBAL zu formulieren. Das ist ja quasi zwingend erforderlich, weil man sonst nicht DBMS-Agnostisch wäre.
            Raw-Queries gegen wohl. Heißt, man könnte für einfache Entitäten immer noch den Active-Record-Ansatz von Eloquent verwenden und bei komplexeren Aufgaben dann zu Raw-SQL zurückgreifen - hier könnte man auch einen Querybuilder wie Aura.Sql verwenden.
            Ich habe jetzt auch noch keine Infos gefunden, ob Eloquent auch Unit of Work implementiert. Das würde parallele Raw-SQL-Geschichten verkomplizieren.
            Standards - Best Practices - AwesomePHP - Guideline für WebApps

            Kommentar


            • #36
              Zitat von rkr Beitrag anzeigen
              [...]
              Bei Symfony magst du recht haben. Aber Doctrine?
              Jeder in meinem Dunstkreis, der mal ernsthaft was mit Doctrine gemacht hat, hat es entweder aus ideologischen Gründen eingeführt und quält sich jetzt oder hat die Idee schnell wieder verworfen. Bei einfachen Sachen ist das sicher hilfreich und spart ein wenig Arbeit uns so. Aber sobald die Anwendung komplexer wird, hast du mit Doctrine nur noch ärger. Besonders, wenn man da noch Cross-Cutting-Concerns auf die Objekte projezieren muss wie "Darf der aktuell angemeldete User diese Entität überhaupt sehen?".
              Zumal wir heute in den Anwendungen, die für Doctrine eigentlich prädestiniert sind (weil einfach gestrickt) eigentlich kaum mehr mit Daten-Objekten arbeiten, weil die ja eh wieder sofort auf JSON projeziert werden müssen.
              Ich würde jetzt zwar nicht sagen, dass Doctrine generell immer eine schlechte Idee ist, aber ich wäre super vorsichtig zu sagen, dass man jede Anwendung damit beginnen sollte.
              Meine Worte. Deshalb bin ich schon lange auf Passive Record umgezogen. Query-Builder ist (leider?) mein eigener entstanden über mehrere Projekte hinweg.

              Und wer schonmal mit C# und Linq-Queries gearbeitet hat (oder allg. dem Entity Framework von Microsoft), erfreut sich sowieso, etwas unmögliches zum debuggen und reproduzieren im Code zu haben. Das ist mit Doctrine immerhin nur halb so schlimm.
              GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

              Kommentar


              • #37
                Zitat von millcolin Beitrag anzeigen

                Junge, junge, hat das lange gedauert. Ich habe dir schon im Post vom 19.1. empfohlen auf ein handelsübliches Framework zu setzen und die Idee mit der Workflow Engine zu überlesen.
                Jo, und? Meinst du, ich soll bei jedem Vorschlag hingehen und 5+ Stunden an Recherche investieren oder gleich blind auf den Zug aufspringen? Man lernt halt dazu, ich arbeite seit 2011 ausschließlich mit CMS und habe mit PHP-Frameworks wie Laravel oder Symfony GAR NICHTS am Hute bisher. Ob mir das jetzt bei meinem Projekt helfen wird, steht in den Sternen - es scheint mir der brauchbarste Vorschlag zu sein, daher fahre ich damit. Ggfs. wird es auch eine Kombination aus CMS und Framework. Denn das Problem bei Frameworks ist immer noch das nicht existierende Backend, welches man quasi selber erstellen (und dem Kunden verkaufen) müsste. Und dass nicht alle und jeder nur Glücksmomente mit Frameworks oder bestimmten Komponenten hatten, kannst du ja hier ebenfalls nachlesen.

                >Ich sehe hier immer noch keinen direkten Zusammenhang zwischen dem eingangs beschriebenen Problem und einem Framework.

                Das von mir benutzte CMS (WordPress) hat eine ganz "eigene" Codearchitektur - kein MVC, und oft nichtmal Klassen- bzw. Objektorientiert. Letzten Endes baut man sich in seiner Theme/Plugin - Sandbox was zusammen, und für viele Projekte reicht das auch. Aber eine wirklich tiefere Struktur existiert da nicht, bzw. es existiert nur das, was man sich im Rahmen der Möglichkeiten selber erstellt - z.B. eine gewisse Ordnerstruktur und klassenbasierter Code. Hier sehe ich das Hauptproblem.


                >Doctrine

                Auf Datenbank-Ebene sehe ich noch die geringsten Probleme. Die Anzahl der Produkte ist auch überschaubar. Derzeit verwenden wir nichtmal eine Datenbank, sondern ein via Google-API intergriertes Spreadsheet, damit der Kunde dort selber schnell Änderungen anbringen kann. Zwar nicht so performant wie eine auf demselben Server liegende Datenbank, aber simpel in der Benutzung.

                Kommentar


                • #38
                  Ein paar Monate später kann ich meine Frage selber beantworten.

                  Aus meinem ersten Beitrag kann man eigentlich herauslesen, dass die Geschäftslogik unübersichtlich wird. Da hilft einem ein MVC-Framework nicht wirklich weiter, weil MVC über den Aufbau der Geschäfts-Schicht nicht viel aussagt. Frameworks wie Laravel oder Symfony sind also eine Lösung für die Präsentations-Schicht der Applikation, aber nicht für die "tiefer" liegenden Schichten wie Domäne/Geschäft oder Infrastruktur.

                  Ich belese mich seither zu Herangehensweisen wie Domain Driven Design bzw. einzelnen Modellen wie der Onion-Architektur. Das Entkoppeln von Schichten und Klassen und das Vermindern von Abhängigkeiten war dabei ein erster großer Schritt.

                  Kommentar


                  • #39
                    Grundlegend sehe ich, dass etwas Probleme in der Architektur enthalten sind. Auf Basis der genannten Forderungen / Änderungsfrequenz, tendiere ich dazu, zu sagen, dass Workflows an dieser Stelle auch eher etwas oversized sind. Schlüsselwörter wie "Er möchte immer neue Regeln haben" zwingen einen fast schon dazu, in Richtung Geschäftswissen / Regelmaschinen zu denken. Aus der Java-Ecke gibt es hier Engines wie z.B. JRules oder Drools, mit denen man solche Regeln einfach schreiben kann und damit die Geschäftslogik und auch -wissen abbilden kann.

                    Ich habe keine Ahnung, ob https://gndf.io/ hier eine simple Lösung bietet, da ich das nicht kenne und nur oberflächlich nach PHP und Business Rules gesucht habe. Mit geeigneter Dateistruktur ist dies hier aber vllt. genau die simple Lösung, die dir es ermöglicht, schnell neue Regeln zu schreiben: https://github.com/bobthecow/Ruler

                    Kommentar

                    Lädt...
                    X