PHP-Alternativen: Ruby on Rails

Der Einsatz von Frameworks für die Entwicklung von Webseiten und -anwendungen ist keine neue Erscheinung. Bereits seit Jahren existieren verschiedene Lösungen in diesem Bereich. Eines dieser Frameworks hat aber besonders bleibende Spuren hinterlassen und zurecht für einigen Wirbel und ein Umdenken gesorgt.

Die Rede ist von Ruby on Rails, meist nur Rails oder einfach kurz RoR genannt, das im Vergleich zu anderen Frameworks oder Programmiersprachen im Webbereich mit erstaunlich wenig Quellcode und Konfigurationsdateien auskommt. Zwei Grundprinzipien standen bei der Entwicklung des Frameworks im Vordergrund: DRY (Don't repeat yourself) und Convention over Configuration.

Ruby bietet so beispielsweise eine Reihe nahtlos in das Framework integrierter Bestandteile, die zur Lösung alltäglicher Probleme genutzt werden können. Dazu zählen die Unterstützung von AJAX, E-Mail, Webservices, Datenbanken und vieles mehr. RoR kommt mit sehr wenigen Konfigurationsdateien aus, da vieles wie von Geisterhand zusammenpasst, beziehungsweise automatisch zusammenfindet.

Ruby on Rails blickt auf eine relativ kurze Geschichte zurück. David Heinemeier Hansson veröffentlichte die erste Version im Jahr 2004. Bereits die ersten Versionen lösten einen gewaltigen Hype um Rails aus.

In den darauf folgenden Jahren hat sich der Hype etwas gelegt, übrig geblieben ist aber eine große und stetig wachsende Community sowie ein Framework, das allen Anforderungen moderner Webanwendungen gerecht wird.

Die Basis

Rails ist ein sogenanntes MVC-Framework. Hinter diesem Kürzel verbirgt das Model- View-Controller-Entwurfsmuster. Der Grundgedanke hinter diesem Pattern ist die strikte Trennung zwischen den grundsätzlichen Aufgabenbereichen einer Anwendung. Folgende Bereiche lassen sich hierbei unterscheiden:

• Model: In der Model-Schicht ist die Datenlogik einer Anwendung untergebracht. Alle Klassen, die für den Zugriff auf Daten einer Datenbank verantwortlich sind, werden dieser Schicht zugeordnet. • View: Die Anzeigelogik einer Anwendung gehört zur View-Schicht. Ruby unterstützt die Ausgabe Webseiten durch diverse Helfer-Skripte, die ganze HTML-Konstrukte erzeugen können. • Controller: Diese Schicht ist das Bindeglied zwischen den beiden anderen Schichten. In einem Controller ist die Steuerungslogik zusammengefasst. In der Regel veranlasst der Controller, dass Daten durch die Model-Klassen aus der Datenbank gelesen werden und gibt diese an den View zur Anzeige weiter.

Diese Art der Trennung von Aufgaben einer Anwendung in einzelne, voneinander unabhängige Teile hat mehrere Vorteile. So steigt dadurch beispielsweise die Übersichtlichkeit und damit auch die Wartungsfreundlichkeit des Quellcodes.

Des Weiteren ist es einfacher einzelne Bereiche durch neue Implementierungen auszutauschen. Wenn zukünftig die Daten nicht mehr aus einer Datenbank, sondern per Webservice geladen werden sollen, so genügt es meist, die Model- Klassen anzupassen, der Controller und der View bleiben davon unberührt.

Welcher Controller aufgerufen wird, entscheidet das Framework selbstständig anhand der aufgerufenen URL. Dafür verantwortlich ist der Dispatcher, der aufgrund definierter Regeln automatisch zum passenden Controller weiterleitet. Eine Anwendung besteht somit aus mehreren Controller-Klassen.

Generator

Eine der Neuerungen, die Ruby on Rails salonfähig gemacht hat, ist das Ausführen von häufig vorkommenden Aufgaben per Kommandozeile. Darunter fallen ganz alltägliche Aufgaben, wie beispielsweise die Erstellung einer Projektstruktur. Bei Ruby genügt dafür ein einfacher Befehl auf Kommandozeilenebene:

Damit ist bereits ein großer Schritt getan. Nach dem Ausführen dieses Befehls ist bereits auf der Kommandozeile ersichtlich, dass eine Menge an Dateien und Verzeichnissen erzeugt wird. Für die Entwicklung sehr praktisch, ist auch, dass ein kleiner Webserver bereits mit dem Framework ausgeliefert wird.

Dieser Webbrick genannte und in Ruby entwickelte Server ist zwar nicht für produktive Systeme geeignet, aber zur Anzeige der ersten Ergebnisse durchaus ausreichend. Der Server kann mit folgendem Befehl direkt aus dem Projektverzeichnis heraus gestartet werden.

Anschließend ist das Projekt über die URL https://localhost:3000 erreichbar. Die erste Ausgabe ist eine Standardseite des RoR-Frameworks. Ein erster Blick in das Projektverzeichnis zeigt bereits, dass eine Rails-Anwendung stark hierarchisiert ist und die Quelltexte in vielen verschiedenen Verzeichnissen abgelegt sind.

Unterhalb des app-Verzeichnisses finden sich so beispielsweise Unterordner für die Controller, die Modell-Klassen und die View-Templates. Konfigurationen, Libraries und Unit-Tests sind hiervon strikt getrennt. Jeder Anwendungsteil besitzt so ein eigenes Verzeichnis. Da nahezu alle Rails-Projekte nach diesen Vorgaben arbeiten, findet man sich nach kurzer Eingewöhnungsphase auch in fremden Projekten sehr schnell zurecht.

Das Model

Fast alle Webanwendungen speichern heutzutage ihre Daten in Datenbanken ab. Daher kommt der Model-Schicht eine besondere Bedeutung zu. Rails liefert in der Standard-Installation lediglich einen in Ruby implementierten MySQL-Datenbanktreiber mit aus. Dieser lässt sich aber einfach durch eine in C implementierte und daher deutlich schnellere Variante ersetzen.

Zudem bietet Rails auch die Möglichkeit, Treiber für viele populäre Datenbanksysteme zu installieren. So wird der Zugriff auf Postgre SQL, SQLite, MS SQL, Informix, IBM DB2 oder auch Oracle ermöglicht.

Die Implementierung von Datenbankzugriffen zählt bei vielen Anwendungen zu den zeit- und fehleraufwendigsten Aufgaben während der Entwicklung. Rails vereinfacht diesen Vorgang erheblich, indem es verschiedene Hilfsmittel zur Verfügung stellt. Das folgende Beispiel zeigt die Erstellung einer Model-Klasse für einen Eintrag einer Bloganwendung.

Die so erstelle Modelklasse ist wenig spektakulär, da sie lediglich aus folgendem Quelltext besteht.

Mehr ist vorerst auch nicht erforderlich. Hier greift nämlich automatisch eine der angesprochenen Konventionen von Rails. Es geht einfach davon aus, dass die Daten für die Klasse Post in einer Tabelle mit dem Namen posts in der Datenbank abgelegt sind.

Selbstverständlich kann dies auch geändert werden, wenn man mit einer vorgegebenen Datenbankstruktur arbeitet, ansonsten ist diese Art der Konvention jedoch sehr eingängig und erleichtert die Arbeit ungemein.