Comelio GmbH PHP: Enterprise Applications Muster - Design Patterns - Entwurfsmuster PHP Handbuch SQL XML Anleitung Tutorial LDAP MySQL SQLJ -

Mittlerweile haben es einige der Muster aus dem Standardkatalog nicht nur auch in die Praxis der PHP-Welt geschafft, sondern geistern gleichfalls durch Artikel und Bücher für Anfänger und Profis. Als typischer Grenzgänger zwischen den objektorientierten Sprachen PHP, Java und C# erscheint mir dies als überaus sinnvoll, weil PHP durch die neuen OOP-Fähigkeiten, welche hoffentlich noch weiter ausgebaut werden, nun auch auf den Erfahrungsschatz von vielen anderen Programmierern zurückgreifen kann. Dies ist deswegen sehr zu begrüßen, weil gerade die „großen“ Sprachen durch Herstellerunterstützung und damit auch Finanzkraft – was im Open Source-Bereich nicht gerne gehört wird – besonders umfangreiches Material für den Umgang mit ihren Technologien angeboten haben. Man ist gerade nicht gezwungen, für jede Anwendung das berühmte Rad neu zu erfinden, sondern kann auf Ideen, Techniken und (halb-)fertige objektorientierte Entwürfe von wiederkehrenden Problemen zurückgreifen. Damit sind durchaus nicht nur fertige Klassenbibliotheken gemeint, die natürlich auch – oder gerade - im Open-Source-Bereich verfügbar sind und sich sowohl in der PEAR-Bibliothek als auch in den Datenbeständen vieler anderer Plattformen befinden.

Allerdings ist es nicht mit fertigen Lösungen für besondere Aufgaben getan, die sich letztendlich als Komponenten begreifen lassen und einfach in einer anderen Anwendung aufgerufen werden können. Es geht auch nicht um völlig fertige Lösungen, die wie ein Gästebuch, ein Forum oder gar ein ganzes Content-Management-System zur Weiterverwendung bereit stehen, da hier ein ganzes Konglomerat aus Komponenten herunter geladen, entpackt, in das richtige Verzeichnis kopiert und dann entweder nur eingebunden oder tatsächlich auch verändert wird. Es geht vielmehr darum, Lösungen für Entwurfsprobleme zu finden, also Fragen nach der Architektur, nach dem grundlegenden Aufbau von Klassen, ihrem Zusammenfügen zu möglichen wieder verwendbaren Komponenten, den passenden Vererbungsregeln, der Ableitung von konkreten Klassen aus konzeptuellen abstrakten Klassen oder natürlich dem richtigen Aufbau von Schnittstellen. Die Liste lässt sich mit Unterpunkten zu den genannten Arbeitsaufgaben verfeinern und sich zu einem hohen Turm aus Aufgaben mit verwirrenden Interdependenzen aufschichten. Dieser Turm hat zudem die unangenehme Eigenschaft, größer zu werden, je mehr man sich ihm nähert, da immer neue Verästelungen und Architekturanforderungen von der Seite, seinen Fundamenten oder zukünftigen Baumeistern gestellt werden. Hier lässt sich dann auch leicht nicken, warnend den Finger heben und geheimnisvoll von der Paralyse durch Analyse orakeln, um also unmittelbar mit dem Codieren zu beginnen wie eh und je und sich nachher über Kunden, Kollegen, Zulieferer und natürlich die ganze Welt zu ärgern.

An diesem Punkt sollen nun die Entwurfsmuster helfen, wobei insbesondere die spezialisierten Kataloge mit dem Anspruch auftreten, Lösungen für konkrete Entwurfsprobleme parat zu haben. Zwar wird man hier immer (noch) nicht den perfekten Entwurf für Gästebücher, Shops, CMS und dergleichen finden, aber Muster für die Präsentation von Daten, Schichtung von Architekturen oder Datenzugriffe auf relationale Datenbanken sind in jedem Fall in so ausreichender Fülle zu finden, dass man sowohl mit den Mustern im Originalzustand als in jedem Fall auch mit Kombinationen und Variationen von ihnen seine häufigsten Überlegungen wenigstens mal mit einer anderen Vorstellungen vergleichen kann. Vermutlich dürfte dann auch mal das ein oder andere Muster für Gefallen sorgen, weil es haargenau auf das gestellte Problem zugeschnitten ist und damit eine Lösung darstellt.

Zielsetzung des Enterprise-Katalogs

Wie alle Kataloge, die sich neben dem Standardkatalog etabliert haben, hat der Enterprise-Katalog ebenfalls ein spezielles Ziel, was die Anwendung seiner Muster und Vorschläge für andere Software als die von ihm fokussierte natürlich in den meisten Fällen nicht begünstigt. Wie ist das überhaupt zu verstehen? Wenn sich Programmierer mit Entwurfsmustern beschäftigen, dann treffen sie für gewöhnlich zuerst auf den Standardkatalog, der mit solchen klassischen Mustern wie Singleton, Beobachter, Besucher, Befehl oder Fassade aufwartet. In allen Darstellungen zu diesen Themen finden sich zwar jeweils auch Beispiele, aber sie sind immer wieder anderer Art. Dem einen sind sie zu technisch, dem anderen zu internetfixiert, der dritte programmiert nun einmal keine Spiele und der vierte fühlt sich genau verstanden und glaubt, dass er beim Programmierern einer Armee immer nur mit dem Kompositum-Muster arbeiten kann (es ist unbekannt, wie viele Armeen er in seinem Leben noch programmieren wird und was alle anderen Armee-Programmierer machen, die von dem Muster noch nichts gehört haben).

Als Beispiel lässt sich das sehr einfach zu verstehende Fassade-Muster verwenden. Ganz bewusst haben wir die Struktur mit so allgemeinen Begriffen abgebildet, dass jeder mit dem Muster zufrieden zeigen müsste. Die beiden Klassen Client1 und Client2 interagieren nicht direkt mit den vielfältigen Unterklassen, die theoretisch greifbar wären. Stattdessen interagieren sie ausschließlich mit der Fassadenklasse. Dies muss nicht notwendigerweise eine einzige Klasse sein, aber die Anzahl der Klassen, welche die Fassade bilden, sollte deutlich kleiner als die der von ihnen verdeckten Klassen sein, damit die Arbeit mit der Fassade einfacher ist als mit dem gesamten verdeckten Klassensystem.

Unabhängig vom konkreten Muster sollte dieser kurze Ausflug in den Standardkatalog zeigen, dass die Muster dort tatsächlich sehr allgemein sind und sich ausschließlich auf allgemeine wiederkehrende Probleme konzentrieren. Sie sind selbstverständlich nicht für Labyrinthe, Armeen oder geometrische Formen erzeugende Systeme entwickelt worden. Ganz anders verhält es sich mit den spezialisierten Musterkatalogen, die ausschließlich Lösungen für besondere Softwarelösungen anbieten: Unternehmensanwendungen, Software für den Finanzsektor, technische Software, Datenintegration und –austausch, um nur einige zu nennen. Im Internet findet man fast genauso viele Mustervorschläge wie es Softwareprobleme gibt..., also wenigstens unendlich viele.

Die Enterprise Muster konzentrieren sich also auf Unternehmensanwendungen, die mit folgenden Eigenschaften beschrieben werden können:

Wenngleich auch nicht offiziell, so möchte ich persönlich die meisten PHP-Anwendungen in diese Kategorie fallen lassen, die ich bisher gesehen habe. Auch wenn es um Konzertkartenverkauf im Internet oder auch ein Forum geht, so erfüllen diese Systeme doch die meisten Anforderungen aus obiger Liste, ohne tatsächlich automatisch als Unternehmensanwendung gelten zu können. Da in anderen Sprachen auch eine Vielzahl von Software für jede Art von Gerät oder technischer Komponente erzeugt werden kann, was in PHP nicht möglich ist, so ist insbesondere dieser Katalog für PHP-Programmierer und Systemarchitekten von besonderer Bedeutung, da – obwohl ich leider keine Zahlen anbieten kann – die meisten Entwicklungen Probleme lösen müssen, die genau mit einigen Mustern aus dem Katalog zu lösen gewesen wären.

Grundarchitektur: Schichtung

In diesem Jahr habe ich die Besuche in PHP-Teams, die neue Software komplett objektorientiert aufsetzen oder bereits bestehende System objektorientiert neu gestalten wollten, gar nicht richtig zählen können. Es waren in jedem Fall eine erstaunliche Anzahl, und jedes Mal ging es darum, dass auch nach der Beschäftigung mit den interessanten neuen Schlüsselwörtern und Konzepten nicht klar war, wie man denn nun vorgeht, um eine Software „richtig“ objektorientiert aufzubauen. Bei dieser Formulierung ist allerdings nicht klar, ob sich das Wort „richtig“ auf die OOP oder auf die Tätigkeit des Aufbauens bezieht. Der erste Fall ist zweifelsohne viel einfacher, denn hier geht es um syntaktische Richtigkeit und das sporadische Auftreten von solchen Schlüsselwörtern wie extends, implements, abstract oder interface. Der zweite Fall dagegen ist wesentlich schwieriger, denn hier geht es um den Einsatz und das Zusammenspiel der einzelnen neuen Schlüsselwörter zu einem neuen Ganzen, dessen Modulaufbau, Zukunftsfähigkeit und Erweiterbarkeit messbar besser sein muss als vorherige Systeme. Dabei soll jetzt an dieser Stelle nicht auf die einzelnen Schlagwörter oder gar das Messen derselben eingegangen werden, obschon sie für die Mittagspause immer wieder interessante Themen darstellen.

Als erste Antwort empfehle ich dann immer, nach einer allgemeinen Anforderungsanalyse mit Use Cases mit einem Schichtenmodell zu beginnen, um sich überhaupt klar zu werden, wie viele Schichten denkbar und notwendig sind und was in den einzelnen Schichten geschieht. Meistens kann man hier bereits durch diese einfache Sortierung mit weiteren Analysen fortfahren oder sogar Ergebnisse aus der Anforderungsanalyse unterbringen. Insbesondere die Präsentationsschicht aufgrund ihrer Sichtbarkeit und die Datenzugriffschicht aufgrund der Datenbankbedeutung erscheinen hier häufig als besonders dankbare Gebiete, die sich freudig beackern lassen.

Eine geschichtete Anwendung ist entweder nur in gedachte Schichten unterteilt oder besteht tatsächlich aus solchen physischen Schichten, die in Form von unterschiedlichen Servern oder wenigstens Ordnern organisiert ist. Grundsätzlich allerdings werden nur immer zwischen zwei Schichten Daten ausgetauscht, sodass vor allen Dingen die Präsentationsschicht mit all ihren HTML-Formularen, Tabellen, Listen und ähnlichen Darstellungstechniken niemals direkt auf die Datenbank zugreift, sondern alle ihre Daten von dieser Schicht erhält bzw. in einem Drei-Schicht-Modell wie in der Abbildung die notwendigen Daten und die Aufforderung eine entsprechende Sicht auf die Daten darzustellen, direkt aus der Geschäftslogik-Schicht stammen. Dies ermöglicht es, neue Sichten (Druckansicht, CSV-/XML-Darstellung, personalisierte Darstellungen gemäß Benutzervoreinstellungen) zu erzeugen, ohne auch jedes Mal neue Datenzugriffe zu programmieren.

In der Datenzugriffschicht befinden sich Klassen bzw. zum laufenden Betrieb natürlich Objekte, deren Aufgabengebiet daraus besteht, die tatsächliche Arbeit mit den Daten zu unterstützen. Dies betrifft sowohl das Abfragen (SELECT) von Daten als auch ihre Bearbeitung (INSERT, UPDATE, DELTE). Hier befinden sich also die gesamten SQL-Quelltexte, die oftmals in nicht geschichteten Anwendungen an den Stellen auftauchen, wo tatsächlich die Daten gerade benötigt werden. Diese Schicht liefert die Daten bspw. in Form von Objekten mit einer Tabellenzeile, als Arrays mit mehreren Objekten oder in reiner Array-Form (in PHP dank schwacher Typisierung besonders einfach zu programmieren) sowie auch in CSV- oder XML-Form an die Geschäftslogikschicht.

Die mittlere Schicht organisiert die gesamte Geschäftslogik, also sämtliche Aspekte, die direkt mit dem eigentlichen Auftrag und dem ursprünglichen Zweck der Software zu tun haben. Hier befinden sich solche typischen Bestandteile wie das Rechtemanagement, Umwandlungen und Berechnungen (sofern sie nicht bei Objekten untergebracht sind, die auch die Daten enthalten) sowie die Verarbeitung von Geschäftsregeln. Diese sind entweder nur in Form von Fallunterscheidungen oder – je nach Bedeutung der Regelungen – auch wieder in Form von XML- oder DB-Daten verfügbar, wenn sie selbst als Daten aufgefasst werden (Abrechnungs-, Validierungsregeln).

Muster der Geschäftslogik

Aufbau des Katalogs

Der Katalog umfasst über 30 Muster, von denen die meisten auch in PHP-Anwendungen umgesetzt werden können bzw. Probleme aus Anwendungen lösen, die mit PHP typischerweise erstellt werden. Einige wenige Muster für Sitzungszustände oder Nebenläufigkeit sind nur sehr schlecht bzw. gar nicht umzusetzen. Entweder unterstützt PHP die entsprechenden Voraussetzungen nicht oder es sind keine Muster für Webanwendungen. Damit nach der allgemeinen Einführung auch einige Muster vorgestellt werden, folgt nun eine Auswahl der eher einfachen Muster, mit denen man sich zu Anfang besonders gut beschäftigen kann, da sie keine umfangreiche Syntax erfordern und ihr Nutzen leicht vorstellbar ist.

Neben den verschiedenen Listen, die im Artikel verstreut sind, und die einige der häufigsten Muster enthalten, möchte ich einige wenige aus dem umfangreichen Schatz herausgreifen und vorstellen. Wie immer sollte dabei nicht der Eindruck entstehen, man würde bevormundet werden oder alles, was bislang programmiert wurde, sei nur deswegen nicht optimal, weil es keinem Muster folgt. Vielleicht folgt es auch tatsächlich einem Muster, was den Quelltext nicht besser macht als er ist, aber zeigt, dass die Muster tatsächlich universeller Natur sind. Auch darf nicht der Eindruck entstehen, mit einem Muster müsse die gesamte Anwendung aufgebaut werden. Es gibt überhaupt keine andere Regel als die, möglichst zielführend zu arbeiten und für die gesamte Software, die einzelne Komponente oder kleinere Einheiten einen guten Entwurf zu finden.

Beispiel für Basismuster: Registry

Einige Vorschläge sind nicht einer bestimmten Schicht zugeordnet, sondern gelten als Basismuster, da sie in anderen Mustern umgesetzt werden oder grundsätzlicher Natur sind. Das Registry-Muster setzt bspw. das Singleton-Muster aus dem Standardkatalog um und kann in PHP-Kreisen für Diskussionen sorgen, da mit den globalen Variablen für Sitzungsverwaltung und Parametern eine Art Registry bereits umgesetzt ist, die allerdings nicht objektorientiert funktioniert, sondern auf globalen Variablen basiert und nur für die bereits fertigen globalen Werte eine Lösung darstellt.

Das Muster schlägt vor, globale Werte, die es letztendlich in den meisten Anwendungen gibt, in Form eines Objekts zu speichern, das nur ein einziges Mal existiert und daher mit dem Singleton-Muster umgesetzt werden soll. Neben der Sitzungsverwaltung eignet sich auch immer wieder für das Speichern und Lesen von GET- und POST-Werten. Greift man konsequent immer auf die Request-Registry zu und weiß die Anwendung rein gar nichts von GET, POST oder gar Daten, die aus der Kommandozeilen stammen und werden diese Unterscheidungen nur in einem Request Resolver-Objekt erledigt, das bspw. in der Registry sitzt (nicht im Muster enthalten, aber denkbar für den praktischen Einsatz), so lässt sich eine einfache Array-Struktur mit get- und set-Methoden als Objekt in der Anwendung als zentraler Zugriffspunkt verwenden, welche die genauen Zugriffs-, Umwandlungs- und Speicherfunktionen verbirgt.

Der typische Nutzen für dieses einfache Muster entsteht bei Kundenfragen der Art „Können wir die Anwendung auf der Kommandozeile betreiben?“ oder „Können wir statt der Cookies doch lieber versteckte Felder verwenden?“. Die Registry kümmert sich um die Werte, welche von der Anwendung immer nur in der Registry gelesen oder geschrieben werden, sodass solche Änderungen tatsächlich einfach zu realisieren sind.

Datenzugriffsschicht

Data Mapper

Die Verwendung von Datenbanken stellt nur dann ein Problem dar, wenn die DB-Zugriffe im ganzen Quelltext verstreut sind und nicht einmal eine geschichtete Anwendung vorliegt. Mit solchen Fällen lässt sich immer wieder eine Menge Geld umsetzen, um Anwendungen für neue Datenbanken tauglich zu machen oder überhaupt mal eine saubere Schicht einzuziehen. Das heißt also, dass meine potenzielle Kunden sich am besten gar nicht erst mit dem Thema beschäftigen.

Der Data Mapper ist nur eines von sehr vielen Mustern für Architekturen und Verfahren, um Datenzugriffe zu realisieren. Die Erarbeitung einer komplexen Schicht von kapselnden Objekten ist immer ein großer Zeitaufwand, weswegen es für andere Programmiersprachen auch wiederum Softwareprodukte gibt, die mit der einen oder anderen Technik in Abhängigkeit von der Datenbank im zwei- oder dreistelligen Bereich Klassen generieren können.

Konkret schlägt dieses Muster vor, für den Datenzugriff pro Tabelle/Sicht/Prozedur eine Mapper-Klasse einzuführen. So kümmern sich die Objekte der Geschäftslogik wirklich ausschließlich um dieselben, während neben diesem Objektschema das relationale Schema getrennt erzeugt wird, wobei die Mapper-Objekte als Transferstation zwischen DB und Geschäftslogik stehen. Die Abfragen über find-Methoden können entweder auch im Mapper-Objekt oder sogar noch in einem eigenen Objekt platziert werden, da für gewöhnlich wesentlich mehr Such- als Bearbeitungsmöglichkeiten existieren.

Muster des Datenzugriffs

Präsentationsschicht

Page Controller

Mit diesem Muster lassen sich in beeindruckender Geschwindigkeit Webanwendungen mit einfacher Bedienungslogik aufbauen, die hauptsächlich Daten aus XML-Dateien oder einer Datenbank anzeigen und nur über wenige Hierarchieebenen verteilt sind. Wichtig ist, dass sich die Aktionen, die ein Benutzer auf einer solchen Seiten ausführen darf, in Form von Befehlen ausdrücken lassen und die gesamte Anwendung über diese Aktion auch definiert werden kann. Dabei ist nicht weiter notwendig, jede Sicht zu einer Aktion zu erheben, weil weiterhin die Möglichkeit besteht – und auch immer genutzt werden sollte – neben dem Aktionsnamen auch weitere (Aktions-)Parameter zu übergeben.

Die Aufgaben des PageControllers ergeben sich aus der Zerlegung der GET- und POST-Parameter, um die Aktionen zu erkennen und die für ihre Ausführung benötigten Daten bereitzuhalten, danach passenden Objekte aus der Geschäftslogik aufrufen und ihnen die Daten übergeben, schließlich dann eine passende Sicht auswählen, die für die Aktion und damit auch für die Geschäftslogik notwendig ist.

Muster der Präsentation

Comelio GmbH PHP: Enterprise Applications Muster - Design Patterns - Entwurfsmuster PHP Handbuch SQL XML Anleitung Tutorial LDAP MySQL SQLJ -Comelio GmbH PHP: Enterprise Applications Muster - Design Patterns - Entwurfsmuster PHP Handbuch SQL XML Anleitung Tutorial LDAP MySQL SQLJ -Comelio GmbH PHP: Enterprise Applications Muster - Design Patterns - Entwurfsmuster PHP Handbuch SQL XML Anleitung Tutorial LDAP MySQL SQLJ -Comelio GmbH PHP: Enterprise Applications Muster - Design Patterns - Entwurfsmuster PHP Handbuch SQL XML Anleitung Tutorial LDAP MySQL SQLJ -Comelio GmbH PHP: Enterprise Applications Muster - Design Patterns - Entwurfsmuster PHP Handbuch SQL XML Anleitung Tutorial LDAP MySQL SQLJ -Comelio GmbH PHP: Enterprise Applications Muster - Design Patterns - Entwurfsmuster PHP Handbuch SQL XML Anleitung Tutorial LDAP MySQL SQLJ -Comelio GmbH PHP: Enterprise Applications Muster - Design Patterns - Entwurfsmuster PHP Handbuch SQL XML Anleitung Tutorial LDAP MySQL SQLJ -Comelio GmbH PHP: Enterprise Applications Muster - Design Patterns - Entwurfsmuster PHP Handbuch SQL XML Anleitung Tutorial LDAP MySQL SQLJ -Comelio GmbH PHP: Enterprise Applications Muster - Design Patterns - Entwurfsmuster PHP Handbuch SQL XML Anleitung Tutorial LDAP MySQL SQLJ -

Enterprise Muster

Kontakt

Muster für PHP-Enterprise-Anwendungen