Rails’ MVC-Konzept

Es geht hier also um drei Schichten, die zusammen die Anwendung darstellen.

Controller (Steuerung)

Der Controller ist die Schicht, die Anfragen (einfache oder Post-Requests) des Clients (z. B. vom Browser) verarbeitet und Daten aus dem Model zusammenstellt und mit einem View antwortet. Seit Rails 2.0 sind die Controller standardmäßig „RESTful“ - was es damit auf sich hat, erkläre ich in einem anderen Artikel. Im Grunde genommen bedeutet das kurzgesagt, dass man sich hier aber nur noch an sieben Methoden pro Controller hält, die folgende Aufgaben übernehmen: Übersicht (index), Neu anlegen (new und create), Bearbeiten (edit und update) und Löschen (destroy).

Vermutlich stellt sich gerade jemand die Frage, warum Neu anglegen und Bearbeiten jeweils zwei Actions (so werden die Methoden von Controllers in Rails genannt) benötigen. Hier die Antwort:

• Die Action new initialisiert nur ein neues Object und stellt mit seinem View nur das (noch leere) Formular dar. Das Formular schickt seine Daten dann an die create-Action.
• Die Action create nimmt die Post-Request-Daten entgegen und verarbeitet (sprich: validiert und speichert) sie und leitet dann entweder an die index-Action weiter und/oder gibt eine Erfolgmeldung aus.
• Die edit-Methode lädt das angefragte Objekt aus der Datenbank und stellt mit seinem View das mit den Objektdaten ausgefüllte Formular dar. Das Formular sendet seine Daten an die Action update.
• Die update-Action nimmt die Post-Request-Daten entgegen und validiert und speichert dann das Objekt wieder.

Der Controller ruft also Daten aus dem Model (sprich: aus der Tabelle) ab und stellt sie zu Verfügung oder ändert sie mithilfe der Methoden, die das Model enthält.

Model (Modell)

Das Model ist sozusagen die Brücke zur Datenbanktabelle. ActiveRecord (die Datenbankabstraktionsschicht, die jedes Model automatisch erbt) ist dann der Brückenkopf zur Datenbank.

Im Model wird die Business-Logik implementiert, d. h. hier werden Eigenschaften des Models und die Assoziationen zu anderen Models angegeben. Methoden, wie new, find, save, update etc. sind bereits durch die Vererbung der ActiveRecord-Klasse verfügbar und müssen nicht immer wieder neu programmiert aber gerne geändert/überschrieben werden. Alle Attribute des Models (also die Tabellenspalten, wie z. B. die Spalte „title“ des Models Post) sind auch direkt als Setter- und Getter-Methoden verfügbar.

Alle Methoden des Models können auf ihre Objekte in Controllers und Views angewendet werden. Ändern und Speichern sollte man aber besser dem Controller als dem View überlassen.

View (Präsentation)

Das View stellt die Daten für den Client dar. Views sind einfache Dateien, die eine direkte Beziehung zu den Actions haben und auch genauso heißen. Die Dateiendung ist hier besonders interessant.

• edit.html.erb
• show.js.rjs
• index.xml.builder

Der Dateiname beginnt also mit dem Namen der dazugehörigen Action (das ist Konvention) und danach folgt auf einem Punkt das Format in dem das View gesendet wird (html, js, xml etc.). Darauf folgt die Template-Engine, in der das View verfasst wird. Das wären die Konventionen: HTML wird mit erb geschrieben, Javascript wird mit rjs geschrieben und XML wird mit builder verfasst. Man kann hier aber gerne abweichen, was aber eher selten nötig sein wird.

Im View kann man alle Instanzvariablen, die in ihrer Action erstellt wurden, verwenden. Mochte ich also den Titel eines Posts darstellen, mach ich das in einem erb-Template so:

<h1><%= @post.title %></h1>

Verwendung von Variablen in der erb-Template-Engine

Die spitzen Klammern und Prozentzeichen zeigen der Template-Engine, dass darin Ruby-Code steht, der ausgeführt werden soll. Das Gleichheitszeichen sagt, dass der Rückgabewert der Anweisung ausgeben werden soll. Lässt man das Gleichheitszeichen weg, wird der Code zwar ausgeführt, aber nicht ausgegeben. Das ist manchmal nötig, wenn im View einfache (aber nur einfache) Berechnungen oder Ähnliches durchgeführt werden sollen. Man sollte jedoch so wenig Logik wie möglich im View unterbringen. If-Anweisungen sind hier wohl der häufigste Fall, bei dem das aber auch völlig in Ordnung geht. Wenn jedoch die boolschen Ausdrücke sehr komplex/lang sind, ist die Überlegung wert, diesen nicht schon im Model oder im Controller unterzubringen. Denn wenn diese if-Anweisung in mehreren Templates dieser Action nötig ist, spart mann sich dann die Wiederholung.

Mehr Informationen zum MVC-Konzept im Allgemeinen gibt es bei Wikipedia.