dedlfix: Trennung der Anliegen (Logik - Layout)

Beitrag lesen

Hi!

Bei meinem aktuellen Projekt versuche ich strikt die Logik vom Layout zu trennen. Bis jetzt habe ich auch nur Sachen die man Anzeigen muss. Sprich Daten aus der Datenbank holen, für die Ausgabe aufbereiten und ausgeben. Das ganze natürlich ganz sauber mit Template Engine.

Auch PHP wäre bereits eine Template-Engine, und damit bekommt man das Ganze auch sauber hin. Eine Template-Engine kann aber anderweitig helfen, indem sie beispielsweise einfachere Syntax und weitere Funktionalität bereitstellt.

Jetzt komme ich jedoch zum ersten Eingabe Formular. Der erste Versuch das Sauber um zu setzen ist gescheitert, da sich wie ich finde die Anliegen vermischen (dazu gleich mehr).

Da muss zwangsläufig ein Zusammenspiel da sein, denn jeder Datentyp hat so seine Eigenheiten, die beim Eingabeelement berücksichtigt werden müssen. Eine Freitexteingabe geht nicht mit einer Checkbox, ein boolescher Wert macht sich in einem Textfeld nicht gut, usw.

Dieses input Feld möchte der Webdesigner jetzt jedoch als checkbox umsetzen. Dann bräuchte man jetzt noch eine Variable.

Er kann nicht einfach so Elemente nehmen, wie es ihm beliebt, er muss die fachliche Seite berücksichtigen. Das muss aufeinander abgestimmt sein.

Auf jeden Fall haben sich jetzt die Anliegen wie ich finde vermischt. Die Programmlogik muss wissen ob es sich um eine Checkbox handelt oder nicht. Und das war jetzt nur ein einfaches Beispiel.

Soweit muss es nicht kommen, wenn du die Programmlogik weiter teilst. Die Geschäftslogik will eigentlich nur mit einer booleschen Information arbeiten. Die Anzeigelogik muss dann daraus die notwendigen Template-Variablen erzeugen. Die Eingabedatenlogik muss aus dem POST/GET-Daten den booleschen Wert rauslesen.

Kann man die Anliegen überhaupt sauber trennen?

Es gibt auch Programmiermuster, die generelle Strukturierungen beschreiben, beispielsweise Model-View-Controller (MVC). Der Controller ist die zentrale Steuerung, aber eigentlich verteilt er die Arbeiten nur. Das Model kümmert sich um die fachliche Verarbeitung und um die Datenhaltung, die View bekommt Daten und erzeugt daraus die Ausgabe. Die Aufgaben der einzelnen Teile kann man nun auch wieder aufteilen. Zum Beispiel bedient sich das Model für das eigentliche Daten-Handling einer Datenbanklogik. Mit dem Controller tauscht es nur Rohdaten aus. Die View bereitet die vom Controller bekommenen Rohdaten für das Template auf, das seinerseits den Rest macht.

Lo!