Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Artigo Java Magazine 78 - Grails: do Groovy à Web – Parte 4
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.
Java Magazine 78
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 78
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 78
Grails: do Groovy à Web – Parte 4
Alta produtividade no desenvolvimento de aplicações web
Conhecendo o GORM: a camada de persistência do Grails
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.
Configurando o acesso ao SGBD
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.
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"
}
}
}
Bloco environments
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 .
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 {
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Alta produtividade no desenvolvimento de aplicações web
Conhecendo o GORM: a camada de persistência do Grails
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.
Configurando o acesso ao SGBD
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.
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"
}
}
}
Bloco environments
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 .
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 {
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Você está em:
canal Java
Publicidade
Henrique Lobo Weissmann
Space do autor
É consultor Groovy/Grails, fundador do Grails Brasil e sócio da itexto Desenvolvimento de Projetos, que atua na criação de projetos adotando software livre e muito Grails.
Space do autor
0
0
