PHP-MVC-Frameworks. Web Application Frameworks für die serverseitige Scriptsprache PHP

INHALTSVERZEICHNIS

ERKLÄRUNG ZUR SPRACHLICHEN GLEICHSTELLUNG VON FRAUEN UND MÄNNERN

INHALTSVERZEICHNIS

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS

LISTINGVERZEICHNIS

ABKÜRZUNGSVERZEICHNIS

DANKSAGUNG

ABSTRACT

KURZFASSUNG

1 EINFÜHRUNG
1.1 Motivation
1.2 Relevanz der Arbeit
1.3 Aufbau der Arbeit

2 FRAMEWORKS
2.1 Definition
2.2 Klassifizierung
2.3 Stärken und Schwächen
2.4 Web Application Frameworks
2.5 Zusammenfassung

3 SOFTWARE-PATTERNS
3.1 Definition
3.2 Architektur-Patterns für Web-Präsentationen
3.2.1 Das MVC-Konzept
3.2.2 View-Patterns
3.2.3 Input-Controller-Patterns
3.3 Architektur-Patterns der Domänenlogik
3.3.1 Transaction-Script
3.3.2 Domain-Model
3.3.3 Table-Module
3.4 Architektur-Patterns für Datenquellen
3.4.1 Row-Data-Gateway
3.4.2 Table-Data-Gateway
3.4.3 Active-Record
3.4.4 Data-Mapper
3.5 Zusammenfassung

4 DEFINITIONEN FÜR DIE EVALUIERUNG
4.1 Methodik
4.2 Auswahl der PHP-MVC-Frameworks
4.3 Evaluierungskriterien
4.3.1 Funktionale Abdeckung
4.3.2 Risiken aus Sicht des Anwenders
4.3.3 Risiken aus Sicht des Serviceproviders
4.3.4 Kriterienkatalog
4.4 Praktisches Beispiel
4.4.1 Webseiten
4.4.2 Verwendete Funktionen und Kriterien
4.4.3 ER-Diagramm
4.5 Zusammenfassung

5 EVALUIERUNG
5.1 CakePHP
5.1.1 ID-Card
5.1.2 Funktionale Abdeckung
5.1.3 Risiken aus Sicht des Anwenders
5.1.4 Risiken aus Sicht des Serviceproviders
5.1.5 Evaluation-Sheet
5.2 Symfony
5.2.1 ID-Card
5.2.2 Funktionale Abdeckung
5.2.3 Risiken aus Sicht des Anwenders
5.2.4 Risiken aus Sicht des Serviceproviders
5.2.5 Evaluation Sheet
5.3 Zend Framework
5.3.1 ID-Card
5.3.2 Funktionale Abdeckung
5.3.3 Risiken aus Sicht des Anwenders
5.3.4 Risiken aus Sicht des Serviceproviders
5.3.5 Evaluation Sheet
5.4 Zusammenfassung

6 QUALIFIKATION UND SELEKTION
6.1 Qualifikation
6.2 Selektion des Frameworks
6.2.1 Selection-Grid
6.2.2 Ergebnis
6.3 Zusammenfassung

7 ZUSAMMENFASSUNG UND AUSBLICK
7.1 Zusammenfassung
7.2 Ausblick

ANHANG

LITERATURVERZEICHNIS

ABBILDUNGSVERZEICHNIS

Abbildung 1-1: Einführung Aufbau der Arbeit

Abbildung 2-1: Frameworks Klassifizierung nach Anwendungsbereich

Abbildung 2-2: Frameworks Klassifizierung nach Erweiterungstechnik

Abbildung 3-1: SW-Patterns Ablauf MVC-Konzept am Webserver

Abbildung 3-2: SW-Patterns Template-View

Abbildung 3-3: SW-Patterns Transform-View

Abbildung 3-4: SW-Patterns Two-Step-View

Abbildung 3-5: SW-Patterns Funktionsweise eines Front-Controllers

Abbildung 3-6: SW-Patterns Transaction-Script

Abbildung 3-7: SW-Patterns Domain-Model

Abbildung 3-8: SW-Patterns Table-Module

Abbildung 3-9: SW-Patterns Row-Data-Gateway

Abbildung 3-10: SW-Patterns Table-Data-Gateway

Abbildung 3-11: SW-Patterns Active-Record

Abbildung 3-12: SW-Patterns Data-Mapper

Abbildung 3-13: SW-Patterns Zusammenfassung

Abbildung 4-1: Definition The Big List of PHP Frameworks

Abbildung 4-2: Definition QSOS-Methode, Stufe I

Abbildung 4-3: Definition Verbreitungsgrad PHP-MVC-Frameworks

Abbildung 4-4: Definition Praktisches Beispiel, Kontaktformular

Abbildung 4-5: Definition Praktisches Beispiel, Anmeldeformular

Abbildung 4-6: Definition Praktisches Beispiel, Kontaktverwaltung

Abbildung 4-7: Definition Praktisches Beispiel, Bearbeitungsfunktionen

Abbildung 4-8: Definition Praktisches Beispiel, ER-Diagramm

Abbildung 4-9: Evaluierung QSOS-Methode, Stufe II

Abbildung 5-1: Evaluierung CakePHP Logo

Abbildung 5-2: Evaluierung CakePHP, Funktionale Abdeckung

Abbildung 5-3: Evaluierung CakePHP, Risiken aus Sicht des Anwenders

Abbildung 5-4: Evaluierung CakePHP, Risiken aus Sicht des Providers

Abbildung 5-5: Evaluierung Offizielles Symfony Logo

Abbildung 5-6: Evaluierung Symfony, ORM-Prinzip

Abbildung 5-7: Evaluierung Symfony, Debugging-Toolbar

Abbildung 5-8: Evaluierung Symfony, Funktionale Abdeckung

Abbildung 5-9: Evaluierung Symfony, Risiken aus Sicht des Anwenders

Abbildung 5-10: Evaluierung Symfony, Risiken aus Sicht des Providers

Abbildung 5-11: Evaluierung Offizielles Zend Framework Logo

Abbildung 5-12: Evaluierung Zend Framework, Funktionale Abdeckung

Abbildung 5-13: Evaluierung Zend Framework, Risiken aus Sicht des Anwenders

Abbildung 5-14: Evaluierung Zend Framework, Risiken aus Sicht des Providers

Abbildung 6-1: Qualifikation QSOS-Methode, Stufe III

Abbildung 6-2: Selektion QSOS-Methode, Stufe IV

TABELLENVERZEICHNIS

Tabelle 2-1: Frameworks Stärken versus Herausforderungen

Tabelle 4-1: Definition Hauptkriterium 1.1, Model

Tabelle 4-2: Definition Hauptkriterium 1.2, View

Tabelle 4-3: Definition Hauptkriterium 1.3, Controller

Tabelle 4-4: Definition Hauptkriterium 1.4, Formular-Handling

Tabelle 4-5: Definition Hauptkriterium 1.5, Datenbindung

Tabelle 4-6: Definition Hauptkriterium 1.6, Internationalisierung

Tabelle 4-7: Definition Hauptkriterium 1.7, Komponenten

Tabelle 4-8: Definition Hauptkriterium 2.1, Einsatz

Tabelle 4-9: Definition Hauptkriterium 2.2, Integrationsfähigkeit

Tabelle 4-10: Definition Hauptkriterium 2.3, Benchmarking

Tabelle 4-11: Definition Hauptkriterium 3.1, Wartung

Tabelle 4-12: Definition Hauptkriterium 3.2, Strategie

Tabelle 4-13: Definition Kriterienkatalog

Tabelle 5-1: Evaluierung CakePHP, ID-Card

Tabelle 5-2: Evaluierung CakePHP, Bücherangebot

Tabelle 5-3: Evaluierung CakePHP, Benchmarking - Verfügbarkeit

Tabelle 5-4: Evaluierung CakePHP, Benchmarking - Performance

Tabelle 5-5: Evaluierung CakePHP, Benchmarking - Concurrency

Tabelle 5-6: Evaluierung CakePHP, Evaluation-Sheet

Tabelle 5-7: Evaluierung Symfony, ID-Card

Tabelle 5-8: Evaluierung Symfony, Bücherangebot

Tabelle 5-9: Evaluierung Symfony, Benchmarking - Verfügbarkeit

Tabelle 5-10: Evaluierung Symfony, Benchmarking - Performance

Tabelle 5-11: Evaluierung Symfony, Benchmarking - Concurrency

Tabelle 5-12: Evaluierung Symfony, Evaluation-Sheet

Tabelle 5-13: Evaluierung Zend Framework, ID-Card

Tabelle 5-14: Evaluierung Zend Framework, Paging-Optionen

Tabelle 5-15: Evaluierung Zend Framework, Bücherangebot

Tabelle 5-16: Evaluierung Zend Framework, Benchmarking - Verfügbarkeit

Tabelle 5-17: Evaluierung Zend Framework, Benchmarking - Performance

Tabelle 5-18: Evaluierung Zend Framework, Benchmarking - Concurrency

Tabelle 5-19: Evaluierung Zend Framework, Evaluation-Sheet

Tabelle 6-1: Qualifikation Gewichtungsschema

Tabelle 6-2: Selektion Gewichtungsfaktor

Tabelle 6-3: Selektion Selection-Grid

LISTINGVERZEICHNIS

Listing 5-1: Evaluierung CakePHP, Paginator im Controller

Listing 5-2: Evaluierung CakePHP, Paginator in der View

Listing 5-3: Evaluierung Symfony, Datenbankkonfiguration für Propel

Listing 5-4: Evaluierung Symfony, Paging im Controller

Listing 5-5: Evaluierung Symfony, Paging in der View

Listing A-1: Anhang Variante ohne Framework, Datenbank

Listing A-2: Anhang Variante ohne Framework, Geschäftslogik

Listing A-3: Anhang Variante ohne Framework, Präsentation

Listing A-4: Anhang Variante mit CakePHP, Model

Listing A-5: Anhang Variante mit CakePHP, Layout

Listing A-6: Anhang Variante mit CakePHP, View

Listing A-7: Anhang Variante mit CakePHP, Controller

Listing A-8: Anhang Variante mit Symfony, Schema für Model

Listing A-9: Anhang Variante mit Symfony, Basisformular

Listing A-10: Anhang Variante mit Symfony, Layout

Listing A-11: Anhang Variante mit Symfony, View für Formular

Listing A-12: Anhang Variante mit Symfony, View für Action

Listing A-13: Anhang Variante mit Symfony, Controller

Listing A-14: Anhang Variante mit Zend Framework, Model

Listing A-15: Anhang Variante mit Zend Framework, Formular

Listing A-16: Anhang Variante mit Zend Framework, Layout

Listing A-17: Anhang Variante mit Zend Framework, View für Action

Listing A-18: Anhang Variante mit Zend Framework, Controller

ABKÜRZUNGSVERZEICHNIS

Abbildung in dieser Leseprobe nicht enthalten

DANKSAGUNG

An dieser Stelle möchte ich mich bei all jenen bedanken, die mich bei der vorliegenden Diplomarbeit sowie bei dem vorausgegangenen Studium tatkräftig unterstützt haben.

Im Besonderen gilt meine Danksagung meiner Partnerin, die mit ihrer einzig- artigen Geduld bewiesen hat, dass hinter jedem erfolgreichen Mann eine noch erfolgreichere Frau steht. Sowie meiner gesamten Familie und Freunden, die während des Studiums und des Erstellens der Diplomarbeit stets Verständnis dafür aufbrachten, das ich an dem einen oder anderen Tag keine Zeit für sie hatte.

Des Weiteren möchte ich mich bei meinem Betreuer der Fachhochschule, FH-Prof. DI Dr. Franz Niederl bedanken, der mich in allen Belangen während der Erstellung dieser Arbeit stets unterstützt hat. Auch dem Unternehmen MOTIONDATA Software GmbH möchte ich den Dank für die Unterstützung und Zusammenarbeit aussprechen, ohne die ein berufsbegleitendes Studium dieser Art nicht möglich gewesen wäre.

Jürgen Kargl

Ehrenhausen, 05.06.2009

ABSTRACT

Web application frameworks represent a special kind of reuse-technique for software which can offer the following advantages: Reduction of development effort and its costs as well as increase of quality of the applications deve- loped with it. The first part of this diploma thesis is about the theoretical prin- ciples for frameworks and software patterns to provide a base for the second, practical part - the evaluation of MVC-Frameworks for the production of web applications in the script-language PHP. The objective was to determine the most suitable PHP-MVC-framework for the Internet Solutions Department of the MOTIONDATA Software GmbH. As an approach, an evaluation was selected, which was done by the QSOS-method. This iterative method contains four steps: (1) The definition, (2) the evaluation, (3) the qualification and (4) the selection of the framework. Concerning the variety of licence-free PHP-MVC-frameworks whose complete evaluation would go far beyond the scope of this thesis, a pre-selection was made by analysing the diffusion rate of the frameworks. Therefore CakePHP, Symfony and Zend Framework were chosen for the evaluation. Next a criteria catalogue was defined which consists of three categories: (1) Functional coverage, (2) risks from the user's perspective and (3) risks from the service provider's perspective. Based on this criteria catalogue the evaluation was carried out. Afterwards follows the qualification by weighting the criteria to make a choice of the most suitable framework. The final part of this thesis sums up the gained results and gives a prospect of introducing the selected framework. In the appendix, extracts of source code from a practical example were added, which include the three frameworks and the present implementation-variant of the Internet Solutions Department as a comparison.

KURZFASSUNG

Web Application Frameworks stellen eine besondere Form der Wiederver- wendung von Software dar, die folgende Vorteile bieten kann: Verringerung des Entwicklungsaufwands und -kosten, als auch Erhöhung von Qualität der damit entwickelten Anwendungen. Im ersten Teil dieser Arbeit werden zu- nächst theoretische Grundlagen für Frameworks und Software-Patterns betrachtet, um die Basis für den zweiten, praktischen Teil - der Evaluierung von MVC-Frameworks für die Erstellung von Webanwendungen in der Skript- sprache PHP zu schaffen. Die Zielsetzung bestand darin, dass am besten geeignete PHP-MVC-Framework für die Internet Solutions Abteilung der MOTIONDATA Software GmbH zu bestimmen. Als Vorgehensweise wurde eine Evaluierung anhand der QSOS-Methode gewählt. Diese iterative Metho- de besteht aus vier Stufen: (1) Der Definition, (2) der Evaluierung, (3) der Qualifikation und (4) der Auswahl des Frameworks. Es existiert eine Vielzahl an lizenzkostenfreien PHP-MVC-Frameworks, deren gesamte Evaluierung den Rahmen dieser Arbeit sprengen würde, daher wurde eine Vorauswahl mittels einer Analyse des Verbreitungsgrades der Frameworks getroffen. Daraus resultierend wurden CakePHP, Symfony und das Zend Framework für die Evaluierung ausgewählt. Als nächstes wurde ein Kriterienkatalog fest- gelegt, der aus drei Kategorien besteht: (1) Funktionale Abdeckung, (2) Risiken aus Sicht des Anwenders und aus (3) Sicht des Providers. Auf Basis des Kriterienkatalogs wird die Evaluierung durchgeführt. Danach folgt die Qualifikation durch Gewichtung der Kriterien, um so die Auswahl des geeig- neten Frameworks zu ermöglichen. Im Schlussteil der Arbeit werden die gewonnen Erkenntnisse zusammengefasst und ein Ausblick über die Ein- führung des gewählten Frameworks gegeben. Im Anhang der Arbeit sind Quellcodeauszüge eines praktischen Beispiels beigefügt, welche die drei Frameworks und die derzeitige Umsetzungsvariante der Internet Solutions Abteilung als Vergleich umfassen.

1 EINFÜHRUNG

1.1 Motivation

Die Internet Solutions Abteilung¹ der MOTIONDATA Software GmbH² bietet seit zehn Jahren Dienstleistungen und Entwicklungen im E-Business-Bereich an. Dabei kommt als Entwicklungsumgebung ein LAMP-System (Linux, Apache, MySQL, PHP) zum Einsatz. Das ganze Know-How der Abteilung und zahlreiche Projekte von Bestandskunden basieren auf dieser Umset- zungsvariante. Der stetige Anstieg der Anforderungen an die Entwicklung von Webanwendungen in Bezug auf bestimmte Kriterien ist dabei nicht außer Acht zu lassen. Die Entwicklung soll möglichst flexibel und effizient, sowie mit guter Qualität durchgeführt werden. Webanwendungen stehen sehr oft wie- derkehrenden Problemstellungen gegenüber. Code-Wiederverwendung ist daher eine wichtige Maßnahme, um die Programmierung effizienter gestalten zu können. Frameworks können den Entwicklungsprozess durch Wiederver- wendung und strukturierte Vorgehensweise bei der Entwicklung verbessern. Für die Scriptsprache PHP wird eine Vielzahl von Frameworks angeboten, die auf unterschiedlichste Arten die Programmierung vereinfachen sollen. In der Internet Solutions Abteilung soll nun ein Framework zur Anwendung kommen, um durch Wiederverwendung von Software den Entwicklungspro- zess zu optimieren.

1.2 Relevanz der Arbeit

Aus der eben geschilderten Ausgangslage ergeben sich drei Fragen, die im Rahmen dieser Arbeit relevant sind:

- Welches dieser Frameworks soll zum Einsatz kommen?
- Welche Funktionen soll das zukünftige Framework abdecken?
- Worauf ist bei einem Einsatz des zukünftigen Frameworks zu achten?

Eine Evaluierung von PHP-Frameworks soll erfolgen, um einerseits deren Funktionalität zu erheben und andererseits die Auswahl des am besten geeigneten Frameworks zu ermöglichen. Folgende Rahmenbedingungen wurden durch das Unternehmen vorgegeben:

- Framework läuft auf LAMP-Serverumgebung
- Architektur des Frameworks basiert auf dem MVC-Konzept
- Framework ist lizenzkostenfrei
- Geeignete Entwicklungswerkzeuge für Windows-Clients
- Support und Ausbildungsangebot für die Anwender des Frameworks

1.3 Aufbau der Arbeit

Kapitel I: Einführung In diesem Kapitel werden die Motivation, die Relevanz und der Aufbau dieser Arbeit vorgestellt.

Kapitel II: Frameworks Das zweite Kapitel ist eine theoretische

Betrachtung von Frameworks, wobei die Definition, die Klassifizierung und die Beschreibung von Stärken und Schwächen von Frameworks erfolgen. Abschließend wird im Speziellen auf Web Application Frameworks eingegangen.

Kapitel III: Software-Patterns Im zweiten theoretischen Teil werden

Software-Patterns beschrieben, indem deren Definition und Architektur-Patterns für Webpräsentationen, Domänenlogik, sowie für Datenquellen vorgestellt werden.

Kapitel IV: Definitionen für die Evaluierung In diesem Kapitel wird mit dem praktischen Teil der Arbeit begonnen. Die für die Evalu- ierung angewandte Methode QSOS³ wird vorgestellt. Danach erfolgen die Vorauswahl der Frameworks anhand einer Verbreitungsanalyse und die Definitionen für die Evaluierung (Stufe I der Methode).

Kapitel V Evaluierung der Frameworks Im Kapitel fünf wird die

zweite Stufe der Methode abgehandelt - die Evaluierung der vorselektierten Frameworks (Stufe II).

Kapitel VI Qualifikation und Auswahl des Frameworks In diesem

Kapitel wird die Qualifikation (Stufe III) und Auswahl des Frameworks für die Abteilung (Stufe IV) durchgeführt.

Kapitel VII Zusammenfassung und Ausblick Als abschließendes

Kapitel werden die gewonnenen Erkenntnisse der Arbeit zusammengefasst und ein Ausblick über die Einführung des ausgewählten Frameworks gegeben.

Anhang: Hier werden Quellcodeauszüge der evaluierten Frameworks und zum Vergleich die derzeitige Entwicklungsvariante anhand des unter Kapitel IV definierten praktischen Beispiels beigefügt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1-1: Einführung Aufbau der Arbeit

2 FRAMEWORKS

Das folgende Kapitel befasst sich mit Application Frameworks, deren Klassi- fizierung, sowie deren Stärken und Schwächen. Zusätzlich wird auf Web Application Frameworks eingegangen, da PHP-Frameworks zu dieser Kate- gorie zählen.

2.1 Definition

Unter Application Frameworks, nachfolgend kurz als Frameworks bezeichnet, versteht man allgemeine, im Speziellen objektorientierte Techniken zur Wiederverwendung. In der Literatur werden Frameworks vielfältig beschrieben. Fayad, Schmidt, Johnson führen in ihrem Buch „Building Application Frameworks“ im Jahr 1999 zwei Definitionen an, die ihrer Meinung nach oft verwendet werden und auch den Umstand aufzeigen sollen, dass eine klare Definition für Frameworks nur schwer möglich ist:

- „A framework is a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact“ (Fayad et al. 1999, S. 3 f),
- „A framework is the skeleton of an application that can be customized by an application developer” (ebd.).

Diese Definitionen stehen nicht im Widerspruch, ganz im Gegenteil - die erste beschreibt die Struktur eines Frameworks, wobei die zweite dessen Zweck zum Ausdruck bringt (vgl. ebd.).

Für diese Arbeit wird folgende Definition für den Begriff Framework getroffen:

Frameworks sind ein abstraktes Design zur Erstellung von spezifischen Anwendungen und stellen eine bestimmte Anzahl von Klassen bereit, die wiederverwendet werden können (vgl. Johnson, Foote 1988, S. 10 f).

Nach der Beschreibung des Begriffs Application Framework folgt nun die Klassifizierung der Frameworks.

2.2 Klassifizierung

-bwohl die Vorteile und Design-Prinzipien, die den Frameworks zugrunde liegen sehr von deren Einsatzgebiet abhängig sind, treffen Fayad et al. folgende Unterscheidung in drei Anwendungsbereiche:

- System Infrastructure Frameworks vereinfachen die Entwicklung von portablen und effizienten System-Infrastrukturen, wie zum Beispiel Betriebssystemen, Frameworks zur Kommunikation und für User-Inter- faces, sowie zur Sprachverarbeitung. Diese werden ausschließlich für interne Zwecke einer Software-Organisation verwendet und nicht direkt an Kunden verkauft.

- Middleware Integration Frameworks dienen im Allgemeinen zur Integration von verteilten Anwendungen (Distributed Applications) und Komponenten - im Konkreten bedeutet dies Unterstützung für Entwick- ler bei der Modularisierung, Wiederverwendung und Erweiterbarkeit ihrer Software-Infrastruktur, um nahtlos in verteilten Anwendungen ar- beiten zu können.

- Enterprise Application Frameworks kommen bei Branchen, wie der Telekommunikation, Luftfahrt, Fertigungsindustrie oder Banken zum Einsatz. Ein Beispiel hierfür wären sogenannte ERP-Software-Systeme.

In Relation zu den anderen Anwendungsbereichen von Frameworks ist die Anschaffung und Entwicklung sehr teuer, jedoch wird der Einsatz von solchen Frameworks durch den Umstand, dass diese EndbenutzerAnwendungen und Produkte direkt unterstützen (laufendes Return on Investment, ROI), gerechtfertigt (vgl. ebd., S. 9 f).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1: Frameworks Klassifizierung nach Anwendungsbereich Quelle: vgl. Fayad, Johnson 1999, S. 617

Eine weitere Klassifizierung kann aufgrund der eingesetzten Techniken zur Erweiterung der Frameworks getroffen werden (vgl. Fayad et al. 1999, S. 10):

- Whitebox-Frameworks beruhen sehr stark auf objektorientierten (OO)

Funktionen, wie etwa Vererbung und dynamisches Binden (Dynamic Binding), um Erweiterbarkeit zu erreichen. Die bestehende Funk- tionalität wird durch (1) Vererbung von Framework-Klassen und (2) dem Überschreiben von vordefinierten Hook-Methoden mittels Gebrauch von Patterns (zum Beispiel Template-Method) wiederverwendet bzw. erweitert (vgl. Gamma, Helm, Johnson, Vlissides 1995, S. 19 ff).

- Blackbox-Frameworks unterstützen die Erweiterbarkeit durch Schnitt- stellendefinition für Komponenten, die dann während der Laufzeit in das Framework eingefügt werden können (Plugins mittels Composition). Die bestehende Funktionalität wird hierbei anders als bei Whitebox-Frame- works durch (1) Definition von Komponenten, die auf speziellen Schnittstellen beruhen und (2) Integration der Komponenten in das Framework wiederverwendet bzw. erweitert (vgl. ebd.).

- Graybox-Frameworks stellen eine Mischform der beiden oben angeführten Frameworks dar und sollen deren Nachteile minimieren. Ein Graybox-Framework besitzt hohe Flexibilität und Erweiterbarkeit trotz Verbergung von Informationen vor dem Anwendungsentwickler (vgl. Fayad, Johnson 1999, S. 618 f).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2: Frameworks Klassifizierung nach Erweiterungstechnik Quelle: vgl. ebd.

2.3 Stärken und Schwächen

Die primären Stärken von Frameworks liegen in der Modularität, Wiederverwendbarkeit, Erweiterbarkeit und Anwendung von Inversion of Control. Diese lassen sich wie folgt beschreiben:

- Modularität (Modularity): Frameworks erzielen Modularität durch Trennung änderbarer Details der Implementierung hinter stabilen Schnittstellen. Diese Abstraktion hilft, die Software-Qualität zu steigern, da etwaige Änderungen am Entwurf oder an der Implementierung ein- fach zu lokalisieren sind. Der Aufwand für das Erlernen und Warten der bestehenden Software kann dadurch gering gehalten werden.

- Wiederverwendbarkeit (Reusability): Die oben angeführten stabilen

Schnittstellen ermöglichen Wiederverwendbarkeit durch Definition von generischen Komponenten, welche für neue Anwendungen abermalig benützt werden können. Für die Anwender des Frameworks entfällt infolgedessen der Erstellungsaufwand. Zusätzlich profitieren sie vom zugrundeliegenden Spezialwissen der Komponenten-Entwickler. Damit wird eine Steigerung der Qualität, Performanz, Zuverlässigkeit und Interoperabilität der Software erzielt.

- Erweiterbarkeit (Extensibility): Frameworks stellen sogenannte HookMethoden (abstrakte Methoden, die überschrieben werden können) zur Verfügung, die es erlauben, Anwendungen trotz deren stabilen Schnittstellen zu erweitern. Durch diese Entkoppelung können Applikationen effizient und flexibel erweitert werden.

- Inversion of Control (IOC): Die Laufzeit Architektur eines Frameworks

ist gekennzeichnet durch eine IOC. Mit IOC können vorgegebene Ver- arbeitungsschritte an eigene Bedürfnisse angepasst werden, indem Objekte für das Event-Handling über die Mechanismen der Ablauf- steuerung (Dispatching) aufgerufen werden. Wenn ein bestimmtes Ereignis (Event) eintritt, reagiert der Dispatcher des Frameworks und ruft die vorregistrierte anwendungsspezifische Hook-Methode auf (vgl. Fayad et al. 1999, S. 8 f).

Neben den eben angeführten Stärken von Frameworks besitzen diese auch Schwächen, die bei einem effektiven Einsatz von größeren Frameworks eine tragende Rolle spielen können. Das stellt Entwickler und Anwender des Frameworks vor bestimmte Herausforderungen, die im Vorfeld berücksichtigt werden sollten (siehe nächste Seite):

- Entwicklungsaufwand: Die Entwicklung komplexer Anwendungen ist oftsehr aufwändig. Die Entwicklung von hochwertigen, wieder verwendbaren Frameworks für komplexe Anwendungsbereiche ist aber noch viel mühsamer. Das dafür notwendige Wissen ist sehr oft ausschließlich in den Köpfen der Experten, die diese Frameworks entwickeln, isoliert. Herausforderung: Das Wissen über den Softwareprozess und die Design-Prin- zipien im Zusammenhang mit der Entwicklung und Anwendung des Frameworks muss ausführlich dokumentiert sein.

- Lernkurve: Das Erlernen von Frameworks bedeutet einen gewissen Zeitaufwand. Daher dauert es meistens sehr lange, eine hohe Produktivität bei der Anwendung von Frameworks zu erzielen. Das hängt von den Vor- kenntnissen des Anwenders und von der Komplexität des Frameworks ab. Herausforderung: Die Lernkurve der Anwender kann durch Schulun- gen und direkte Betreuung (Support) durch die Entwickler bzw. Hersteller des Frameworks verkürzt werden. Es gilt, die Kosten hierfür dem resul- tierenden Nutzen durch Anwendung des Frameworks gegenüberzustel- len.

- Integrationsfähigkeit (Integratability): Frameworks müssen zumeist mit

Altsystemen (Legacy Systems), Komponenten, Klassen-Bibliotheken, Datenbanken oder auch anderen Frameworks kompatibel sein. Viele der älteren Frameworks haben sich nur auf die interne Integration konzentriert, jedoch die externe vernachlässigt. Herausforderung: Eine Überprüfung, ob die Integrationsfähigkeit des Frameworks für bestehende als auch zukünftige Anforderungen gegeben ist, sollte erfolgen.

- Wartbarkeit (Maintainability): Die Anforderungen an Programmen ändern sich laufend, was mit sich bringt, dass auch die Anforderungen an Frameworks ständig variieren. Dabei kann zwischen funktionalen (zum Beispiel Komponenten) und nicht funktionalen Änderungen (zum Beispiel Qualitätsaspekte) unterschieden werden. Beide erfordern ein tieferes Verständnis des Frameworks, um es auf die neuen Bedürfnisse anpassen zu können. Herausforderung: Die Anpassung an bestehende und zukünftige Anforderungen sollte entweder direkt, oder durch die Entwickler des Frameworks möglich sein.

- Validierung und Fehlerkorrektur: Obwohl ein modulares Framework mit gutem Design die Auswirkung von Softwarefehlern eingrenzt, kann die Validierung und Fehlersuche (Debugging) in damit erstellter Software sehr trickreich sein. Herausforderung:

- Schwierige Validierung durch Abstraktion der generischen Komponenten kompliziertes Testen von Objekten, da diese von dessen Instanzierungen abgekapselt sind.

- IOC und Mangel an explizitem Kontrollfluss kompliziertes Testen durch ständig wechselnde Methodenaufrufe zwischen Kontrollfluss der Anwendung und des Frameworks.

- Effizienz: Frameworks begünstigen Erweiterbarkeit auf Kosten der Effizienz durch Einführung zusätzlicher Indirektionsschichten (zum Beispiel Dynamic Binding). Bei Programmiersprachen wie C++ und Java führt diese Flexibilität zum Verlust von konkreten Datentypen (Concrete Data Types, CDTs), welche besonders bei zeitkritischer Software gefordert werden. Herausforderung: Der Mangel an CDTs führt (1) zum Ansteigen des Speicherbedarfs (zum Beispiel Zeiger auf virtuelle Tabellen), (2) zum Abbau der Performance (zum Beispiel Overhead durch Aufruf einer dynamisch gebunden Methode) und (3) zu Einbußen bei der Flexibilität (zum Beispiel die Unfähigkeit, Objekte im verteilten Speicher zu plat- zieren). Bei besonders zeitkritischen Anwendungen sollte dieser Umstand beachtet werden.

- Mangel an Standards: Derzeit existieren keine weitverbreiteten Standards für das Entwerfen, Implementieren, Dokumentieren und Anpassen von Frameworks. Außerdem bieten Standards für die Industrie (zum Bei- spiel CORBA, DCOM oder Java RMI) nicht die übergreifende Bedeutung, Funktion und Integrationsfähigkeit, um diese in anderen Anwendungsbe- reichen einsetzen zu können. Herausforderung: Eine Kooperation mit -rganisationen und Middleware-Herstellern, die die geforderte Integrationsfähigkeit und Funktionalität der Anwender des Frameworks gewährleisten können, sollte angestrebt werden (vgl. ebd., S. 11 ff).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-1: Frameworks Stärken versus Herausforderungen

2.4 Web Application Frameworks

Web Application Frameworks stellen eine Sammlung von Software-Kompo- nenten dar, die zur Unterstützung für die Entwicklung und Ausführung von webbasierten Benutzerschnittstellen (Web-based User Interfaces, WUIs) dienen. Dabei werden diese nach der Art der Ausführung in zwei Bereiche getrennt:

- Serverseitige Ausführung: Scriptsprachen wie ASP.NET, ColdFusion, JSP, Perl oder PHP werden nicht direkt an den Client (Browser), sondern an den Interpreter der Sprache ausgeliefert. Der Interpreter verarbeitet die Anweisungen und liefert textbasierte Formate (zum Beispiel HTML, XML, PDFs) an den Client aus.

- Clientseitige Ausführung: Im Gegensatz zum oben erwähnten Ansatz wird hier clientseitig, sprich am Browser, agiert. Scriptsprachen wie Javascript, Ajax, VBScript oder ActionScript werden am Client ausgeführt, um statischen Inhalt durch Funktionen und Anzeigeeffekte (DHTML) zu erweitern (vgl. Vosloo, Kourie 2008, S. 1 f).

PHP-Frameworks fallen in den Anwendungsbereich der serverseitigen Ausführung, wobei die Integration von clientseitiger Unterstützung von Javascript und Ajax möglich sein sollte.

Exkurs: Ajax

Der Name Ajax stammt von Jesse James Garrett von der amerikanischen Webagentur Adaptive Path. „Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s possible on the Web“ (Garrett 2005, Ajax: A New Approach to Web Applications). Bei Ajax werden Daten via Webbrowser vom Webserver angefordert, die in Form eines XML- Dokuments vom Server rückgeliefert werden. Mittels Javascript wird der Inhalt des Dokuments ausgewertet und dynamisch in das HTML-Dokument eingefügt. Somit können einzelne Teile, anstatt die gesamte Webseite aktu- alisiert werden. Die Benutzerfreundlichkeit wird durch Anzeigeeffekte und vor allem durch die Geschwindigkeitssteigerung positiv beeinflusst (vgl. Seeboer- ger-Weichselbaum 2007, S. 9 ff).

2.5 Zusammenfassung

Frameworks sind Rahmenwerke, mit denen eine wiederholbare Erstellung spezieller Anwendungen unterstützt wird. Sie können nach deren Anwen- dungsbereichen, sowie nach der Technik der Wiederverwendung klassifiziert werden. Neben ihren klaren Stärken gibt es auch gewisse Schwächen, die eine Herausforderung für die Anwender und Entwickler des Frameworks bedeuten. Eine besondere Form stellen Frameworks für Webanwendungen dar. Diese können entweder server- oder clientseitig ausgeführt werden, wobei PHP-Frameworks in die Kategorie der serverseitigen Web Application Frameworks fallen.

3 SOFTWARE-PATTERNS

Das folgende Kapitel befasst sich mit dem Begriff Software-Pattern. Speziell wird auf Architektur-Patterns für Web-Präsentationen, der Domänenlogik und für Datenquellen eingegangen, welche bei den evaluierten PHP-Frameworks (Kapitel 5) teilweise zur Anwendung kommen.

3.1 Definition

Alexander Christopher traf in seinem Buch „A Pattern Language“ folgende Aussage über Patterns, die im Zusammenhang mit dem Bau von Städten und Gebäuden getätigt wurde:

„Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice“ (Christopher et al. 1977, A Pattern Language) Diese Definition trifft ebenfalls auf Software-Patterns für Design und Architektur zu, nur dass es sich hierbei nicht um Bestandteile wie Türen und Wänden handelt, sondern um Objekte und Schnittstellen. Software-Patterns können durch folgende vier Eigenschaften beschrieben werden:

- Name des Patterns
- Beschreibung des Problems
- Beschreibung des Lösungsansatzes
- Konsequenzen bei Anwendung des Patterns (vgl. Gamma et al. 1995, S. 2 f).

3.2 Architektur-Patterns für Web-Präsentationen

3.2.1 Das MVC-Konzept

MVC steht für Model View Controller und wurde ursprünglich für ein Frame- work von Trygve Reenskaug in den späten 70er-Jahren für die Smalltalk- Plattform entwickelt. „MVC was conceived in 1978 as the design solution to a particular problem. The top level goal was to support the user's mental model of the relevant information space and to enable the user to inspect and edit this information” (Reenskaug 2003, The Model-View-Controller (MVC). Its Past and Present). Seitdem hat es den Entwurf von Benutzerschnittstellen nachhaltig geprägt und sich als Design-Pattern in der Softwareentwicklung bewährt (vgl. Fowler 2003., S. 367 ff).

MVC zerlegt die Interaktion mit der Benutzerschnittstelle in drei Rollen, nämlich: Model-, View- und Controller-Rolle:

- Die Model-Rolle: Das Model ist ein nicht-visuelles Objekt, das Informationen der Domäne darstellt. Alle Methoden, die nicht für die Benutzerschnittstelle verwendet werden, sind enthalten.

- Die View-Rolle: Die View stellt die visuelle Anzeige des Models in der Benutzerschnittstelle dar. Diese ist ausschließlich mit der Anzeige von Informationen befasst. Alle Änderungen der Informationen werden von der dritten Rolle verarbeitet: dem Controller.

- Die Controller-Rolle: Der Controller nimmt die Eingaben des Benutzers entgegen (daher als Input-Controller bezeichnet), bearbeitet das Model und sorgt für die Aktualisierung der Anzeige. Die Benutzerschnittstelle ist folglich eine Kombination aus View- und Controller-Rolle und dient zur Interaktion mit den Benutzern (vgl. ebd.).

Beim MVC-Konzept liegen zwei grundlegende Trennungen vor: (1) die Trennung von Präsentation und Model, sowie (2) die Trennung von Controller und View. Erstere ist das wichtigste Prinzip, das einem guten Software-Design zugrunde liegen sollte, weil:

- Präsentation und Model unterschiedliche Anliegen verfolgen,
- grundlegende Informationen des Models verschiedenartig angezeigt werden können,
- das Testen nicht-visueller Objekte einfacher ist, als das von visuellen
-bjekten (vgl. ebd.).

Den Kernpunkt dieser Trennung stellt die Richtung der Abhängigkeiten dar: Die Präsentation hängt vom Model ab und nicht umgekehrt. Die Entwickler des Models sollten nichts über dessen spätere Präsentation wissen, um später neue Präsentationen hinzufügen zu können. Ein weiterer Vorteil ist, dass Präsentationen bei Bedarf ohne Modifikation des Models geändert wer- den können. In diesem Zusammenhang tritt jedoch ein häufiges Problem auf: Bei einer Rich-Client-Schnittstelle mit mehreren Fenstern können mehrere Präsentationen eines Models gleichzeitig auf einem Bildschirm dargestellt werden. Bei Änderung des Models von einer Präsentation aus, müssen sich die anderen Präsentationen dementsprechend anpassen. Um dies zu be- werkstelligen, ohne Abhängigkeiten zu erzeugen, kann ein Observer-Pattern verwendet werden. Die View arbeitet als Observer (Beobachter) des Models, das bei dessen Änderung ein Ereignis auslöst und die View ihre Informatio- nen aktualisiert (vgl. ebd.).

Die zweite Trennung, die von View und Controller, ist in den meisten GUIFrameworks nicht gegeben. Hingegen wird die Trennung bei WUIs (Webbased User Interfaces), bei denen der Controller ausgegliedert wird, öfters angewendet (vgl. ebd.).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-1: SW-Patterns Ablauf MVC-Konzept am Webserver Quelle: vgl. ebd., S. 73

Abbildung 3-1 zeigt den Ablauf, wie die drei Rollen in einem Webserver zusammenarbeiten: (1) Der Controller nimmt eine Benutzeranfrage entgegen und (2) entnimmt ihr Informationen. (3) Anschließend aktiviert er die Busi- nesslogik des zugehörigen Models. (4) Das Model kommuniziert mit der Datenquelle, führt etwaige Anweisungen in der Anfrage aus und sammelt Informationen für die Antwort. (5) Danach gibt es die Kontrolle an den Con- troller zurück, (6) der die Rückgabewerte analysiert und entscheidet, welche View benötigt wird, um die Antwort anzuzeigen. (7) Als nächstes gibt er die Kontrolle zusammen mit den Antwortdaten an die View weiter. (8) Die Übergabe der Kontrolle an die View ist nicht immer ein direkter Aufruf, son- dern kann auch über eine vorher vereinbarte Stelle an ein HTTP-Session- Objekt erfolgen. (9) Am Ende liefert die View die Antwort an die Benutzer- schnittstelle zurück (vgl. ebd., S. 72 f).

3.2.2 View-Patterns

Auf der View-Seite müssen drei Patterns berücksichtigt werden: TransformView, Template-View und Two-Step-View. Dabei müssen zwei Entscheidungen getroffen werden: (1) soll ein Template-View oder ein Transform-View verwendet werden, und (2) sind diese einstufig oder zweistufig (Two-Step- View). Die grundlegenden Patterns für Template-View und Transform-View sind einstufig (vgl. ebd., S. 74 ff).

Bei Template-View (siehe Abbildung 3-2) wird die Anzeigeinformation in die Struktur der Seite eingebaut. Platzhalter zeigen an, wo dynamische Inhalte eingefügt werden müssen. Viele Plattformen wie ASP, JSP oder PHP arbeiten hierbei mit dem Server-Pages-Verfahren, bei dem die komplette Programmiersprache zur Verfügung steht. Dies bietet einerseits hohe Leis- tungsstärke und Flexibilität, anderseits muss sehr diszipliniert vorgegangen werden, um die Programmlogik aus der Seitenstruktur herauszuhalten. Zu diesem Zweck kann ein Hilfsobjekt (View-Helper) verwendet werden (vgl. ebd., S. 388 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-2: SW-Patterns Template-View Quelle: vgl. ebd., S. 388

Bei Transform-View (siehe Abbildung 3-3; nächste Seite) wird ein Programm im Transformationsstil verwendet (zum Beispiel XSLT). Dieses Pattern ist besonders effektiv, wenn die Daten des Models im XML-Format vorliegen oder leicht in dieses Format umgewandelt werden können. Ein Input-Controller wählt das dazugehörige XSLT-Stylesheet aus und führt eine Transformation des XML-Codes durch (vgl. ebd., S. 400 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-3: SW-Patterns Transform-View Quelle: vgl. ebd., S. 400

Eine einstufige View enthält „meistens“ eine View-Komponente für jede Bildschirmmaske. Meistens deshalb, weil logisch ähnliche Bildschirmmasken eine View gemeinsam nützen können. Ein Two-Step-View (siehe Abbildung 3-4) zerlegt diesen Vorgang in zwei Stufen: Zuerst wird aus den Daten des Models eine logische Seite (Layout) ohne Formatierungen bzw. HTML-Code erstellt. Anschließend erfolgt in der zweiten Stufe eine Umwandlung des Layouts in HTML. Der Vorteil dieser zusätzlichen Abstraktionsstufe liegt darin, dass der Zusammenbau des Layouts an einer zentralen Stelle geschieht. Dadurch wird die Wartbarkeit des Layouts vereinfacht und Teile des Layouts (zum Beispiel Kopf- und Fußbereich der Seite) können wieder- verwendet werden (vgl. ebd., S. 404 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-4: SW-Patterns Two-Step-View Quelle: vgl. ebd., S. 75 f

3.2.3 Input-Controller-Patterns

Es gibt zwei Patterns für den Input-Controller: Page-Controller und FrontController, wobei ersterer häufiger eingesetzt wird (vgl. ebd., S. 77).

Beim Page-Controller handelt es sich um „ein Objekt, das eine Anforderung für eine spezielle Seite oder Aktion auf einer Website verarbeitet“ (ebd., S. 370). Grundsätzlich ist für jede Seite der Webanwendung ein Modul als Controller zuständig. In der Praxis gibt es jedoch keine exakte Eins-zu-eins- Beziehung zwischen den Modulen und Seiten, da die Controller mit Aktionen (daher auch als Action-Controller bezeichnet) verbunden sind. Zu den wesentlichen Aufgaben eines Page-Controllers bzw. Action-Controllers zählen (siehe auch Abbildung 3-1):

- URL-Decodierung und Extrahierung der Informationen des HTTP- Requests, die für die Aktion benötigt werden.
- Erstellung und Aufruf der für die Verarbeitung der Aktion erforderlichen Model-Objekte.
- Übergabe der extrahierten Daten an das Model.
- Auswahl der View, welches die Ergebnisseite repräsentiert.
- Übergabe der Antwortdaten des Models an die jeweilige View zur Darstellung der Daten (vgl. ebd., S. 370 ff).

Der Front-Controller hingegen ist „ein Objekt, das alle Anfragen an eine Webapplikation entgegennimmt und die Arbeiten durchführt, die bei allen Anfragen identisch sind. Zur Erzeugung der Antwort auf die Anfrage leitet es die Anfragen an die Objekte weiter, die die unterschiedlichen Anfragen ver- arbeiten können“ (Schmidt. 2006, S. 292). Bei komplexen Webanwendungen gibt es viele ähnliche Schritte, die zur Verarbeitung einer Anfrage anfallen, wie zum Beispiel die Sicherheit, die Internationalisierung und die Bereit- stellung von Views. Ein Front-Controller besteht grundsätzlich aus zwei Teilen: einem Handler-Objekt und einer Befehlshierachie (vgl. Fowler 2003, S. 382 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-5: SW-Patterns Funktionsweise eines Front-Controllers Quelle: vgl. ebd., S. 383

Abbildung 3-5 stellt die Funktionsweise eines Front-Controllers dar: (1) Das Handler-Objekt nimmt die HTTP-Requests des Webservers entgegen und (2) extrahiert relevante Informationen aus der URL, um (3) die Entscheidung für die Wahl der jeweiligen Aktion treffen zu können. (4) Abschließend wird die Ausführung der Aktion an den jeweiligen Befehl delegiert und abgearbeitet (vgl. ebd., S. 382 ff).

3.3 Architektur-Patterns der Domänenlogik

3.3.1 Transaction-Script

Bei Transaction-Script handelt es sich um ein Pattern, bei dem die Domänen- logik (auch als Geschäftslogik bzw. Businesslogik bezeichnet) nach Transak- tionen organisiert wird. Jedes Transaktions-Objekt verarbeitet eine einzelne Anforderung der Präsentation. Zum Beispiel beinhaltet das Buchen eines Fluges mehrere Verarbeitungsschritte: Verfügbarkeitsprüfung, Kostenbe- rechnung und die Buchung des Fluges. Diese werden in einem Transaktions- Objekt zusammengefasst (siehe Abbildung 3-6). Der wesentliche Vorteil liegt in der Einfachheit dieses Patterns. Es ist daher besonders für Applika- tionen, die nur wenige Verarbeitungsschritte umfassen geeignet. Eine Kombi- nation mit dem Row-Data-Gateway (siehe Kapitel 3.4.1) bzw. dem Table- Data-Gateway (siehe Kapitel 3.4.2) ist möglich. Falls die Domänenlogik jedoch komplexer wird, ist es schwieriger, diese zu strukturieren. Die Folge ist die Duplizierung von Transaktions-Code, daher ist in diesem Fall der Entwurf des Domain-Models, welches im nächsten Kapitel beschrieben wird, besser geeignet (vgl. ebd., S. 131 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-6: SW-Patterns Transaction-Script Quelle: vgl. ebd., S. 131

3.3.2 Domain-Model

Das Domain-Model stellt ein Objektmodell der Domäne dar, das nicht nur Geschäftslogik sondern auch Daten umfasst. Der gesamte Geschäftsbereich (Daten und Regeln) wird durch ein Netz an erstellten Objekten, abgedeckt. Es kann dabei zwischen einfacher (Simple-Domain-Model) und komplexer Logik (Rich-Domain-Model) unterschieden werden. Das Objektmodell einer einfachen Logik kann für die Datenanbindung mit dem Active-Record-Pattern (siehe Kapitel 3.4.3) kombiniert werden. Bei komplexerer Logik (Vererbung, Verwendung von anderen Design-Patterns, wie zum Beispiel das StrategyPattern) ist eine einfache Datenbankanbindung nicht mehr möglich. Daher ist ein Data-Mapper (siehe Kapitel 3.4.4) dem Active-Record vorzuziehen. In Folge dessen wird die Erstellung, Änderung und das Testen des Objektmodells erleichtert (vgl. ebd., S. 138 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-7: SW-Patterns Domain-Model Quelle: vgl. ebd., S. 138

3.3.3 Table-Module

Das Table-Module-Pattern kann folgendermaßen beschrieben werden: Ein instanziertes Objekt (Singleton), das die Geschäftslogik für alle Zeilen in einer Datenbanktabelle oder Datenbankview verwaltet. Beim Rich-Domain- Model tritt das Problem auf, dass die Objektstruktur nicht in einem relatio- nalen Datenbankmodell abgebildet werden kann (Impedance-Mismatch). Daher gibt es bei Table-Module eine Klasse je Datenbanktabelle oder Daten- bankview, die die jeweilige Geschäftslogik abbildet. Der Hauptunterschied zum Domain-Model liegt in der Identität und Multiplizität der Objekte (vgl. Liebhart, Schmutz, Lattmann, Heinisch, Könings, Kölliker, Pakull, Welkenbach 2007, S. 6 ff). Dies bedeutet, dass es beim Domain-Model für jeden gespeicherten Auftrag ein Auftrags-Objekt gibt, während bei Table-Module nur ein Objekt für alle Aufträge vorgesehen ist (vgl. Fowler 2003, S. 148 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-8: SW-Patterns Table-Module Quelle: vgl. ebd., S. 148

3.4 Architektur-Patterns für Datenquellen

3.4.1 Row-Data-Gateway

Das „Row-Data-Gateway dient als Repräsentation einer Zeile einer Daten- banktabelle. Es existiert eine Instanz pro Zeile, über die die Spalten der Zeile verändert werden können“ (Schmidt 2006, S. 253). Jede Spalte der Tabelle stellt im Objekt ein Attribut dar. Die Abfrage-Operationen (siehe Abbildung 3-9; nächste Seite) sollten in einem separaten Objekt untergebracht werden, um unterschiedliche Methoden für verschiedene Datenquellen verwenden zu können. Der Unterschied zu Active-Record (siehe Kapitel 3.4.3) besteht darin, dass im Row-Data-Gateway keine Domänenlogik enthalten ist, sondern ausschließlich der Code für den Datenbankzugriff. Dieser Ansatz ist besonders für Transaction-Script geeignet (vgl. Fowler 2003, S. 177 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-9: SW-Patterns Row-Data-Gateway Quelle: vgl. ebd., S. 177

3.4.2 Table-Data-Gateway

Von einem Table-Data-Gateway Pattern spricht man, wenn ein Objekt, das als Gateway zu einer Datenbanktabelle dient nicht nur eine, sondern alle Zeilen in der Tabelle verwaltet. Ein Table-Data-Gateway enthält den gesam- ten SQL-Code für den Zugriff auf eine einzelne Tabelle. Dieses Pattern ist sehr gut in Kombination mit Table-Module anzuwenden (vgl. ebd., S. 169 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-10: SW-Patterns Table-Data-Gateway Quelle: vgl. ebd., S. 169

3.4.3 Active-Record

Bei Active-Record entspricht ein Objekt einem Datensatz, einer Datenbank- tabelle oder Datenbankview. Dabei wird die Geschäftslogik mit dem Zugriff auf den zugrundeliegenden Datensatz gekoppelt. Durch das Active-Record- Pattern wird der gesamte Datenbankzugriff für ein Objekt in die Klasse selbst integriert. Methoden für Create, Read, Update und Delete (CRUD-Implemen- tierung) werden innerhalb der Klasse zur Verfügung gestellt, um das Objekt mit dem zugehörigen Datensatz abzugleichen. Außerdem müssen auch Methoden zur Auffindung eines Datensatzes (Finder-Methoden) implementiert sein (vgl. Schlossnagle 2006, S. 349 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-11: SW-Patterns Active-Record Quelle: vgl. Fowler 2003, S. 185

3.4.4 Data-Mapper

Data-Mapper, auch als objektrelationale Mapper (ORM) bezeichnet, sind eine zusätzliche Abstraktionsschicht, die die Übertragung von Daten zwi- schen Objekten und einer Datenbank ermöglicht. Durch die Abstraktion blei- ben die Objekte voneinander und vom Mapper selbst unabhängig. Data- Mapper wirken dem unter Kapitel 3.3.3 beschriebenen Abbildungsproblem von OO-Techniken eines Rich-Domain-Models in eine relationale Datenbank entgegen (vgl. ebd., S. 191 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-12: SW-Patterns Data-Mapper Quelle: vgl. ebd., S. 191

3.5 Zusammenfassung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-13: SW-Patterns Zusammenfassung

Software-Patterns beschreiben Lösungsansätze für Probleme der SoftwareEntwicklung, die immer wiederverwendet werden können. In diesem Kapitel wurden Architektur-Patterns für Webpräsentationen, Domänenlogik und Datenquellen vorgestellt, um Ansätze in den unter Kapitel 5 evaluierten PHPFrameworks zu veranschaulichen. Im nächsten Abschnitt wird nun mit dem praktischen Teil dieser Arbeit begonnen, im dem die Definitionen für die Evaluierung der PHP-Frameworks getroffen werden, um einerseits auf die Anforderungen von Web Application Frameworks einzugehen, und andererseits die notwendige Basis für die Evaluierung zu schaffen.

4 DEFINITIONEN FÜR DIE EVALUIERUNG

Zahlreiche PHP-Frameworks sind in den letzten Jahren entstanden, wobei sich einige mehr und andere weniger einen sicheren Platz in der PHP- Community erarbeitet haben. Diese Fülle an Frameworks bringt jedoch Unklarheit, welches Framework für welche Zwecke am besten geeignet erscheint. Leider gibt es momentan nur oberflächlich betrachtete Vergleiche der einzelnen Frameworks, die keine wirkliche Entscheidungshilfe darstellen. Dies mag daher kommen, dass die meisten Frameworks erst in den letzten Jahren entwickelt wurden und somit noch keine aussagekräftigen Vergleiche möglich waren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-1: Definition The Big List of PHP Frameworks Quelle: vgl. Leseberg 2009

Für die im Kapitel 5 durchgeführte Evaluierung wird zunächst die ange- wandte Methodik vorgestellt und anschließend eine Auswahl von drei Frame- works getroffen, deren Architektur auf dem unter Kapitel 3.2.1 beschriebenen MVC-Konzept basiert. Des Weiteren werden die Kriterien für die Evaluierung festgelegt und ausführlich beschrieben. Danach erfolgt die Definition eines praktischen Beispieles, das für zusätzliche Erläuterungen im Zuge der Evaluierung dienen soll und auszugsweise im Anhang der Arbeit für jedes Framework beigefügt ist.

4.1 Methodik

Für die Evaluierung wurde die unter die freie GNU-Lizenz für Dokumentationen⁴ gestellte Methode QSOS⁵ (Method for Qualification and Selection of Open Source Software) mit der derzeitigen Version 1.6 adaptiert angewendet. Diese wurde von dem Untenehmen Artos Origin⁶ im Jahr 2004 initiiert und dient zur Qualifikation und Auswahl von Open Source Software (vgl. Semeteys, Pilot, Baudrillard, Le Bouder 2006, S. 6 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-2: Definition QSOS-Methode, Stufe I Quelle: ebd., S. 8

Abbildung 4-2 zeigt den Aufbau dieser iterativen Methode, die aus vier Stufen besteht: (1) Die Definition, (2) die Evaluierung (siehe Kapitel 5), (3) die Qualifikation und (4) die Auswahl des Frameworks (siehe Kapitel 6). Für die Evaluierung wurde das Firefox-Plugin namens QSOS XULEditor⁷ in der derzeitigen Version 0.9 verwendet, dessen Datenhaltung auf XML-Format basiert und als Unterstützung im Evaluierungsprozess dient. Der Ablauf der Methode wird durch deren Anwendung während der Evaluierung ersichtlich.

4.2 Auswahl der PHP-MVC-Frameworks

Für die Evaluierung werden drei Frameworks ausgewählt, deren Architektur auf dem MVC-Konzept (siehe Kapitel 3.2.1) basiert. Zur Entscheidungs- findung wurde hierfür der Verbreitungsgrad der Frameworks herangezogen, der mit Hilfe einer Analyse von Suchergebnissen der Suchmaschine Google⁸ für die unter Abbildung 4-1 ersichtlichen Frameworks ermittelt wurde. Dabei wurde nach dem Begriff: „+<Frameworkname> +PHP +Framework" gesucht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-3: Definition Verbreitungsgrad PHP-MVC-Frameworks Quelle: vgl. Google Inc. 2009, Analyse der Suchergebnisse

Wie in Abbildung 4-3 ersichtlich, konnten sich drei der Frameworks klar von den Anderen absetzen. Folgende Frameworks werden daher für die Evaluierung ausgewählt:

- CakePHP
- Symfony
- Zend Framework

4.3 Evaluierungskriterien

Die Evaluierungskriterien werden in drei Gruppen eingeteilt: (1) Funktionale Abdeckung, (2) Risiken aus Sicht des Anwenders und (3) Risiken aus Sicht des Serviceproviders (vgl. Semeteys et al. 2006, S. 13). Innerhalb jeder Gruppe wird wiederum zwischen Haupt- und Unterkriterien unterschieden, wobei die Unterkriterien die eigentlich zu evaluierenden Merkmale darstellen. Im folgenden Kapitel werden diese Kriterien erläutert und deren Aufnahme in den Kriterienkatalog (siehe Kapitel 4.3.4) begründet.

4.3.1 Funktionale Abdeckung

K 1.1 Model

Zunächst wird die Umsetzung des Models (K 1.1.1) untersucht. Dabei sol- len Varianten für einfache und komplexe Anforderungen unterstützt werden.

Zusätzlich wird von der Model-Rolle eine strikte Trennung zur View und zum DB-Zugriff (K 1.1.2) erwartet. Der wesentliche Vorteil der Trennung zur View liegt in der Unabhängigkeit der beiden Rollen. Unterschiedliche Personen können ihre individuellen Fähigkeiten bei der Bearbeitung gleichzeitig einsetzen. Die Trennung zum DB-Zugriff soll den Austausch von Datenbanken ohne Änderung des Models ermöglichen.

Zusammenfassend: Das Model soll nach dem Entwurfsprinzip des MVC- Konzeptes (siehe Kapitel 3.2.1) umgesetzt sein und auf Architektur-Patterns der Domänenlogik (siehe Kapitel 3.3) basieren bzw. dessen Implementation unterstützen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4-1: Definition Hauptkriterium 1.1, Model

K 1.2 View

Als erstes wird die Umsetzung der View (K 1.2.1) untersucht. Dynamische Views (Template-View) und Layouts (Two-Step-View) sollen möglich sein. Zusätzlich soll es auch die Möglichkeit geben Formate wie zum Beispiel XML, PDF oder auch RSS durch Transformation zu erzeugen (Transform- View).

Zweitens wird die strikte Trennung zwischen View und Controller (K 1.2.2) untersucht. Diese Trennung ist bei Webanwendungen von größerer Bedeutung als bei Rich-Client-Systemen, da hier der Controller häufig aus- gegliedert wird, und die Überprüfungen einen höheren Aufwand für die Ent- wickler bedeuten.

Zusammenfassend: Die View soll nach dem Entwurfsprinzip des MVCKonzeptes (siehe Kapitel 3.2.1) umgesetzt sein und auf View-Patterns (siehe Kapitel 3.2.2) basieren bzw. dessen Implementation unterstützen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4-2: Definition Hauptkriterium 1.2, View

K 1.3 Controller

Die Umsetzung des Controllers (K 1.3.1) soll standardmäßig mittels PageController (Action-Controller) realisiert sein. Zusätzlich soll die Möglichkeit zur Nutzung eines Front-Controllers gegeben sein.

Zusätzlich soll der Controller eine strikte Trennung zur View (K 1.3.2) auf- weisen.

[...]

---

¹ http://www.motiondata-internet.at

² http://www.motiondata.at

³ http://www.qsos.org

⁴ http://www.gnu.org/copyleft/fdl.html

⁵ http://www.qsos.org

⁶ http://www.atosorigin.com

⁷ http://www.qsos.org/tools/xuleditor-firefox-0.9.xpi

⁸ http://www.google.com