OOP - korrekter Ablauf / gute Struktur

honse33

Grünschnabel
Hallo,

durch ein anderes Projekt war ich gezwungen mit C# zu arbeiten und mich mit OOP zu beschäftigen. Da mir das ganze eigentlich schon recht gut gefallen hat, wollte ich mich nun an einige Seiten setzen, um die mit OOP aufgeräumter und strukturierter von Grund auf neu zu schreiben.

Man findet dazu ja recht viel im Internet - tatsächlich ist es jedoch zu viel. Viele Schnippsel, die man aufschnappt und dann irgendwie zusammensetzen muss. Letztendlich bin ich bei dem Stichwort MVC, oder zumindest einem MVC-ähnlichen Konstrukt, stehengeblieben.

Vorher habe ich meine Seiten immer recht stumpf aufgebaut - jede Datei hat gemischten Content (PHP+JS+HTML, Logik+Output). So hat man eine index.php mit einer Form, die auf sich selbst zeigt, Daten auswertet und dem User Bescheid gibt. Dann landet er quasi auf der dashboard.php, die zu dem User alles mögliche raussucht und direkt ausgibt.

Ok, ich kürze mal ein wenig ab. Als recht gute Struktur habe ich ein Mini-Framework gefunden: https://github.com/panique/mini2/. Es verbindet "Slim" als Router und "Twig" als View-Engine.

Dadurch, dass ich immer jede Seite als eigenständiges Script aufgebaut habe, bin ich mir nicht ganz sicher, wie man das alles nun korrekt trennt und dann als "komplette App" verbindet. Gibt es in der Richtung gute Artikel, Präsentationen oder ähnliches?

Ich finde ganz viele Sachen, die ich jedoch nur schwer miteinander verbinden und somit nicht wirklich verstehen kann: SOLID-Prinzip, Separation of Concerns (vom Prinzip her verstanden, die Anwendung ist aber noch schwierig), Dependency-Injection, Inversion of Control, ..... Es scheint auch so, als hätte jeder irgendwie eine andere Interpretation über diese Begriffe.

Wie man Klassen aufbaut und strukturiert ("DRY") habe ich einigermaßen drauf. Aber alles weitere ist für mich unklar.
 
Hallo,

Vorher habe ich meine Seiten immer recht stumpf aufgebaut - jede Datei hat gemischten Content (PHP+JS+HTML, Logik+Output).
Dies ist eigentlich genau der falsche Weg. Die Logik muss von der Ausgabe getrennt werden!

Das von dir verlinkte Projekt weist auch einige "Schwächen" auf. Man muss natürlich immer relativ sein. Wenn man jede Schwäche ausbügeln will, gelangt man irgendwann wieder zu einem riesigen Framework, welches man dann sicherlich nicht mehr als "slim" bezeichnen könnte.

Nehmen wir z. B. das Model: https://github.com/panique/mini2/blob/master/Mini/Model/Model.php#L19
Bei jedem neuen Model wird eine neue DB-Verbindung geschaffen. Eine DB-Verbindung sollte logischerweise wiederverwendet werden. Man müsste also eine Referenz zu einem DB-Objekt per Dependency Injection übergeben. Dies kann bspw. in Konstruktor geschehen. Auch werden die globalen Konfigurationsdaten für die DB benutzt. Möchtest du z. B. Unit Testing anwenden, so müsstest du globale Variablen verändern, dessen Wirkungsbereich du nie abschätzen kannst (Wo wird das jetzt überall verwendet? Was hängt davon ab?). Dependency Injection kann auch hier Abhilfe schaffen.
 
Dies ist eigentlich genau der falsche Weg. Die Logik muss von der Ausgabe getrennt werden!

Genau. Das habe ich verstanden. Und suche nun eben nach einem gewissen Leitfaden, um die ganzen Design Pattern und so weiter zu verstehen.
Bei Stackoverflow habe ich nun das Stichwort "Single Point of Entry" gelesen und bin auf ein kleines Tutorial von phpro.org (klick) gestoßen. Dort werden die Abläufe zumindest für das MVC-Skeleton erklärt.

Was mir jetzt noch Schwierigkeiten bereitet, ist der grobe Ablauf; quasi wie man nun in solch ein Skelett die korrekte Reihenfolge der Komponenten reinbringt. Wann kommt das Sessionhandling, wann wird auf eingeloggte User geprüft usw. Gibt es dafür einen groben Leitfaden, wie man da vorzugehen hat? Oder eben was in Richtung "Best Practices"?

Da ich eine grobe Vorstellung der fertigen Seite habe (alter Code ist ja vorhanden), könnte ich mir nun Snippets und Erklärungen mühsehlig zusammensuchen und diese irgendwie aneinanderkleben. Tatsächlich habe ich aber Angst, dass ich dann mittendrin feststelle, dass mein Ansatz scheiße war und ich alles wieder über Bord werfen muss. Also vorher genügend informieren, einen gewissen Plan anfertigen und direkt richtig durchstarten. :)
 
Ein eigenes MVC-Framework bauen? Wieso das Rad neu Erfinden, schau dir mal das J!-Framework als "Stand-alone" an (Oder eben Joomla selber) ;)
Oder Symfony2, Silex und Konsorten
 
Zurück