Seite 4: Testen, Modularisierung, Fazit

Inhaltsverzeichnis

Automatisiertes Testen

Beide Frameworks ermöglichen Unit- und Integrationstests, erzeugen ein rudimentäres Test-Codegerüst beim Generieren von Klassen und liefern eine gesondert konfigurierbare Testumgebung. Rails stellte Tests von Anfang an in den Vordergrund. Seit Version 4.0 nutzt es MiniTest als Test-Framework, aber auch andere Langzeit-Alternativen wie Rspec sind möglich. Grails hingegen setzt auf den populären Vertreter Spock. Ein Beispiel für einen Unit-Test sähe damit etwa wie folgt aus:

def "Länge der Strings"() {
    expect:
      name.size() == length

    where:
      name     | length
      "PHP"    | 3
      "Java"   | 4
      "Groovy" | 6
}

Allerdings lassen sich auch Legacy-Grails-Tests und reine JUnit-Tests durchführen, was in der Praxis zu Durcheinander bei den diversen Annotationen, Code-Mixins, Ableitungen und Mock-Möglichkeiten führen kann.

Modularisierung, Caching und Sicherheit

Während sich vor ein paar Jahren noch jedes halbwegs ernstzunehmende Webframework nur mit aufgeblasenem Feature Sets sehen (und vergleichen) lassen konnte, ist dieser Trend inzwischen gegenläufig: Mit jedem Major Release werden altgediente Kernkomponenten in Frage gestellt und in optionalen Modulen weiterentwickelt. Rails hat sein Modularisierungskonzept noch weiter in Ruby-Gems und Engines unterteilt, wobei man sich letztere wie eine Art Mini-/Standalone-App vorstellen kann, die sich in eine Hauptanwendung einbinden (mounten) lässt. Grails bietet entfernt Vergleichbares nur über seinen Plug-in-Mechanismus oder verlinkte Bibliotheken. In der Praxis unterteilt man monolithische Applikationen jedoch eher in Services auf App-Ebene und lässt sie beispielsweise über REST APIs kommunizieren.

Caching ist einer der komplizierteren Aspekte der Informatik und so bieten Rails und Grails vom SQL Query bis hin zu komplett gerenderten HTML-Seiten diverse Caching-Möglichkeiten innerhalb des Framework-Stacks. Dabei kann In-Memory als Standardoption gelten, allerdings lässt sich auch auf die üblichen Cache Stores wie Ehcache oder Redis zurückgreifen. Grails sorgt mit Annotationen und seiner Spring Bean DSL für mehr Übersichtlichkeit, um Methoden-Rückgaben besser im Cache zu lagern als es der programmatische Ansatz von Rails vorgibt.

Eine Verbesserungen in Rails 4 lässt sich bei verschachtelten Caches (Russian Doll) finden:

# :touch updated auch den parent-cache (Campaign model)
class Campaign < ActiveRecord::Base
  has_many :activities
end

class Activity < ActiveRecord::Base
  belongs_to :campaign, touch: true
end

Auch wenn in beiden Frameworks Filter zur Authentifizierung und Autorisierung leicht selbst implementiert sind, werden viele Entwickler dieses sensible Thema gern an ein gereiftes Plug-in abgeben wollen. Das Devise Gem ist ein solches und wird über Mixins in die Rails-Modelklasse eingebunden, sodass beispielsweise im Controller ein authenticate_user! ausreicht. Grails hat mit Spring Security nur eine ernstzunehmende, aber sehr umfangreiche Alternative. Das Grails-Plug-in hilft mit vereinfachter Konfiguration sowie einer DSL und bietet zudem etliche Erweiterungen (zum Beispiel für OAuth oder LDAP).

Flügeltüren in der Aufpreisliste - ein Fazit

Während die Java-Community schon immer seriös und unternehmenssorientiert daher kommt, sind Nutzer und Entwickler von Groovy und Ruby mehrheitlich pragmatisch und geben sich nur ungern mit umständlichen Workflows zufrieden. Der Umgang mit beiden Sprachen und Frameworks macht durch ihre zumutbare Lernkurve und ihre pragmatisch-tolerante Art von Anfang an Spaß. Natürlich muss man sich dabei auf das jeweilige Framework einlassen, die Ideen und Entscheidungen dahinter akzeptieren und nicht dagegen arbeiten.

Ruby ist eine ausgereifte Programmiersprache, die zusammen mit den Rails-Spracherweiterung und den JRuby-Möglichkeiten nur noch besser wird. Rails ist über die Jahre gereift und eben kein kurzlebiger Modetrend mit Kinderkrankheiten mehr. Zur richtigen Zeit, nämlich als Webentwicklung noch wirklich schmerzhaft war, konnte es mit prominenten Anwendungen und guter Community-Arbeit einen bis heute andauernden guten Ruf aufbauen. Dem Rails-Entwicklungsteam, vor allem Hansson, sagt man allerdings auch Arroganz und Engstirnigkeit bei Entscheidungen nach. Ähnlich wie in der PHP-Entwicklung unterschätzen viele gelegentlich die Einfachheit von Rails, und ordentliches Design der Komponenten und Schnittstellen wird besonders in großen oder wachsenden Projekten vernachlässigt.

Eines der größten Argumente, das für Grails spricht, ist Groovy. Die Sprache vereinfacht den Einstieg – gleichermaßen für Ruby- und Java-Entwickler – und die sich durch die Java Virtual Machine ergebenden Vorteile sind gewaltig. Sicherlich, die Community ist kleiner und Grails jünger, dafür haben deren Anwender und Entwickler oftmals ein vertieftes Java-Wissen und kennen daher viele der unter der Haube eingesetzten Techniken bereits. Gerade dieser Zweckverband der besten und umfangreichsten Java Tools macht es nicht gerade zu einem schlanken Framework und ein Austausch von Komponenten ist oftmals nicht vorgesehen oder scheitert an echten Alternativen.

Grails hat im direkten Vergleich ein engeres Korsett an Konventionen und zwingt den Entwickler, mehr über die Strukturierung seiner Anwendung nachzudenken. Wie bei Ruby ist die "Magie", die in allem zu stecken scheint, Segen und Fluch zugleich. Zudem ist die Zukunft nach dem Ausscheiden von Pivotal als Sponsor für Groovy und Grails ungewiss.

Gibt es einen klaren Gewinner? Nein, vielmehr hängt die Entscheidung für oder gegen eines der vorgestellten Frameworks vom Projekt und seinen Rahmenbedingungen ab. Sollen Java-Entwickler mitarbeiten, die möglicherweise unerfahren mit dynamischen Sprachen sind, dafür aber fit mit Spring & Co., oder gibt es bereits eine signifikante Menge JVM-Code, geht die Empfehlung in Richtung Groovy und Grails. Umgekehrt, wenn die JVM kein Muss ist und Ruby-Vorkenntnisse und -Bibliotheken zum Einsatz kommen, spricht das eher für Ruby und Rails.

Und um es ein letztes Mal im Jargon der Autozeitschrift zu sagen: Rails ist das Webframework mit kraftvollem Turbolader und langer Aufpreisliste, während Grails eher ein vollausgestattetes Sondermodell mit großem Hubraum präsentiert. Schnelles Kurvenfahren ist mit beiden möglich.

Dirk Lingstädt
ist Senior Consultant bei der innoQ Deutschland GmbH. Er beschäftigt sich mit administrativen Aufgaben (Software Rollouts etc.) und der Web-Entwicklung mit Ruby on Rails oder Grails. (jul)