Hallo Menschen
Dann beginne ich hier mal mit einem aktuellen Thema, das mich umtreibt. Mein altes Framework war eine wilde Durchmischung der verschiedenen Ebenen und nach Jahren einzelnen Nachvollzugs von bestimmten Neuerungen ein wahres Flickwerk und kaum zu bändigen. Darum habe ich direkt alles in den Eimer geschmissen und vor ca. sechs Wochen komplett neu gestartet.
Als ich mich nach langer codeabstinenter Zeit wieder mit dem aktuellen State of the Art beschäftigt habe, bin ich natürlich um das MVC-Pattern nicht herumgekommen. Wenn auch schon länger Standard, hat es in meinem Code, der vor 20 Jahre seinen Anfang gefunden hatte, noch keinen Einzug gefunden. Und so habe ich mich da mal profunder eingelesen und bin direkt auf einige Tradeoffs gestossen, dich ich nun sukzessive aufzulösen versuche.
Einer davon betrifft den Grundsatz, dass prinzipiell schlanken Controllern den Vorzug zu geben ist. Das leuchtet von daher ein, dass in einem Framework immer mal wieder Logik auftaucht, die wiederverwendbar sein sollte und entsprechend universell und nicht in einem proprietären Controller vorhanden sein sollte. So wie ich das verstanden habe, hat der Controller nur die Aufgabe Input entgegen zu nehmen, entsprechend dem Input in der Model-Schicht Geschäftslogik anzukicken, von der Geschäftslogik Daten zu empfangen und an den View weiterzureichen.
Entsprechend habe ich ziemlich viel, was vorher repetitiver Spaghetticode war, gekapselt. Namentlich duzende hard-coded Formulare und Listen mit List- und FormHandler-Klassen ersetzt. Hier stellt sich mir aber bereits die erste Architekturentscheidung, die das Potential hat, die Regeln des MVC-Pattern zu brechen oder zumindest zu ritzen.
Nach meinem Verständnis gehört der Aufbau eines Formulars (FormFactory liefert FormHandler, der mit Objekten des Typs FormElement gefüllt wird) nicht in den Controller, obwohl das natürlich eng mit der View-Schicht verwandt ist. Wenn ich ein rigides Verständnis des Patterns anwenden würde, müsste ich für jedes Formular eine Hilfsklasse erstellen.
Also kann ich hier eigentlich wählen: entweder ich befolge stur, was das Pattern als immanenten Grundsatz verankert hat und habe einen veritablen Hilfsklassenwildwuchs. Oder ich verzichte auf die sture Befolgung des Grundsatzes und habe dafür Controller die nicht mehr 'skinny' sind.
Ich habe mich hier vorerst für einen Kompromiss entschieden: Formulare, die unique sind, also nirgends ein zweites Mal gebraucht werden (bspw. Insert-News-Formular, das nur im Adminbereich in der Sektion News gebraucht wird) generiere ich im Controller über private Hilfsmethoden. Formulare die an mindestens zwei Orten gebraucht werden (bspw. das Formular um News zu filtern, das einerseits in der News-List im Adminbereich aber auch im News-Anzeigebereich des Userbereichs genutzt wird) kapsle ich in einer eigenen Hilfsklasse und binde sie dort ein, wo sie gebraucht werden.
Die Fragen hier mal ganz allgemein:
- Wendet ihr die Pattern-Rules konsequent an?
- Falls nein: nach welchen Kriterien entscheidet ihr euch, von den best practices abzuweichen?
- Falls mein Kompromiss nicht allzu jenseits ist - was ist stärker zu gewichten: skinny controller oder Verhindern einer Hilfsklassenschwemme?
Ganz allgemein sehe ich, wie mächtig die aktuell herrschenden Grundsätze sind und den sukzessiven Aufbau von wirklich grossen Tools wunderbar unterstützen. Deshalb werde ich mich hier noch weiter reinfuchsen und bin am Austausch interessiert.
Weiterhin ein gutes Wochenende allerseits.
Gruss
Dann beginne ich hier mal mit einem aktuellen Thema, das mich umtreibt. Mein altes Framework war eine wilde Durchmischung der verschiedenen Ebenen und nach Jahren einzelnen Nachvollzugs von bestimmten Neuerungen ein wahres Flickwerk und kaum zu bändigen. Darum habe ich direkt alles in den Eimer geschmissen und vor ca. sechs Wochen komplett neu gestartet.
Als ich mich nach langer codeabstinenter Zeit wieder mit dem aktuellen State of the Art beschäftigt habe, bin ich natürlich um das MVC-Pattern nicht herumgekommen. Wenn auch schon länger Standard, hat es in meinem Code, der vor 20 Jahre seinen Anfang gefunden hatte, noch keinen Einzug gefunden. Und so habe ich mich da mal profunder eingelesen und bin direkt auf einige Tradeoffs gestossen, dich ich nun sukzessive aufzulösen versuche.
Einer davon betrifft den Grundsatz, dass prinzipiell schlanken Controllern den Vorzug zu geben ist. Das leuchtet von daher ein, dass in einem Framework immer mal wieder Logik auftaucht, die wiederverwendbar sein sollte und entsprechend universell und nicht in einem proprietären Controller vorhanden sein sollte. So wie ich das verstanden habe, hat der Controller nur die Aufgabe Input entgegen zu nehmen, entsprechend dem Input in der Model-Schicht Geschäftslogik anzukicken, von der Geschäftslogik Daten zu empfangen und an den View weiterzureichen.
Entsprechend habe ich ziemlich viel, was vorher repetitiver Spaghetticode war, gekapselt. Namentlich duzende hard-coded Formulare und Listen mit List- und FormHandler-Klassen ersetzt. Hier stellt sich mir aber bereits die erste Architekturentscheidung, die das Potential hat, die Regeln des MVC-Pattern zu brechen oder zumindest zu ritzen.
Nach meinem Verständnis gehört der Aufbau eines Formulars (FormFactory liefert FormHandler, der mit Objekten des Typs FormElement gefüllt wird) nicht in den Controller, obwohl das natürlich eng mit der View-Schicht verwandt ist. Wenn ich ein rigides Verständnis des Patterns anwenden würde, müsste ich für jedes Formular eine Hilfsklasse erstellen.
Also kann ich hier eigentlich wählen: entweder ich befolge stur, was das Pattern als immanenten Grundsatz verankert hat und habe einen veritablen Hilfsklassenwildwuchs. Oder ich verzichte auf die sture Befolgung des Grundsatzes und habe dafür Controller die nicht mehr 'skinny' sind.
Ich habe mich hier vorerst für einen Kompromiss entschieden: Formulare, die unique sind, also nirgends ein zweites Mal gebraucht werden (bspw. Insert-News-Formular, das nur im Adminbereich in der Sektion News gebraucht wird) generiere ich im Controller über private Hilfsmethoden. Formulare die an mindestens zwei Orten gebraucht werden (bspw. das Formular um News zu filtern, das einerseits in der News-List im Adminbereich aber auch im News-Anzeigebereich des Userbereichs genutzt wird) kapsle ich in einer eigenen Hilfsklasse und binde sie dort ein, wo sie gebraucht werden.
Die Fragen hier mal ganz allgemein:
- Wendet ihr die Pattern-Rules konsequent an?
- Falls nein: nach welchen Kriterien entscheidet ihr euch, von den best practices abzuweichen?
- Falls mein Kompromiss nicht allzu jenseits ist - was ist stärker zu gewichten: skinny controller oder Verhindern einer Hilfsklassenschwemme?
Ganz allgemein sehe ich, wie mächtig die aktuell herrschenden Grundsätze sind und den sukzessiven Aufbau von wirklich grossen Tools wunderbar unterstützen. Deshalb werde ich mich hier noch weiter reinfuchsen und bin am Austausch interessiert.
Weiterhin ein gutes Wochenende allerseits.
Gruss