Die Welt spricht Ruby, egal wie oft sie dabei Rails sagt. Tatsache ist, dass Rails längst sicher nicht die Lösung aller Dinge der Rubywelt ist. Trotz allem darf man ihm seine Effizienz in der Entwicklungsarbeit nicht absprechen.
Und so wär es auf jeden Fall einen Blick darauf Wert, wie Rails diese Effizienz eigentlich erreicht und darüber nach zu denken, inwiefern man diese Erkenntnis in die Arbeit einfließen lassen kann.
Die Effizienz erreicht Rails zum einen durch die Verwendung des MVC-Entwufsmusters und die Einhaltung einiger wenigen strikter Prinzipien.
MVC-Entwurfsmuster
MVC steht für Model-View-Controller und ist ein seit langem bewährtes Muster der Softwareentwicklung, in dem es darum geht die Geschäftslokig von ihrer Präsentation zu trennen und eine Schnittstelle zwischen den beiden verfügbar zu machen.
Das Model ist dafür zuständig die Geschäftslogik festzuhalten und stellt somit quasi den Zustand des System dar. Es macht dabei nichts anderes, als mit Daten zu handeln. Es validiert und speichert die Daten um dann Methoden verfügbar zu machen, die Daten auch wieder abzufragen.
Die Modelle werden durch die Datenbankabstraktion zur Verfügung gestellt, wobei Object-Relationship-Mapping zum Einsatz kommt. Jedes Modell stellt eine Klasse dar und wird auf eine Tabelle der Datenbank gemappt.
Somit stellt jede Zeile der Datenbank ein Objekt dieser Klasse dar. Die Klasse stellt nun alle nötigen Getter-, Setter- und Valdierungsmethoden als Klassenmethoden zur Verfügung.
Der Controller ist ebenso eine Klasse, die als Schnittstelle zwischen dem Model und dessen Präsentation dienen soll. Zu jedem Modell steht ein eine Controllerklasse zur Verfügung, welcher die Klassenmethoden des Modell nutzt um Actions und Helper zu erstellen.
Eine Action wird immer dann ausgelöst, wenn der User in der Präsentationsschicht in irgendeiner Form mit den Modellen interagiert.
Hinter jedem dieser Action-Aufrufe steht ein Callback in dem alle Variablen für die Präsentation gesetzt, alle nötigen Methodenaufrufe für die Aktion gestartet und schließlich der Returnwert, meist in Form der Präsentation, an den User zurückgeliefert werden.
Die View steht dabei für die Präsentationsschicht. Sie stellt alle Möglichkeiten für den Anwender mit der Applikation zu kommunizieren dar.
Sie nutzt, die in ihrer Action gesetzten Variablen und die Helper, die der Controller zur Verfügung stellt, innerhalb einer Umgebung, welche die Darstellung übernimmt, also beispielsweise die Template-Engine.
Das DRY-Prinzip
DRY steht für 'Dont repeat yourself' und erklärt sich eigentlich schon fast von selbst. Man sollte jeden Sachverhalt genau einmal programmieren und diese Lösung dann als Resource im System zur Verfügung zur stellen. Die strenge Objektorientierung in Ruby stützt diesen Ansatz, stellen Klassen und ihre Instanzen gepaart mit den Methoden doch ein optimales Fundament dafür, wiederverwertbaren Code zu schreiben.
Bei dieser Idee geht es sehr viel weniger um Faulheit als um Übersicht und Wartbarkeit. Eine Sache die nur an einer Stelle programmiert wurde, muss bei Bedarf auch nur an einer Stelle geändert werden.
Konvention über Konfiguration
Wenn man sich darauf einigen würde, dass die Entwicklungsumgebung immer "Development" heißt und ferner noch dass die Datenbank zu einer Umgebung immer nach der Datenbank benannt wird, hätte man es schon geschafft eine Arbeitsumgebung zu schaffen in der jeder Teilnehmende zu jeder Zeit wissen sollte wo er eigentlich gerade ist.
Wenn darüber hinaus vereinbar würde, dass eine Datenbanktabelle als Namen immer die Pluralform des zugehörigen Models bekommt, würde man immer genau wissen woran man gerade arbeitet.
Gleichzeitig könnte man programmatisch eine Automation erschaffen, die einem genau diese Vorgänge, die immer die gleichen sind, abnimmt und hätte wieder Zeit für die Entwicklung der Applikation anstatt sich mit Konfigurationsdateien und ähnlichen Scheuslichkeiten auseinander zu setzen.
Wie sich diese Punkte mit welchen Werkzeugen umsetzen lassen, werde ich in den kommenden Wochen hier erörtern. Wir werden Sinatra, den Datamapper, Haml und Sass ebenso erforschen wie Rspec und die aufregende Welt des Test-Driven-Developments.
Ich freue mich schon auf diese spannende Reise. Aber zuerst freu ich mich auf sieben Tage Segelurlaub.
Keine Kommentare:
Kommentar veröffentlichen