Wenn Sie Ihre eigenen Programme von Anfang bis Ende schreiben, ist dies leicht zu erkennen Ablaufsteuerung. Das Programm startet hier, dort gibt es eine Schleife, hier sind Methodenaufrufe, alles ist sichtbar. In einer Rails-Anwendung sind die Dinge jedoch nicht so einfach. Mit einem Framework jeglicher Art geben Sie die Kontrolle über Dinge wie "Flow" zugunsten einer schnelleren oder einfacheren Möglichkeit zur Ausführung komplexer Aufgaben auf. Im Fall von Ruby on Rails wird die Flusskontrolle hinter den Kulissen durchgeführt, und Sie haben nur (mehr oder weniger) eine Sammlung von Modellen, Ansichten und Controllern übrig.
Das Herzstück jeder Webanwendung ist HTTP. HTTP ist das Netzwerkprotokoll, mit dem Ihr Webbrowser mit einem Webserver kommuniziert. Hierher kommen Begriffe wie "Anfrage", "GET" und "POST", sie sind das Grundvokabular dieses Protokolls. Da Rails jedoch eine Abstraktion davon ist, werden wir nicht viel Zeit damit verbringen, darüber zu sprechen.
Wenn Sie eine Webseite öffnen, auf einen Link klicken oder ein Formular in einem Webbrowser senden, stellt der Browser über TCP / IP eine Verbindung zu einem Webserver her. Der Browser sendet dem Server dann eine "Anfrage". Stellen Sie sich das wie ein Mail-In-Formular vor, das der Browser ausfüllt und nach Informationen auf einer bestimmten Seite fragt. Der Server sendet dem Webbrowser schließlich eine "Antwort". Ruby on Rails ist jedoch nicht der Webserver. Der Webserver kann alles von Webrick sein (was normalerweise passiert, wenn Sie einen Rails-Server von starten das
Befehlszeile) an Apache HTTPD (den Webserver, der den größten Teil des Webs mit Strom versorgt). Der Webserver ist nur ein Vermittler. Er nimmt die Anfrage entgegen und übergibt sie an Ihre Rails-Anwendung. Der die Antwort generiert und weiterleitet, geht zurück an den Server, der sie wiederum an den Server zurücksendet Klient. Der bisherige Fluss ist also:Eine Rails-Anwendung sendet eine Anfrage zunächst über den Router. Jede Anfrage hat eine URL. Diese wird in der Adressleiste eines Webbrowsers angezeigt. Der Router bestimmt, was mit dieser URL zu tun ist, ob die URL sinnvoll ist und ob die URL Parameter enthält. Der Router ist in konfiguriert config / route.rb.
Stellen Sie zunächst fest, dass das ultimative Ziel des Routers darin besteht, eine URL mit einem Controller und einer Aktion abzugleichen (dazu später mehr). Und da die meisten Rails-Anwendungen RESTful sind und Dinge in RESTful-Anwendungen mithilfe von Ressourcen dargestellt werden, sehen Sie Linien wie Ressourcen: Beiträge in typischen Rails-Anwendungen. Dies entspricht URLs wie /posts/7/edit mit dem Posts-Controller wird der bearbeiten Aktion auf der Post mit der ID von 7. Der Router entscheidet nur, wohin die Anforderungen gehen. So kann unser [Rails] -Block etwas erweitert werden.
Nachdem der Router entschieden hat, an welchen Controller die Anforderung gesendet werden soll und an welche Aktion auf diesem Controller, sendet er sie weiter. Ein Controller ist eine Gruppe verwandter Aktionen, die alle in einer Klasse gebündelt sind. In einem Blog wird beispielsweise der gesamte Code zum Anzeigen, Erstellen, Aktualisieren und Löschen von Blog-Posts in einem Controller namens "Post" gebündelt. Die Aktionen sind einfach normal Methoden dieser Klasse. Controller befinden sich in App / Controller.
Nehmen wir also an, der Webbrowser hat eine Anfrage für gesendet /posts/42. Der Router entscheidet, dass sich dies auf die bezieht Post Controller, die Show Methode und die ID des zu zeigenden Beitrags ist 42, so nennt es das Show Methode mit diesem Parameter. Das Show Die Methode ist nicht dafür verantwortlich, das Modell zum Abrufen der Daten und die Ansicht zum Erstellen der Ausgabe zu verwenden. Unser erweiterter [Rails] -Block lautet nun:
Das Modell ist sowohl am einfachsten zu verstehen als auch am schwierigsten zu implementieren. Das Modell ist für die Interaktion mit der Datenbank verantwortlich. Der einfachste Weg, dies zu erklären, ist, dass das Modell eine einfache Reihe von Methodenaufrufen ist, die einfache Ruby-Objekte zurückgeben, die alle Interaktionen (Lese- und Schreibvorgänge) aus der Datenbank verarbeiten. Nach dem Blog-Beispiel sieht die API, mit der der Controller Daten mithilfe des Modells abruft, ungefähr so aus Post.find (params [: id]). Das params ist, was der Router von der URL analysiert hat, Post ist das Modell. Dadurch werden SQL-Abfragen durchgeführt oder es wird alles getan, was zum Abrufen des Blogposts erforderlich ist. Modelle befinden sich in App / Modelle.
Es ist wichtig zu beachten, dass nicht alle Aktionen ein Modell verwenden müssen. Die Interaktion mit dem Modell ist nur erforderlich, wenn Daten aus der Datenbank geladen oder in der Datenbank gespeichert werden müssen. Als solches setzen wir ein Fragezeichen in unser kleines Flussdiagramm.
Schließlich ist es Zeit, HTML zu generieren. HTML wird weder vom Controller selbst noch vom Modell verarbeitet. Der Sinn der Verwendung eines MVC-Frameworks besteht darin, alles zu unterteilen. Datenbankoperationen bleiben im Modus, die HTML-Generierung bleibt in der Ansicht und der Controller (vom Router aufgerufen) ruft beide auf.
HTML wird normalerweise mit eingebettetem Ruby generiert. Wenn Sie mit PHP vertraut sind, dh mit einer HTML-Datei, in die PHP-Code eingebettet ist, ist eingebettetes Ruby sehr vertraut. Diese Ansichten befinden sich in App / AnsichtenEin Controller ruft einen von ihnen auf, um die Ausgabe zu generieren und an den Webserver zurückzusenden. Alle Daten, die vom Controller mithilfe des Modells abgerufen werden, werden in der Regel in einem gespeichert Instanzvariable Diese werden dank Ruby-Magie als Instanzvariablen in der Ansicht verfügbar sein. Außerdem muss Embedded Ruby kein HTML generieren, sondern kann jede Art von Text generieren. Dies wird beim Generieren von XML für RSS, JSON usw. angezeigt.
Diese Ausgabe wird an den Webserver zurückgesendet, der sie an den Webbrowser zurücksendet, wodurch der Vorgang abgeschlossen wird.