Viva la evolución!

Det språk och ramverk som i det här sammanhanget har ojämförligt högst profil är förstås Ruby och Rails, som är ett oerhört lättfotat och uttrycksfullt ramverk för att i första hand bygga ganska raka webbgränssnitt ovanpå en databas. Rails, och även Ruby med tillhörande bibliotek, utvecklas i rask takt mot bredare kompetens även om det ännu inte täcker in allt som finns inom Java EE. I den här artikeln ska vi titta lite närmare på ett högintressant projekt som heter Grails, ett Java- och Groovybaserat projekt som har en hel del likheter med Rails, men också en del viktiga skillnader som gör det väldigt intressant för Javautvecklare.

Grails, som i skrivande stund är väldigt nära att släppa version 1.0, är Apache-licenserat och har utvecklats sedan början på 2006 under ledning av framför allt Graeme Rocher. Groovyprofilen Guillaume Laforge var inblandad i projektets tillkomst, och nyligen startades företaget G2One av Graeme, Guillame och Alex Tkachman från Jetbrains för att tillhandahålla kommersiell support för Groovy och Grails. Upplägget liknar förhållandet mellan Spring och Interface21.

Vad som gör Grails speciellt är att det inte är ett från grunden nytt ramverk, utan snarare ett slags dynamiskt "klister" mellan ett antal beprövade Java-ramverk:

• Spring, för hantering av beroenden (dependency injection), transaktioner och MVC-webbramverket, och mycket annat,
• Hibernate, för domänmodell-till-databas-mappning (Object-Relational Mapping).
• Sitemesh, för dekoration av vyer.

Därutöver finns ett system för plugins, som snabbt växer i antal. Indexmotorn Lucene, schemaläggaren Quartz och säkerhetsramverket Acegi är tre exempel där det finns plugins. Själva Grailsplattformen består till ca 80 % av Javakod och 20 % Groovy.

Det här medför att det är väldigt lätt att integrera med befintliga Javakomponenter och -bibliotek, eller över huvud taget vad som helst som går att exponera som en böna i en Spring-kontext. Groovy har ju som bekant heller inga problem att anropa Java. Dessutom får man omedelbart tillgång till all den kraft och flexibilitet som finns i exempelvis Hibernate, med cachning och mappning mot gamla och komplicerade databasschema, drivrutiner och dialekter för obskyra databaser och så vidare. Slutligen blir steget inte särskilt långt för den som redan är bekant med något eller flera av de här ramverken - och det är rätt många - när man kan utnyttja mycket av den kunskap redan har.

Så hur är det då att utveckla i Grails? Den som tittat på Ruby on Rails kommer att känna igen en del saker, exempelvis har man tre profiler: utveckling, test och produktion, med var sin datakälla bland annat. Dessutom finns samma typ av scaffolding-funktionalitet, som givet en entitet i en domänmodell (eller en tabell i databasen, i Rails fall) automatiskt kan skapa MVC-controller och vyer för de vanliga CRUD-operationerna (skapa, läsa, uppdatera, radera) samt listning och paginering. I huvudsak kan man också se ändringar omedelbart efter en omladdning i webbläsaren utan att ladda om applikationen, förutom när man gjort förändringar i domänmodellen. En viktig skillnad i Grails är dock att man driver domänmodellen från Groovy-klasserna och låter Hibernate generera schemat, istället för att skriva databasdefinitionen för att skapa domänklasserna.

Persistens och domänmodell

class Person {
  String name
}

class Person {
  String name

  static constraints = {
    name(range:4..100,match:"^[A-Z][a-z]*$")
  }
}

def p = Person.find(1)
p.name = "Newname"
p.save()

def peters = Person.findByNameOrderByAge("Peter")

"from Person where name = ? order by age"  

Alla typer av relationer mellan domänklasser stöds, och om man exempelvis säger att en person har ett hus och flera husdjur, ser det ut så här:

class Person {
  String name
  House house
 
  static hasMany = [pets : Animal]
}

...
List pets
static hasMany = [pets : Animal]

Transaktioner

class PartnershipService {
  static transactional = true

  void marryTwoPeople(Person one, Person theOther) { ... }
}

class Person {

  PartnershipService partnershipService

  void marry(Person partner) {
    partnershipService.marryTwoPeople(this, partner)
  }

}

Person adam, eve, steve
[...]

Person.withTransaction { tx ->
   adam.divorce(eve)
   adam.marry(steve)
   if (anyObjections()) {
     tx.setRollbackOnly()
   }
}

Webblagret

class PersonController {
  def scaffold = Person
}

def namesakes = {
    def p = Person.get(params.id)
    def ns = Person.findByName(p.name).minus(p)
    [person:p, namesakes:ns]
}

Alla Grails-controllers jobbar med ModelAndView-konceptet i Spring MVC, med ett antal konventioner för att förenkla returvärdena. I exemplet ovan kommer vynamnet "namesakes" att användas, eftersom inget annat sägs. Ett annat centralt begrepp i webblagret är render-metoden, som är en oerhört kraftfull allt-i-allo för att  generera innehåll.  Den kan användas för att rätt och slätt skriva text:

render "Hello"

 render(view:"friendsOf",model:[person:Person.get(params.id)])

render(contentType:"text/xml") {
  people(count:Person.count()) {
    Person.list().each { p->
      person(name:p.name, p.storyOfMyLife())
    }
  }
}

<people count="3">
  <person name="Peter Backlund">I was born in 1977...</person>
  [...]
</people>

Det finns även stöd för default-action, kedjning och redirect mellan olika actions. Grails har en variant av taglibs, som man kan använda tillsammans med Groovy-scriptlets i vyerna, eller så kan man men lite knep och knåp konfigurera det underliggande Spring MVC-ramverket att använda Velocity- eller Freemarkermallar, exempelvis. Vill man styra webbapplikationen med hjälp av flöden kan man utnyttja Spring Web Flow, återigen genom att använda builders för att formulera tillstånd och transformationer.

Verktyg och drift

Grails kan paketeras och driftas precis som vilken Javaapplikation som helst, genom det förberedda kommandot "grails war". Tillsammans med det faktum att Hibernate används som ORM betyder det att man omedelbart kan dra nytta av de investeringar man gjort i applikationsserver och databas, både i form av pengar och erfarenhet. Dessutom kan man utnyttja mogna och högpresterande skalbarhetslösningar för HTTP-sessionsreplikering och annat.

Prestandan hos en Grailsapplikation kommer av naturliga skäl aldrig att överstiga den hos Java, och på grund av ramverkets filtiga utnyttjande av dynamiska lösningar kommer det i praktiken att ligga en bit efter. Det är inte heller särskilt besvärligt att skriva om identifierade flaskhalsar i Java, om man skulle behöva. Många är förstås nyfikna på hur Grails står sig i förhållande till Ruby on Rails, och det ser lovande ut - tidiga, enkla tester visar ett betydande övertag för Grails. Det här är förstås någonting som varierar med tiden och med uppgiften, så det är väldigt svårt att säga att den ena alltid är snabbare än den andra, men sannolikt behöver man inte välja bort Grails på grund av sämre prestanda.

Samlade intryck

Alldeles oavsett vilket fotfäste Ruby on Rails kommer att få inom de närmaste åren, så har dess blotta existens mer eller mindre tvingat den 400 kg tunga Java-gorillan att rannsaka sig själv ur ett enkelhets- och produktivitetsperspektiv. När rädslan, osäkerheten och tveksamheten klingar av så börjar man fråga sig hur kan det vara så enkelt för dem, när det är så besvärligt för oss? En sak som ska sitta i ryggraden hos varje programmerare är att duplicering är dåligt, så det känns intuitivt fel när man måste säga "person" på 6-7 ställen för att komma från webbläsaren till databasen. En annan grundbult inom programmering är att ju mindre kod man behöver för att utföra en uppgift, desto bättre. Mindre kod att läsa, förstå, förändra, underhålla och testa. Och förstås att skriva. På den här punkten har Java fått svår konkurrens av språk som Ruby och Groovy, bland andra.

Det viktigaste är att vi som utvecklare hela tiden strävar efter att öka vår produktivitet, och att vi har roligare och roligare på jobbet under tiden.