Vergleich Verschiedener PHP-Basierter ORM-Frameworks Mit Fokus Auf Ihrem Anwendungspotenzial Für Content-Management-Systeme
Total Page：16
File Type：pdf, Size：1020Kb
Vergleich verschiedener PHP-basierter ORM-Frameworks mit Fokus auf ihrem Anwendungspotenzial für Content-Management-Systeme von Ingmar Szmais 3113419 Databay AG 1. Prüfer: Prof. Dr. rer. nat. Volker Sander 2. Prüfer: Thomas Joussen Reichshof, 26. Dezember 2018 1 Eidesstattliche Erklärung Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema “Vergleich verschiedener PHP-basierter ORM-Frameworks mit Fokus auf ihrem Anwendungspotenzial für Content-Management-Systeme” selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, alle Ausführungen, die anderen Schriften wörtlich oder sinngemäß entnommen wurden, kenntlich gemacht sind und die Arbeit in gleicher oder ähnlicher Fassung noch nicht Bestandteil einer Studien- oder Prüfungsleistung war. Ich verpflichte mich, ein Exemplar der Seminararbeit fünf Jahre aufzubewahren und auf Verlangen dem Prüfungsamt des Fachbereiches Medizintechnik und Technomathematik auszuhändigen. Name: Ingmar Szmais Reichshof, den 26.12.2018 Unterschrift des Studenten 1. Prüfer: Prof. Dr. rer. nat. Volker Sander 2. Prüfer: Thomas Joussen Reichshof, 26. Dezember 2018 2 Inhaltsverzeichnis ● 1. Einleitung 4 ● 2. Umgebung 5 ● 3. Voraussetzung und Einrichtung 6 ○ RedbeanPHP 6 ○ Doctrine 7 ○ Maghead 9 ● 4. Erweiterte Nutzung und Performance 11 ○ RedbeanPHP 11 ○ Doctrine 14 ○ Maghead 19 ● 5. Fazit 23 ● 6. Quellen 27 ● 7. Anhang 28 3 1. Einleitung Durch den Fortschritt der globalen Vernetzung und deren Integration in die Gesellschaft werden immer mehr analoge Datenverwaltungssysteme durch digitale Content-Management-Systeme (CMS) ersetzt. Besonders in der Web-basierten CMS Entwicklung sorgt die dadurch steigende Datenmenge und Datenverknüpfung in Korrelation mit der steigenden Komplexität der Anwendungen für Probleme, die sich meist durch eine verbesserte Datenstruktur und Reduzierung trivialer Datenbankabfragen beheben lassen. Besonders die Migration der meist prozeduralen, analogen Daten hin zu objektorientierten digitalen Daten stellt bei der Datenverwaltung eine der größten Schwierigkeiten dar. Die Nutzung von Objektrelationalen Abbildungen (abgeleitet von “object-relational mapping” Abk. ORM) spielt hierbei eine entscheidende Rolle, da sie die Transformation der Daten hin zu einer objektorientierten Datenstruktur an der Datenbankschnittstelle übernimmt und somit an dem Ressourcen-intensivsten Punkt, der Verbindung des Webservers zum Datenbankserver, ansetzt und dabei hilft den Daten-Overhead zu reduzieren. Das primäre Ziel eines dazu genutzten ORM-Frameworks ist es somit eine intelligente Schnittstelle zur Datenbank bereitzustellen, die durch möglichst dynamische Objektrelationen die Abrufe der Datenbank auf eine Minimum reduziert. Zusätzlich sollte sekundär die Semantik des Frameworks intuitiv verständlich sein und gleichzeitig eine hohe Konfigurierbarkeit bereitstellen, um eine fehlerhafte oder Framework-externe Nutzung und somit Gefährdung des primären Ziels zu vermeiden. 4 2. Umgebung Der Vergleich beinhaltet die ORM-Frameworks RedBeanPHP 5.2, Doctrine 2.6 und Maghead 4.0 . Sämtliche Tests werden auf einem Ubuntu 16.04 Betriebssystem mit PHP-Version 7.2, auf einem Nginx-Webserver der Version 1.14.1 und einem MariaDB-Datenbankserver Version 10 ausgeführt. Als Testobjekt für die Datenverwaltung wird ein stark vereinfachtes Modell eines CMS einer Hochschule simuliert. Das Modell enthält 3 inhaltsspezifische Tabellen in Form von 10000 Studierenden, 10 Fachbereichen und 100 Modulen. Je nach Framework enthält es zusätzlich Tabellen für die anfallenden Verknüpfungen zwischen Fachbereichen und Modulen (1 zu N) und Studierenden und Modulen (N zu N). Hierbei werden alle Module mit jeweils einem Fachbereich verknüpft (die Anzahl der Module pro Fachbereich ist hierbei zufällig und kann auch 0 betragen) und jeder Student mit bis zu 6 Modulen, beziehungsweise jedes Modul mit beliebig vielen Studenten . 5 3. Voraussetzungen und Einrichtung RedbeanPHP Unter den verglichenen Frameworks setzt RedBeanPHP 5.2 die wenigsten Abhängigkeiten voraus. So benötigt das Framework lediglich PHP 5.3 oder höher (PHP 6 wird nur teilweise unterstützt), die PHP Datenobjekt-Erweiterung (abgeleitet von “PHP data objects extension” Abk. PDO) und einen der gängigen Datenbanktreiber wie MySQL, MariaDB, PostgreSQL oder SQLite. Zusätzlich kann die Kompatibilität weiterer Treiber durch diverse RedBean Extensions bereitgestellt werden. Die Einrichtung ist nach Bereitstellung der Abhängigkeiten ebenfalls sehr einfach, da das komplette Framework in Form von einer großen PHP-Datei eingeladen wird. Danach ist die komplette Einrichtung des Frameworks fertig, was es unter den hier behandelten Frameworks zu dem Einfachsten und mit einer Dateigröße von < 1MB zum Kleinsten macht. Als Schnittstelle dient hierbei die in der zuvor beschriebenen Datei enthaltene Klasse R, welche über meist statische Aufrufe Daten von der Datenbank abfragt oder persistiert. Um mit der Verwaltung der Daten zu beginnen wird eine Setup-Funktion von R aufgerufen. Dabei erstellt das Framework, sofern die Funktion ohne Parameter aufgerufen wurde, eine eigene temporäre Datenbank, welche zu Entwicklungszwecken genutzt werden kann. Diese wird allerdings nicht für die Nutzung auf Produktiv-Systemen empfohlen, da sie auf mangelnder Wartung Performance- und Sicherheitslücken aufweist. Eine eigene Datenbank für die Nutzung auf Produktiv-Systemen wird nicht grundlegend bereitgestellt. Dafür besteht die Möglichkeit das Framework mit einer bereits vorhandenen Datenbank durch Angabe des Data-Source-Name (DSN) und der Zugangsdaten im Setup-Aufruf zu verknüpfen (siehe Abbildung 1.1). Der DSN übergibt sämtliche Kontaktdaten der Datenbankverbindung innerhalb eines konventionellen Strings. Sobald die Verbindung zur Datenbank gewährleistet ist können Daten abgerufen und persistiert werden. Dies geschieht über die Verwendung von sogenannten Beans. Ein Bean ist ein dynamisch erweiterbares Tabellenschema auf dessen Basis sich alle Grundfunktionalitäten der Datenverwaltung, definiert durch die sogenannten 6 CRUD-Operatoren, realisieren lassen. Die CRUD-Operatoren enthalten die Grundoperatoren einer Datenverwaltung, “create” zum erstellen, “read” zum lesen, “update” zum aktualisieren und “delete” zum löschen. Zum Erstellen einer neuen Datenbanktabelle wird ein Bean per “dispense”-Befehl vorbereitet. Danach können dem Bean beliebig viele neue Attribute hinzugefügt oder bereits bestehende Attribute geändert werden. Sobald die Bearbeitungen des durch den Bean dargestellten Datenbankeintrags beendet ist, kann dieser durch den “store”-Befehl auf der Datenbank persistiert werden, durch welchen man als Rückgabewert die dynamisch erstellte ID des Datenbankeintrags erhält. Durch den “load”-Befehl kann der Eintrag in einen neuen Bean geladen und dort weiterverarbeitet werden. Gelöscht werden kann der Datenbankeintrag eines geladenen Beans per “trash”-Befehl. Zusätzlich zu den vier Grundfunktionen bietet RedbeanPHP zur jeder Funktion die Möglichkeit, per “All”-Suffix ganze Arrays von Beans zu verwalten. Alle genannten Funktionen werden statisch auf der R-Klasse aufgerufen. Optional kann durch eine Umkonfiguration des System auf statische Aufrufe verzichtet werden. [Rdoc] Doctrine Doctrine 2.6 benötigt für die Nutzung immer die LSV (“latest-stable-version”) von PHP, was momentan PHP 7.2 entspricht, ebenfalls PDO, einen gängigen Datenbanktreiber und den PHP-Paketmanager Composer. Bei älteren Versionen von Doctrine 2 liegt die Voraussetzung bei PHP 5.4 und höher (PHP 6 ausgeschlossen). Über den Composer wird folgen durch eine erstellte Composer-Konfiguration Doctrine und das benötigte Yaml-Paket von Symfony geladen. Das Yaml-Paket selbst ist dabei optional und wird durch Nutzung von Doctrine 3 oder durch Änderung der Grundkonfiguration in Doctrine 2 obsolet. Alle für die Datenverwaltung notwendigen Dateien können dann über den integrierten Autoloader eingeladen werden. Sobald dies geschehen ist, kann das Framework zur Datenverwaltung genutzt werden und liegt mit einer Größe von ungefähr 8 MB sowohl von der Komplexität als auch vom Speicherbedarf unter den getesteten ORM-Frameworks im Mittelfeld. Anders als bei RedbeanPHP ist Doctrine sehr objektorientiert strukturiert und bietet schon bei der Einrichtung mehrere Konfigurationsmöglichkeiten. So gibt es im 7 Framework eine Setup-Klasse die sich alleine um die Vorkonfiguration der ORM-Schnittstelle kümmert. Da in Doctrine, im Gegensatz zu RedbeanPHP, die Model-Klassen von ihren zugehörigen Repositories und somit von ihrer Datenverwaltungsebene getrennt definiert werden, benötigt das Framework eine Möglichkeit, die bestehenden autarken Modellstrukturen zu interpretieren. Hierzu verwendet Doctrine Metadaten-Konfigurationen die in drei verschiedenen Formaten angelegt werden können: ● Yaml-Dateien (ab Doctrine 3 nicht mehr möglich) ● XML-Dateien ● Dokumentation in der Model-Klassen selbst. Bei der Auswahl der Metadaten-Konfiguration muss der Pfad der Model-Klassen angegeben werden, wodurch das Framework den Entwickler in eine strikte Ordnerstruktur zwingt. Zusätzlich kann in der Konfiguration ein Entwicklungs-Flag für Testzwecke gesetzt werden, wodurch das Caching teilweise aufgehoben wird um ein schnelleres Testen der Software zu ermöglichen. Nachdem diese Vorkonfigurationen eingerichtet wurden, kann durch die EntityManager Klasse eine Datenbankverbindung erstellt werden. Die Klasse erhält dabei ein Array mit den für die Verbindung wichtigen Daten, wie zum Beispiel DSN-Parametern, und die gespeicherte Vorkonfiguration