JPA - DAO

Estou em um grande projeto, com um modelo de desenvolvimento totalmente componentizado, mesmo porque existe 4 consultorias no mesmo projeto.

Uma das atividades nossas será criar uma camada de persistência para a base relacional, que possui cerca de 120 tabelas, altemente relacionadas.

Por questões técnicas, achei melhor não utilizar os relacionamentos entre as entidades (ejb/jpa) e criar classes que mapeiam puramente uma tabela (incluindo pks, fks e outros campos).

Portanto terei um único DAO para fazer o CRUD dessas entidades, implementado como um EJB Stateless Session Bean, para que os sistemas acessem facilmente este componente, para manipular os dados desejados.

Bom, a questão é que quero isolar das outras camadas a necessidade de conhecer JPA e todas as características dele, como por exemplo o update e delete dos objetos MANAGED.

Quero apenas fornecer alguns métodos: create, update, delete, findByPK, e os desenvolvedores não precisam se preocupar se o objeto é MANAGED, DETTACHED, etc.

Nos meus testes, fazer um simples merge no update, funciona, porém, um simples delete de um objeto NEW, não funciona. Ou terei de fazer um find e deletar, ou então um merge.

Enfim. Alguem implementou uma solução destas? Como resolveu, sem complicar muito?

JavaEvangelist Membro desde: 26/02/2007 09:31:49 Mensagens: 329 Offline

Um dia vou chegar a desenvolver um sistema desse, parabens daniel pelo conhecimento

Falow

Daniel;

Tenho uma infra aqui na empresa mais ou menos como vc descreveu, porem eu optei por construir um ancestral para cadastramento basico.

Este ancestral faz parte de uma hierarquia de classes nossas.

Fornecemos para o modelo de domínio um ancestral de entidade que tem algumas operações basicas.

No caso optamos por denominar nao DAO, abolimos este conceito aqui porque no nosso entender, o DAO praticamente é o Entity manager - Inclusive essa era uma opinião que queria ter com alguns experts.

Portanto nossos serviço ancestral de CRUD, encapsula o Entity Manager e cuida das operacoes. Bem como prove alguns outros serviços específicos do nosso negócio.

Sendo assim os desenvolvedores tem apenas que estender nossa entidade ancestral e o trabalho de mapeamento das entidades com as anotações JPA, alem de estender o nosso ancestral de seviços que implementar suas regras de negócio.

tem funcionado legal.

Inclusive aceito criticas e sugestoes...

Entendo, mas me preocupa mais a questão técnica da implementação com JPA mesmo.

Quero ter um método update e um delete, que não tenha problema em receber um objet NEW, MANAGED ou DETTACHED, mas que cuide da operação em sim, independente do estado.

Prq vc não usa ejb-ql?
Vc esta fazendo um DAO parametrizado? tipo DAO<E>?
Eu não gosto desta abordagem prq por ex, utilizando hibernate o metodo load devolve um proxy, o que inviabiliza a serialização para envio em um contexto onde não existe esta sessão.

This message was edited 1 time. Last update was at 05/08/2008 15:17:41

EJB-QL, SQL, X-QL, não é esta a questão.

A questão é. Precio de uma classe que faça o CRUD dos objetos do meu modelo de negócio. Porém não quero que quem utilize esta camada de persistência tenha que saber que é JPA, ou Hibernate, Banan Caramelada, mas tem apenas que saber que deve passar um objeto do modelo para criar/atualizar/remover ou então buscar.

Não quero passar aos desenvolvedores a preocupação com NEW/MANAGED/DETTACHED, etc.

Meu código hoje:

Mas ele ainda não me atende.

danieldestro wrote:Entendo, mas me preocupa mais a questão técnica da implementação com JPA mesmo.

Quero ter um método update e um delete, que não tenha problema em receber um objet NEW, MANAGED ou DETTACHED, mas que cuide da operação em sim, independente do estado.

Pois é, eu presumimo o seguinte:

Na camada de apresentacao, o objeto pode ser apenas new e detached, pois fica fora do contexto de persistencia, entao para as operacoes CRUD

Ceate - o o objeto é criado na camada de apresentacao, e passado para o EJB de serviço para gavação, neste caso temos um método inserir que encapsula a chamada do entitymanager.persist (aqui paira uma dúvida arquitetural, nao seria melhor ter um métudo de serviço que receba todos os atributos do objeto de dominio e este sim crie o objeto e persiste?)

Retrieve - São disponibilizados métodos de consulta e recuperacao do objeto, neste caso executam queries (que podem ser dinamicqas ou named queries) e tbem o método entitymanager.find

Update - os objetos de alguma forma sao recuperados da cmada de persistencia pelo Retrieve alteradoe e enviados para o Servço EJB, com a chamada de um método atualizar, o ancestral encapsula o retorno deste objeto pra o contexto de persistencia, praticamente encapsula a chamada do entitymanager.merge

Delete, é passado o objeto que desejamos excluir.

Para cada caso é implementada regras de negócio específica dos objetos que herdam os ancestrais.

Ainda assim gostaria de opiniões sobre essa abodagem.

isso não funciona?

LuizAvila wrote:Na camada de apresentacao, o objeto pode ser apenas new e detached, pois fica fora do contexto de persistencia, entao para as operacoes CRUD

Correto!

LuizAvila wrote:Ceate - o o objeto é criado na camada de apresentacao, e passado para o EJB de serviço para gavação, neste caso temos um método inserir que encapsula a chamada do entitymanager.persist (aqui paira uma dúvida arquitetural, nao seria melhor ter um métudo de serviço que receba todos os atributos do objeto de dominio e este sim crie o objeto e persiste?)

Método que recebe os atributos? Para que? Posso usar a OO e não preciso criar 120 métodos de inserção.

LuizAvila wrote:Retrieve - São disponibilizados métodos de consulta e recuperacao do objeto, neste caso executam queries (que podem ser dinamicqas ou named queries) e tbem o método entitymanager.find

Ok. O objeto retornado pelo EM é retornado pelo método find.

LuizAvila wrote:Update - os objetos de alguma forma sao recuperados da cmada de persistencia pelo Retrieve alteradoe e enviados para o Servço EJB, com a chamada de um método atualizar, o ancestral encapsula o retorno deste objeto pra o contexto de persistencia, praticamente encapsula a chamada do entitymanager.merge

Eu não queria fazer um find, para então fazer um update. Queria simplesmente passar o objeto e atualizar no BD.. mas isso pode ser ruim, pois existem casos que só preciso atualizar um campo, e não o objeto todos, e isso pode comprometer minha base. Então, pelo jeito, preciso fazer um find, atualizar o obeto e (se necessário) fazer merge.

LuizAvila wrote:Delete, é passado o objeto que desejamos excluir.

Em teoria deveria ser isto, mas to vendo que preciso dar um find antes. Quero evitar este passo.

Abdon wrote:isso não funciona?

if(!entityManager.contains(obj)) { //Deixa o objeto tipo lazy load (não vai ao banco aqui) obj = entityManager.getReference(Pessoa.class, chavePrimaria) ; } entityManager.remove(obj);

Considere 120 classes (entities) no meu modelo. Quero simplificar, ou terei que implementar algum mecanismo mais efetivo.

danieldestro wrote:Método que recebe os atributos? Para que? Posso usar a OO e não preciso criar 120 métodos de inserção.

Perfeito!!!

danieldestro wrote:
Eu não queria fazer um find, para então fazer um update. Queria simplesmente passar o objeto e atualizar no BD.. mas isso pode ser ruim, pois existem casos que só preciso atualizar um campo, e não o objeto todos, e isso pode comprometer minha base. Então, pelo jeito, preciso fazer um find, atualizar o obeto e (se necessário) fazer merge.

e alem disso se fizer um merge e por algum motivo esse objeto nao estiver persistido, ele vai ser inserido, em alguns casos pode ser um comportamento indesejado.

Foi o que percebi nos testes.
Como fazer um UPDATE APENAS se o registro existir?

apenas com uma operacao nao tem como. tu tens que executar um find() ou getReference() e depois dar um merge(), caso ele exista..

danieldestro wrote:
Nos meus testes, fazer um simples merge no update, funciona, porém, um simples delete de um objeto NEW, não funciona. Ou terei de fazer um find e deletar, ou então um merge.

Daniel, delete em entities no estado new nunca irá funcionar mesmo. Ctr+C/Ctrl+V do meu blog:

No momento em que é instanciado, um entity encontra-se no estado new. O bean não possui identidade (primary key) e não está associado a nenhum persistence context. Isso equivale a dizer que não está sincronizado com o banco de dados, portanto mudanças nesse objeto não se propagarão para o banco de dados.

danieldestro wrote: Como fazer um UPDATE APENAS se o registro existir?

Não tem como você criar uma query antes da atualização para verificar se determinado objeto já foi persistido? Se não foi, o update no dao não chama merge e retorna.
Ou então só verificar se a entidade tem um pk? Se você estiver utilizando geração de pk, um novo objeto não teria pk e, nesse caso, o merge não seria chamado.

LuizAvila wrote:

danieldestro wrote:Método que recebe os atributos? Para que? Posso usar a OO e não preciso criar 120 métodos de inserção.

Perfeito!!!

danieldestro wrote:
Eu não queria fazer um find, para então fazer um update. Queria simplesmente passar o objeto e atualizar no BD.. mas isso pode ser ruim, pois existem casos que só preciso atualizar um campo, e não o objeto todos, e isso pode comprometer minha base. Então, pelo jeito, preciso fazer um find, atualizar o obeto e (se necessário) fazer merge.

e alem disso se fizer um merge e por algum motivo esse objeto nao estiver persistido, ele vai ser inserido, em alguns casos pode ser um comportamento indesejado.

nao cara.. como seria um comportamento indesejado?
se ele nao existe, ele é persistido no proximo flush() ou commit().. enquanto isso ele apenas é managed.. e pode sofrer rollback

se ele existe, é executado uma busca ao objeto.. se encontrar ele compara todos os atributos e os que foram modificados sao sobrescritos com o estado do objeto atual.. e é só isso, nao tem nada além.

Notícias, artigos e o maior fórum brasileiro sobre Java