Artigo Java Magazine 78 - Grails: do Groovy à Web – Parte 4

[lead]De que se trata o artigo:

Veremos com detalhes o funcionamento do GORM, a camada de persistência adotada pelo Grails. Abordaremos temas que vão desde o básico – pesquisa, inserção, edição e exclusão de registros – até o uso avançado do framework listando questões relativas à performance e consumo de recursos.

Para que serve:

Em uma aplicação Grails é quase que inevitável a existência de classes de domínio cuja persistência é gerenciada pelo GORM. Sendo assim, nada mais natural que a necessidade de conhecermos bem este componente central do framework.

Em que situação o tema é útil:

GORM torna a persistência uma tarefa trivial: buscar e incluir informações em uma base de dados acaba por aparentar-se fácil demais. No entanto, é importante conhecer os detalhes deste componente para evitar possíveis armadilhas que surgem conforme nossos projetos vão se tornando mais complexos.

Grails do Groovy à Web – Parte 4:

Neste artigo conheceremos desde o básico sobre o funcionamento do GORM – pesquisa e alteração de dados em uma base de dados – até detalhes mais complexos do seu funcionamento, como gerência de isolamento, eventos e configurações finas do mapeamento objeto-relacional. Ao final de sua leitura o leitor estará apto a trabalhar com o GORM, além de possuir o background necessário para lidar com situações mais complexas. [/lead]

Grails é um framework full stack, ou seja, o desenvolvedor não precisa inicialmente se preocupar com os componentes básicos de infraestrutura, como persistência, logs, etc. em sua aplicação por já virem pré-configurados com o próprio framework.

Em nosso caso, o componente responsável pela persistência dos dados no SGBD é o GORM – Grails Object Relational Mapping – que, como o próprio nome já diz, trata-se de uma ferramenta ORM. Arquiteturalmente, ele consiste em uma fina camada escrita em Groovy posicionada sobre o Hibernate 3, como pode ser visto na Figura 1.

Esta abordagem de implementação tem suas vantagens:

• Desenvolvedores acostumados a trabalhar com Hibernate terão uma curva de aprendizado menor;

• Ao usar como base um componente maduro e de eficácia comprovada como o Hibernate, os desenvolvedores do Grails não precisaram reinventar a roda, apenas torná-la mais próxima dos programadores Groovy.

Figura 1. GORM dentro da arquitetura de persistência de uma aplicação Grails.

[subtitulo]Configurando o acesso ao SGBD[/subtitulo]

Por default, o Grails vem pré-configurado para trabalhar com o HSQLDB. Nesta pré-configuração o SGBD armazena os dados apenas em memória. Obviamente, esta não é a solução ideal, visto que a cada reinicio da aplicação os dados são perdidos. Para alterar o SGBD default, é preciso executar duas operações:

1. Copiar os arquivos JAR do driver JDBC do SGBD escolhido para o diretório lib da aplicação;

2. Editar o arquivo grails-app/conf/DataSource.groovy.

[nota]O HSQLDB é um excelente SGBD inteiramente escrito em Java, o que o torna ideal quando se precisa embutir um servidor de banco de dados em suas aplicações. Mais informações podem ser obtidas no site oficial: www.hsqldb.org. [/nota]

Neste artigo iremos trabalhar com o MySQL, porém o procedimento é o mesmo para qualquer SGBD.

Na Listagem 1 podemos ver como é o arquivo DataSource.groovy em seu estado original, isto é, logo após criarmos uma nova aplicação com o comando grails create-app. Nele, podemos verificar três blocos de código: dataSource, hibernate e environment.

Listagem 1. O arquivo grails-app/conf/DataSource.groovy original.

  dataSource {
   pooled = true
   driverClassName = "org.hsqldb.jdbcDriver"
   username = "sa"
   password = ""
 }
  hibernate {
   cache.use_second_level_cache=true
   cache.use_query_cache=true
   cache.provider_class='net.sf.ehcache.hibernate.EhCacheProvider'
 }
  environments {
   development {
     dataSource {
       dbCreate = "create-drop"
       url = "jdbc:hsqldb:mem:devDB"
     }
   }
    test {
     dataSource {
       dbCreate = "update"
       url = "jdbc:hsqldb:mem:testDb"
     }
   }
    production {
     dataSource {
       dbCreate = "update"
       url = "jdbc:hsqldb:file:prodDb;shutdown=true"
     }
   }
 }

[subtitulo]Bloco environments[/subtitulo]

Vamos iniciar a nossa análise de baixo para cima. O bloco environments contém os três ambientes de execução padrão adotados pelo Grails: development, que é usado enquanto estamos desenvolvendo nossa aplicação; test, usado na execução dos testes unitários e de integração; e production, adotado quando fazemos o deploy do nosso projeto em um servidor Java EE compatível.

[nota]No período da escrita desse artigo o Grails era compatível com os principais servidores Java EE/Servlets do mercado, como Tomcat, JBoss, WebSphere, Glassfish e Jetty. [/nota]

Se for necessário, é possível adicionar novos ambientes de execução. Para isso, basta incluir um novo bloco de código dentro da seção environment, tal como pode ser visto na Listagem 2. Para executar os comandos do Grails na linha de comando em um ambiente específico, basta usar a sintaxe abaixo:

  grails [nome do ambiente] comando
 exemplo: grails opcional run-app 

Listagem 2. Incluindo ambientes de banco de dados adicionais.

  environments {
   development {
     dataSource {
       dbCreate = "create-drop"
       url = "jdbc:hsqldb:mem:devDB"
     }
   }
    test {
     dataSource {
       dbCreate = "update"
       url = "jdbc:hsqldb:mem:testDb"
     }
   }
    production {
     dataSource {
       dbCreate = "update"
       url = "jdbc:hsqldb:file:prodDb;shutdown=true"
     }
   }
    opcional {
     dataSource {
       dbCreate = "update"
       url = "jdbc:hsqldb:file:prodDb;shutdown=true"
     }
   }
 } 

Em cada ambiente há por default duas chaves de configuração: url e dbCreate. A primeira é a URL de conexão com o SGBD, enquanto a segunda especifica qual o comportamento a ser adotado na base de dados com relação à criação/edição do esquema de dados. Os valores possíveis para esta chave encontram-se listados na Tabela 1.

Tabela 1. Valores possíveis para a propriedade dbCreate.

[nota]Se você estiver trabalhando com uma base de dados legada que não possa ter sua estrutura alterada, exclua a propriedade dbCreate do ambiente em questão. [/nota]

[subtitulo]Bloco dataSource [/subtitulo]

Neste bloco encontram-se as configurações básicas de acesso ao banco de dados que são compartilhadas por todos os ambientes de execução. Suas chaves de configuração estão descritas na Tabela 2.