Zitat von paddelboot
Beitrag anzeigen
Ankündigung
Einklappen
Keine Ankündigung bisher.
Code wird zu komplex - Codedesign?
Einklappen
Neue Werbung 2019
Einklappen
X
-
Zitat von millcolin Beitrag anzeigenJunge, 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.
Zitat von derwunner Beitrag anzeigenDa muss ich dir widersprechen: Ich habe noch keine Anforderung gesehen und / oder selbst umgesetzt, die nicht auf Symfony mit Doctrine passen würde.
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.
- 2 Likes
Kommentar
-
Zitat von rkr Beitrag anzeigenBei 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.
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.[SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]
- 2 Likes
Kommentar
-
Zitat von tomBuilder Beitrag anzeigenIst Eloquent da besser ?
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.
- 1 Likes
Kommentar
-
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.
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.[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
-
Zuletzt geändert von paddelboot; 16.02.2018, 20:26.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.
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
-
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
-
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
Kommentar