Eignet sich Grails auch für „große“ Projekte?

In dem Blog mit dem Titel „Why use Grails“ [1] sind sehr gut die Gründe aufgeführt, die meines Erachtens für Grails sprechen. Wir setzen seit mehreren  Jahren Grails erfolgreich ein und  sind vor allem von der Schnelligkeit begeistert, mit der es möglich ist – im Vergleich zur herkömmlichen JEE Implementierung – Applikationen zu entwickeln. Dennoch entdecke ich immer wieder Artikel, die die Aussage treffen, dass sich Grails nur für „kleine“  Projekte eignet. Hier meine Meinung zu Punkten, die ich öfters lese:

• Skalierbarkeit:
  Die Skalierbarkeit von Grails-Applikationen wird des Öfteren bemängelt. Natürlich gibt es sehr viele Beispiele von Vorzeigeprojekten [2] bei denen es offensichtlich keine Probleme gab. Grails ist wie jedes andere Web Framework für eine gute Skalierbarkeit entworfen worden. In Grails selbst können natürlich – wie bei jeder anderen Software – auch Bugs enthalten sein. So ist im Zusammenhang mit Performanz ein Tag-Lib-Problem bei Grails bekannt geworden,  dies wurde inzwischen gefixt.
  Es kann nur empfohlen werden, schon während der Entwicklung Lasttests durchzuführen, um die Architektur auf Skalierbarkeitsaspekte hin zu überprüfen. Dies machen wir auch bei herkömmlichen JEE-Applikationen, die wir neben Grails auch noch mit JEE (JPA, EJBs, Servlets, JSPs, JSF etc.) entwickeln.  Auch bei klassischen JEE-Applikationen mussten wir  schon des Öfteren unseren Sourcecode umbauen, da die anfängliche Implementierung nicht performant genug war. Da Grails auf Spring und Hibernate basiert, sollte sich immer ein Weg finden, um die Performanz zu optimieren. Notfalls direkt mit Java beziehungsweise Hibernate.
• Testbarkeit:
  Hier wird oft bemängelt, dass eine Grails Applikation nicht so einfach zu testen sei, da Groovy benutzt wird. Groovy ist eine dynamische Sprache und somit können Fehler erst zur Laufzeit auffallen, da hier – nicht wie bei Java – schon während  der Compilierung etwaige Probleme gefunden werden können. Grails bringt schon von Haus aus die Möglichkeit mit, JUnit-Tests zu entwickeln. Eine weitere Möglichkeit stellt das Tool Cobertura dar, mit dem es möglich ist, die Test-Coverage des Source-Codes zu bestimmen. Hier sei vielleicht folgender Blog [3] zu empfehlen. Benötigen Teile des Systems eine 100% Test-Coverage so können diese auch in Java entwickelt werden. Ein weiterer Punkt sollte nicht vergessen werden – mit Groovy wird ein kompakterer Code geschrieben, demzufolge sollte dieser auch weniger Fehler enthalten.
• Teamgröße:
  Ich habe neulich in einem Blog gelesen, dass Grails nicht für Teams > 5 Programmierer geeignet ist. Diese Aussage ist mir vollkommen schleierhaft. Geht man bei Grails von einer Produktivitätssteigerung vom 3-4 fachen – im Vergleich zu einem JEE Team – aus, so würde ein 5 Mann starkes Grails-Team ein 15-20 Mann starkes JEE Team ersetzten. Dies ist schon eine Teamgröße, mit der sich etwas bewerkstelligen lässt. Soll von noch größeren Teams ausgegangen werden, so ist es wohl immer auch eine Frage des Projektmanagers und des Architekten, wie so ein Projekt in Module aufgeteilt wird, die dann von den einzelnen Teams implementiert werden können. Bei Grails könnte man sich auch vorstellen, solche Module in Form von Plugins abzubilden.  Des Weiteren ist meiner Meinung nach die von Grails vorgegebene Projektstruktur ein klarer Pluspunkt, insbesondere wenn bedacht wird, dass es einfacher wird neue Entwickler in das Team zu integrieren, da einem Grails-Entwickler diese Struktur bekannt ist und er sich nicht in eine neue Struktur einarbeiten muss.
• Komplexität:
  Ein großer Vorteil von Grails ist das Paradigma „Convention over Configuration“.  Dies kann jedoch auch den Eindruck erwecken, dass nicht hochkomplexe Applikationen erstellbar sind, da man nicht alle Freiheitsgrade wie bei JEE vorfindet. Generell gilt auch hier, dass alles, was mit Spring/Hibernate funktioniert auch mit Grails funktioniert. Wird seitens des Projekts jedoch die Unterstützung von EJBs gefordert so muss der JEE Weg beschritten werden.
• JEE  6:
  Durch die Einführung von JEE 6 wird auch häufig diskutiert, ob es noch Frameworks wie Grails bedarf. JEE 6 stellt gegenüber seinem Vorgänger klare Verbesserungen – beispielsweise durch die Einführung des Paradigma „Convention over Configuration“ – dar, jedoch muss man JEE 6 mit dem Gesamtpaket von Grails [1] vergleichen. Meine Meinung  hier ist, dass Grails hier immer noch einige interessante Vorteile bietet. Hierbei zählt für mich auch die Sprache Groovy.

Fazit
Ich hoffe, es ist mir gelungen, ein paar Vorurteile gegenüber dem Einsatz von Grails bei „großen“ Projekten aus dem Weg zu räumen. Dennoch möchte ich mich hier auch nicht festlegen, was der Königsweg ist. Dies muss für jedes Projekt erneut entschieden werden. Aber gerade für Projekte, die sehr budgetsensitiv sind, führt meines Erachtens kein Weg an Grails vorbei. Früher hätte man JEE (oder genauer J2EE) auch nicht zugetraut, dass auf dieser Plattform einmal geschäftskritische Applikationen laufen.

[1] Why use Grails?
[2] Grails Testimonials
[3] Grails Test-Coverage

Domain-Modellierung in GORM, Tipps/ BestPractices

Grails Domain Klassen sind Grundbausteine und enthalten die Datenstrukturen und Zuständen einer Geschäftsanwendung.
Die Domain-Modellierung ist ein wichtiger Bestandteil des Grails Object Relational Mappings (GORM).

In den vergangenen Grails Projekten, die in der Produktionsumgebung eine Oracle-Datenbank benutzen, finden einige Arbeitschritten zur Domain-Modellierung in derselben Art regelmäßig wiederkehrend statt.

Diese routinemäßigen Schritte möchte ich nun anhand eines Beispiels beschreiben:

package com.exensio.myapp.helper;
public class Constants {
    public static final String DB_PREFIX = "MYAPP_"; // 1
}

abstract class AbstractEntity implements Serializable { // 2
    Date    dateCreated // 3
    Date    lastUpdated // 4
    Integer    version // 5
}

class Project extends AbstractEntity { // 6
    String title

    static mapping = {
        table   Constants.DB_PREFIX + "project" // 7
        id      generator: "native", params:[ sequence: Constants.DB_PREFIX + "project_id_seq" ] // 8
        sort "title" // 9
    }
    String toString() { title } // 10
}

Tabellen-/Sequenzen- Namen bei dem DB-Mapping

Aus folgenden Gründen wird in dem obigen Beispiel (Punkten-1,7,8) ein DB-Präfix verwendet:

• Wie die meisten Datenbank-Systeme hat Oracle vordefinierte Schlüsselwörter, die nicht als Tabellen-/Sequenz- Namen verwendet werden dürfen. Mit einem Präfix kann dies Problem vermieden werden.
• Das Präfix ermöglicht die Verwendung eines gemeinsamen DB-Schemas mit weiteren Applikationen.

Automatisches Timestamping

Die Idee ist, automatisch einen Zeitstempel bei einer schreibenden DB-Operation zu setzen. Technisch wird dies mittels zwei GORM-Events: "beforeInsert" und "beforeUpdate" realisiert.
Als Grails-Entwickler hat man hier Glück, da mann den Konventionen folgen kann und zwei Attributen (wie Punkte-3,4 im Beispiel) definiert.

Erläuterung der einzelnen Punkten: 

1. DB-Präfix der Applikation, siehe auch Punkt-7
2. Eine abstrakte Basisklasse, die das Interface Serializalbe implementiert
3. Automatisches Timestamping, per Namenskonvention aktualisiert GORM die zwei Attribute("dateCreated" und "lastUpdated") bei entsprechenden Ereignissen
4. Automatisches Timestamping, siehe auch Punkt-3
5. Das "Version" Attribut( ähnlich wie bei der JPA Annotation: @Version), das von GORM zum "Optimistischen Locking" verwendet wird
6. Eine Grails Domain Klasse, durch die Vererbung verfügt es über alle Eigenschaften seiner Basisklasse
7. Name der DB-Tabelle "MYAPP_PROJECT". Dieses Verfahren ermöglicht zum einen die Verwendung eines gemeinsamen DB-Schemas mit weiteren Applikationen, zum anderen wird hierdurch vermieden, dass ein von der Datenbank reserviertes Schlüsselwort als Tabellenname  verwendet wird.
8. Name der DB-Sequenz "MYAPP_PROJECT_ID_SEQ". Diese hat die gleiche Funktion wie der Tabellename von Punkt-7
9. Defaultmäßige Sortierung nach "Title" in einer List von Projekten
10. Defaultmäßige String-Repräsentation für ein Objekt der Domain Klasse.