Opa Edinei... Primeiramente, seja bem-vindo ao fórum...

Uma pergunta que lhe farei e que precisa ficar bem claro o porque perguntei...

Você vai ter Clientes, Empresas e Colaboradores em um mesmo Endereço ???

Pergunto isso, pois sei lá, nunca se sabe a que ponto chegou a ideia de requisitos na cabeça dos usuários por aí...

Perceba que Endereço, normalmente é uma Entidade que atende diretamente somente a 1 dessas outras entidades... Ou ele pertence a um cliente, ou a uma empresa, ou a um colaborador. Você concorda comigo até aqui ???

Então aconselho que você altere o seu modelo pra refletir esse relacionamento entre seus domínios de forma mais clara, não é um Endereco que vai ter vários clientes, é 1 Cliente que terá 1 Endereco; 1 Empresa terá 1 Endereco; 1 Colaborador terá 1 Endereco.

Lembro-lhe que isso pode não ser verdade absoluta e ambos terem mais de 1 Endereco, mas essa discussão podemos deixar pra depois quando essa primeira parte evoluir.

Eu fui claro cara ??? Você concorda, discorda ???

Abs [] e vamos trocando ideias...

valeu pela sugestao... porem na minha concepçao colaboradores, empresas e clientes nao devem ter endereço incluido nas proprias tabelas e sim ter uma unica tabela de endereços para armazenar os dados de cada classe....

Não foi o que eu falei... Em momento algum disse que eles precisam estar na mesma entidade...

Perceba que deixei bem claro a separação da entidade Endereco e das entidades Cliente, Empresa, Colaborador.

O que você está fazendo é dizer "O Cliente Edinei pertence a [belongsTo] ao Endereco 'Rua dos blá blá'" Essa sentença faz sentido pra você ????

Abs [] e vamos trocando ideias...

Bom desculpe se me expresse mal.. voce pode auxiliar como ficaria a modelagem se possivel?

rsrsrsrsrsrs :D Sem problema amigo, estava provocando a conversa levantando questões para realmente forçá-lo a pensar em uma alternativa.

Mas vamos lá, vou fazer o básico e depois vamos evoluindo Ok ???

Temos uma classe Cliente como essa abaixo

class Cliente {
    String nome
}

e uma classe Endereco

class Endereco {
    String logradouro
    Integer numero
}

Precisamos relacionar essas duas classes para dizer que: "O Cliente Edinei, possui o Endereco X"

Para tal montagem, posso dizer que: "O Endereço X pertence ao Cliente Edinei". Você concorda...

Se sim, temos o seguinte cenário formado:

class Cliente {
    String nome

    static hasOne = [endereco:Endereco]
}

e

class Endereco {
    String logradouro
    Integer numero

    static belongsTo = [cliente:Cliente]
}

Assim você monta as 2 sentenças que coloquei lá em cima e monta uma relação de 1 - 1 entre cliente e endereço...

Assim, com esse cenário (que pode evoluir em breve) você consegue contemplar as 2 frases que colocamos lá em cima...

"O Cliente Edinei, possui o Endereco X"
"O Endereço X pertence ao Cliente Edinei"

Abs [] e vamos trocando ideias...

Erratas...

- Você concorda ???

Faltou o ponto de interrogação pra se caracterizar uma pergunta... Pareceu uma afirmação.

certo. entendi... porem o que gostaria de saber é como mostrar para o usuario no cadastro de cliente os campos da entidade Cliente e Endereço juntas..

Acho que você pode utilizar o conceito de classes incorporadas para esse propósito. Em Java é conhecida como a famosa "Composição".

Basicamente, trata-se de utilizar a conveniência de um único objeto de domínio mas sem a complicação de se criar tabelas separadas na base de dados para esse propósito. Típico para cenários de relacionamento 1:1, veja:

class Cliente {
        String nmCliente
	String profissao
	String estadoCivil
	Date dtNascimento
        ...
        Endereco endereco    -> referencia à classe incorporada.
        static embedded = ['endereco' ]   -> aqui está a mágica.
}
class Endereco {
        String cep
	String nmLogradouro
	String numero
	String dsBairro
        ...
}

Assim você mantém a semântica de O.O. sem a necessidade de uma tabela extra de "Endereço" ocupando espaço no seu BD.

Segue um outro link que aplica outro exemplo bem sucinto:

http://grails.org/doc/latest/ref/Domain%20Classes/embedded.html

Se você quiser apresentar na sua view o cliente e o endereço ao mesmo tempo, o plugin do "twitter bootstrap" para grails dá esse suporte no caso de vc querer gerar a view com o recurso do sacaffolding!! Dá uma olhada no visual:

http://grails-twitter-bootstrap.cloudfoundry.com/person/create

Espero poder ter ajudado. Abraços!

Opa!

Esqueci de dizer que no exemplo acima as DUAS classes devem ser criadas no MESMO arquivo .groovy. No caso, no arquivo Cliente.groovy.

Abraços.

show d bola cara....vou verificar

Show de Bola o recurso CarlosG... Valew por compartilhar...

Porém, fiquei curioso sobre o porque você acha complicado não criar uma nova entidade com um propósito completamente diferente ????

É só curiosidade mesmo viu cara ??? É porque normalmente uso assim porque componho Minhas entidades com mais de 1 Endereço e dependendo do Sistema...

Outra questão que eu levanto é, se a composição nesse caso criará esses campos dentro da mesma tabela de Cliente ?????

Lembre-se que no cenário atual dele, além de cliente, ele vai manter empresa e colaborador, teria que replicar essa classe dentro de cada arquivo do novo domain ??? E quando um dado mudar ???

Valeu mesmo por compartilhar o recurso...

Abs []

É apenas uma abordagem, @adrianosi. É bem conveniente neste caso específico de Cliente/Usuarios/Enderecos. Mas claro que, muitas das vezes, o conceito não se aplica. E vc acaba tendo que apelar para Heranças e outros recursos mais "custosos".

Quanto aos atributos, sim, eles são criados dentro da mesma tabela cliente. Mas vc continua tendo a convenção O.O. de fazer um "new Endereco()", o que é muito legal! É uma forma de "tunar" a sua aplicação, já que com um único select vc recupera ambas as instâncias.

Em relação à manter a mesma classe em "Empresa" e "Colaborador"... Aí teria que se estudar o modelo de dados mesmo. Talvez ele precise refatorar. Ou, simplesmente, usar o recurso mais apropriado para a situação. Particularmente, não replicaria a entidade nas outras classes, até porque estaria fugindo da metodologia DRY.

No mais, é bacana explorar esses conceitos fornecidos pelo groovy/grails. Tem muita coisa bacana que resolve uma penca de problemas que esbarramos diariamente usando uma linguagem como o Java, por exemplo. Vale a pena estudar sobre eles!

Abraços.

Pow Carlos... Selou... Realmente levantei essas dúvidas a fim de reconhecer se estávamos ou não no mesmo pensamento.

Fantástico o recurso mesmo cara, vai servir em breve com certeza...

Edinei, e aí ??? já andou com alguma coisa no problema ???

Abs []

Bom.. gostaria de agradecer as respostas, pois me auxiliaram na modelagem de dados e conheci alguns conceitos novos.
Obg.

Carlos, ainda ficou uma duvida minha, em java eu criaria a classe endereço do tipo @Embeddable
e na classe cliente eu chamaria o endereço do tipo @Embedded.
Voce disse q no grails essa classe endereço ficaria dentro de cliente. Entao para cada classe minha que for usar endereço eu tenho que colocar ela dentro dessa minha classe que vai usa-la, como no modelo acima??
Nao bastaria eu criar endereço uma unica vez como no java e utilizar pra quais classes eu quiser???