Olá Joás,

Embora seja novato no Grails, pelo meu entendimento não há restrições para a utilização de Criterias. 

Porém sua utilização torna-se imprescindível quando o critério de sua busca for complexo para fazê-la com os findres.

Abraço

Oi Joás,

quando usar: situações nas quais você vai escrever uma busca mais dinâmica, ou seja, quando vão ser incluídos ou não uma série de condições na sua consulta , tal como fazemos, por exemplo, em um formulário de busca composto. Um bom exemplo você pode ver no exemplo abaixo, em que a função faz a busca por funcionários de acordo com os parâmetros passados:

def buscarFuncionarios(String nome, String cidade, String departamento) {
    Funcionario.withCriteria {
            if (nome) {
                 ilike 'nome', "%${nome}%"
             }
           if (cidade) {
                 cidade {
                          ilike "nome", "%${cidade}%"
                    }
          }
         if (departamento) {
                 departamento {
                              ilike "nome", "%${departamento}%"
                   }
        }
    }
}

Este é um dos usos. Quando você precisa buscar em componentes aninhados, como no exemplo acima, também é uma forma bastante interessante de se montar a consulta, o que você não conseguirá com finders dinâmicos.

Resumindo: quando você ver uma consulta que vai ser escrita concatenando-se strings, pense em criterias.

Quando não usar: quando a busca for muito simples, você pode resolver isto usando um finder dinâmico.

Quando usar o HQL: quando precisar de todo o poder do Hibernate, e as buscas que você for realizar forem REALMENTE complexas.

Concordo contigo Pedro Gentil.

Excelente explanação Kiko.

Uma observação importante é que quando usamos consultas com associações aninhada como no seu exemplo é aplicado eager loading.

Uma coisa que não vi nas criterias e uso muito no HQL é o "exists"

Tem esse excelente post que explica as várias formas de executar consultas no Grails e que "funcionalidades" cada uma atende: http://tatiyants.com/how-and-when-to-use-various-gorm-querying-options/. Só discordo do autor que na tabela comparativa ele coloca que não é possível implementar result sets arbitrários com criterias, mas é possível.

Olá pessoal,

Estou com uma duvida, eu sou novo também em grails e é sobre as Criterias, antes de começar a estudar e a desenvolver em grails eu usava JDBC puro (tédio) e no meu SGBD eu sempre montava as famosas Views para facilitar minha vida quando eu precisava fazer uma pesquisa composta usando varias tabelas, vamos supor Usuário - Cidade - Estado, e eu queira que no resultado da consulta do usuário eu já pegasse a descrição da cidade e do estado, dai eu motava a View para já pegar tudo de uma vez pelo JDBC, se não eu iria ter que realizar 3 consultas, primeiro para o usuário depois para cidade e depois para o estado para pegar as descrições pelas FOREIGN KEY.

E a duvida é.. as Criterias já substitui as Views ou ainda é bom eu motar as mesmas e usar o HQL? Eu não estou conseguindo ter essa visão de como resolver essa parada.

Não vejo a necessidade de uma view. Basta realizar o mapeamento da classes de domínio que o GORM resolve pra ti. Digamos que você tenha a seguinte estrutura de classes de domínio:

class ?User {
   ?City city
}

class City {
   ?State state
   ?String name
}

State state {
   ?String uf
}

Para listar todos os usuários de determinada cidade você poderia usar HQL:

List<User> users = User.executeQuery("from User where city.name = :joinville", [joinville: "Joinville"])

ps: Pessoalmente eu não criaria uma entidade State, usaria uma Enum

@Joás Garcia, bom dia!

Bacana, entendi seu exemplo, é que eu fiquei na duvida de qual iria ter mais desempenho entre a View e o GORM.
E qual a vantagem que você vê em criar um Enum ao invés de uma entidade para o Estado?

A vantagem que eu vejo é que é um join a menos para realizar nas consultas. Como quando você quer uma consulta de todos os clientes de determinado estado por exemplo. Como os estados são dados que raramente são alterados a enum é uma ótima solução. Para ficar melhor, você ainda pode criar um campo na enum para o nome por extenso do estado. Algo assim:

State.SC.description (Resultado = "Santa Catarina")