Struktur eines umfangreichen PHP-Projekts

[Kalle_B(irkenau/Odw.)]

Liebe virtuelle Kollegen,

ich wurschtele als Einzelkämpfer vor mich hin und habe nur dieses
Forum zum Austausch. Ich möchte es nicht missen. Die Hilfe kann wohl auch unter "leiblichen Kollegen" nicht besser sein. Schade, dass wir keinen Kaffee miteinander trinken können, so manche Idee könnte man weiterentwickeln.

Habe Gesprächsbedarf, wie IHR ein großes Projekt strukturiert. Nicht nur das DB- Layout und die Programme, sondern auch die begleitende Dokumentation und Hilfe- Texte. Was liegt in PHP- Dateien, was wird include-d, was sind autonomen HTML- Dateien, was kommt aus der Datenbank?

Sicherlich liegt die Programmlogik, die SQL- Kommandos, die Bildschirmanzeige und die Druckaufbereitung in getrennten Dateien und wird per include zusammengefügt. Arbeitet ihr objektorientiert?

So habe ich es seinerzeit (1987 - 1998) mit einem Warenwirtschaftssystem unter Turbo-Pascal und MS-DOS gemacht.

Nun nimmt ein Terminmanagement-Projekt eines Kunden Größenordnungen an, das ich seit 2004 betreue:

Programmiersprache: PHP
Datenbank:          MySQL
Browser:            Firefox 1.5
JavaScript:         bisher vermieden

================
NEUERUNGEN 2006:

1. Zentrales Programm, das IMMER so angesprungen wird:
------------------------------------------------------

<form action="tm_manager.php" method='post'>
  <input type='hidden' name='kennwort' value="Kalle">
  <input type='hidden' name='last_login' value="1140121578">
  <input type='hidden' name='zielprogramm' value='tm111'>

Das 'last_login' ist eine Zufallszahl und wird nach korrektem Login im DB-Satz des Users hinterlegt. Es ist sein Zugangscode für diese Sitzung, quasi eine Session-ID. Das Konzept Session-ID habe ich getestet, es hinterlässt jedoch einen Müllberg von temporären Dateien auf dem Server. Wann auch sollte eine Session eliminiert werden?

Das 'zielprogramm' ist jenes, das tm_manager.php per include aufruft, nachdem die Datenbank geöffnet und die Zugangsberechtigung geklärt ist. Eigenschaften des Users (z.B. Sprache, Zugriffsrechte, ...) werden dem Zielprogramm zur Verfügung gestellt.

2. Auslagerung von Listen und Formularen als anzeigbare HTML- Dateien
---------------------------------------------------------------------

Das Zielprogramm tm111 kann mehrere Display-Dateien haben, die je nach Sprache oder Zugangsberechtigung unterschiedlich sind:

form111_de.htm (deutsch):
<!--[kopf]-->      Segment kopf
...
<!--[/kopf]-->
<!--[position]-->  Segment position
...
<!--[/position]-->
<!--[fuss]-->      Segment fuss
...
<!--[/fuss]-->

form111_en.htm (englisch)
form111_esan.htm (spanisch, NUR anzeigen, keine Änderung erlaubt)
...

Die Datei wird nicht einfach include-d, sondern durch ein Unterprogramm in den Speicher gelesen und mehrfach vom Leitprogramm angesprungen. Ein Durchlauf für den Kopf, n Durchläufe für die Positionen (bei Listen) und einen Durchlauf für den Fuss. Zusätzliche Segmente für Zwischenüberschriften und Gruppensummen möglich.

Im Moment hat eine solche *.htm Datei im Kopf sogar ihr eigenes CSS, dadurch wird sie autonom anzeigbar:

form.f111 fieldset {...}

3. Auslagerung von Funktionen
-----------------------------
Das habe ich 2005 schon eingeführt. function xyz(...)  wird mit Parametern aufgerufen und erledigt eine Teilaufgabe, etwa die Zusammenstellung von Personen, die um 9:00 Uhr noch keinen Termin haben und für eine Terminvereinbarung offen sind.

4. Auslagerung von SQL- Kommandos
---------------------------------
$q = "SELECT ... LEFT JOIN ... GROUP BY ... HAVING ..."

kann schon sehr aufwendig sein. Jedes SQL- Kommando muss online mit phpmyadmin auf Tauglichkeit getestet werden.

Habe ich bisher im Programmcode "versteckt", macht aber wohl Sinn, als function deklariert zu werden.

Tja, und jetzt würde bei einem persönlichen Treffen das Gespräch beginnen von "vollkommen abartig" über "könnte man so machen" bis "geil ey, echt DIE Idee".

Lasst von euch hören, ähhh - lesen.

Lieben Gruß aus Birkenau, Kalle

[Jörg Peschke]

Hallo Du,
Ich weiss nicht, ob ich Deinen Ausführungen weit genug folgen kann, sprich, wirklich verstehe, was Du wo machst. Aber generell würde ich auf folgendes Achten:

• Strikte Trennung von Darstellung, Anwendungslogik und Datenhaltung.
  In Java gibt es dazu ja das MLV-Modell, so etwas würde ich auch in PHP machen.

• Alle Funktionen und Klassen, die demselben Zweck dienen, würde ich in eine
    PHP-Datei mit einem selbsterklärenden Namen packen.

-Objektorientierung ist kein Muß, aber ich finde, in PHP wird der Code deutlich aufgeräumter.

• Abbilden von Datenbank-Objekten auf PHP-Objekte.
    Für jedes Objekt, welches in Deiner Datenbank schwirrt (z.b. "Mitarbeiter",
  "Abteilung" usw.), würde ich eigene PHP-Klassen schreiben, jeweils mit Methoden
  zum Anlegen, Speichern, Löschen Verändern usw. des Objektes in der Datenbank.
  Etwas wie:

$mitarbeiter = new Mitarbeiter("Klaus", "Meyer");
 $mitarbeiter->assign($abteilung);
 $mitarbeiter->store();

liest sich einfach schön ;).

• Komplexe Verknüpfungen von Daten die Datenbank machen lassen und nicht selbst programmieren (das führt leider manchmal zu einem Bruch mit den oben angesprochenen Daten-Objekten in PHP, bringt aber Performance-gewinn und ist robuster)

• Alle Konfigurierbaren Parameter in seperate Konfigurationsfiles (am besten XML oder was ähnlich einfach menschen-lesbares)

• Fleissig try...catch und throw benutzen um auf Fehler zu reagieren.

• Last but not Least: Einen polemischen, aber wahren Satz über sauberen Code den ich mal wo gelesen habe:
  "Jeder Codeblock, der mit mehr als einem Satz kommentiert werden muss, damit man ihn versteht, sollte in eine eigene Funktion".

So.
Vielleicht weißt Du das aber alles schon, und mein Post bringt dich nur geringfügig weiter. Vielleicht aber auch nicht.

Grüße,
Jörg

[Kalle_B]

Hallo, Jörg.

Danke erstmal. Hatte noch auf andere Reaktionen gewartet. Dachte, so etwas müßte doch ein breiteres Thema sein.

Habe mich schon in die objektoentierte Programmierung mit PHP 4 etwas eingelesen.

Lieben Gruß, Kalle