Arquivo Discussoes de Programacao e Tecnologia Boa Tarde Galera,
Estou desenvolvendo a parte de persistência de um sistema grande e sou iniciante em JPA.
Me parece um pouco redundante ter um DAO que contém um EntityManager para fazer basicamente o que ele já faz.
Gostaria de saber como vcs estão fazendo a camada de persistência de voces, utilizando JPA.
Grato
Gostaria de aproveitar para já deixar aqui uma dúvida:
Estou trabalhando em um projeto em que cada cliente possui um schema do MySQL.
Todos os SCHEMAS possuem as mesmas tabelas, porém cada qual com dados de apenas um cliente
Isso é um problema para o JPA ?
Grato
Oi,
Poderia explicar melhor o problema? 1 SGDB para cada cliente (para cada acesso a aplicação???) ?
Estou trabalhando em um projeto que possui um banco de dados por cliente.
Oi,
Poderia explicar melhor o problema? 1 SGDB para cada cliente (para cada acesso a aplicação???) ?
Oi Rafael,
Desculpe, não fui mto claro.
Na verdade todos os clientes são MySQL(vamos migrar em breve). Cada cliente possui um SCHEMA diferente, porém todos com as mesmas tabelas
Grato
Adicionado por engano
Oi,
Você que provém essa infraestrutura para cada cliente(armazenamento, processamento e etc…)? Como funciona isso? A cada novo cliente de vocês se cria um novo schema e se repete os objetos do banco?
Oi,Você que provém essa infraestrutura para cada cliente(armazenamento, processamento e etc…)? Como funciona isso? A cada novo cliente de vocês se cria um novo schema e se repete os objetos do banco?
Oi Rafael,
Para cada novo cliente, criamos um novo schema no banco e criamos as tabelas para esse novo schema, ai associamos o cliente a esse SCHEMA.
Grato
Oi,
Sinceramente eu desconheço a possibilidade de mapear dinamicamente com JPA, pois seria necessário isso para atender a sua necessidade. No JPA você mapeia o objeto e pode inclusive definir em qual schema (no caso dentro do persistence.xml), alterar isso dinamicamente eu desconheço. Verifique se tem a possibilidade de criar vários persistence.xml e poder carrega-los distintamente, se for possível será um caminho, mas também desconheço essa possibilidade.
Oi,Sinceramente eu desconheço a possibilidade de mapear dinamicamente com JPA, pois seria necessário isso para atender a sua necessidade. No JPA você mapeia o objeto e pode inclusive definir em qual schema (no caso dentro do persistence.xml), alterar isso dinamicamente eu desconheço. Verifique se tem a possibilidade de criar vários persistence.xml e poder carrega-los distintamente, se for possível será um caminho, mas também desconheço essa possibilidade.
Oi Rafael,
Me parece que é possível passar configurações para o EntityManager de forma que ele cuide disso.
Agora a questão central do tópico:
DAO é necessário se eu tenho JPA ?
Grato
Oi,
Agora vamos entrar na parte filosófica da coisa. Se você imagina que nunca mais terá uma outra forma de persistência acredito que não seja necessário, até por que uma das funções do DAO é isolar a persistência e com JPA suas classes estariam repletas de anotações (meta-programação) referentes a persistência. Na minha opinião a resposta seria NÃO.
Estou pensando em usar Active Record.
Gostei bastante do que vi no Rails. Alguém vê algum problema(ou tem dicas) para essa abordagem implementada “na mão” ?
Penso em algo como:
Pessoa possui PessoaRepository
E delega para o repositório os métodos relacionados a persistência.
O que vcs acham ?
Isso teria problemas relacionado a transações ?
Minha arquitetura possui: Seam + EJB3
Grato
EMHO,
Na maioria dos casos, não. Mas em casos mais complexos, onde você começa a ter código que poderia ser encapsulado em um método, é interessante. Talvez providencie os DAOs inicias apenas liberando acesso direto ao EntityManager, se um dia tu precisar que eles sejam mais espertos, já está encapsulado, e aí basta tratar.
EMHO,Na maioria dos casos, não. Mas em casos mais complexos, onde você começa a ter código que poderia ser encapsulado em um método, é interessante. Talvez providencie os DAOs inicias apenas liberando acesso direto ao EntityManager, se um dia tu precisar que eles sejam mais espertos, já está encapsulado, e aí basta tratar.
Ai eu penso:
Colocar os métodos que podem ser reaproveitados em outro lugar e chamar apenas quando necessário, pq em 90% dos meus casos o JPA cru resolve. A meu ver, não vale a pena criar uma camada extra com métodos que “eu possa vir a precisar um dia”.
Estou animado com a idéia do Active Record no Java.
Alguém ai já fez ? Estou com receio por causa das transações, como seria isso ?
Grato
Desculpe pela opiniao, mas pensando por um outro lado, mas tambem filosofico !
O uso de um DAO seria interessante, pois voce poderia cria uma DAOGeneric abstraindo as operações comuns com salvar, atualizar e excluir.E estender este DAOGeneric para criar o DAOPessoa, por exemplo.
Acretido que seria melhor,até porque poderia-se uilizar de arquivos xml para comfigurar os mapeamentos e atributos de uma Entidade que será persistida no banco.
Mas como falei antes, minha opinião, mesmo sendo um pouco leigo, torna-se uma solução mais flexivel e reusavel do sistema em si.
A parte de persistência costuma ser pequena, então não há muito ganho no DAO.
Mas um projeto que eu achei bem interessante, pra praticamente reduzir código de persistência a zero é o Polyforms. É feito por uns chineses e ainda está na infância, pelo que eu vi, e mas com esse framework, todo o código de persistência é criado dinamicamente pra você. Vale a pena dar uma olhada.
Mas mander esta parte de percistencia em outro local que nao seja organizado, acredito que fuja um pouco da ideia da reusabilidade, pois a ideia é justamente essa, reusarmos ideias.
A existencia do DAO, concordo, depende do tamanho da aplicação, imagine um sistema onde temos mais de 50 entidades e controlar isso em camada prorpia, seria uma loucura.
Mas quando bem montado, o DAO passa a ser uma boa soluçao para resolver os problemas de percistencia.
Deêm uma olhada no link abaixo, manipula com JPA uma classe de DAOGeneric, acredito que fique mais facil.
Abstrai tudo que é comum e estende so a parte da localização que é especifico.
A parte de persistência costuma ser pequena, então não há muito ganho no DAO.Mas um projeto que eu achei bem interessante, pra praticamente reduzir código de persistência a zero é o Polyforms. É feito por uns chineses e ainda está na infância, pelo que eu vi, e mas com esse framework, todo o código de persistência é criado dinamicamente pra você. Vale a pena dar uma olhada.
Oi leonardo,
Bastante interessante mesmo esse projeto. Pena que usa Spring e AOP, duas coisas das quais não disponho em meu projeto 
Estamos usando Jboss Seam, e como a equipe não possui mta experiência nos frameworks já escolhidos, adicionar mais outros poderia ser complicado, principalmente o Spring que pode prover funcionalidades equivalentes a algumas funcionalidades do Seam.
Vou continuar minha busca, obrigado pela dica.
Boa Tarde Galera,Estou desenvolvendo a parte de persistência de um sistema grande e sou iniciante em JPA.
Me parece um pouco redundante ter um DAO que contém um EntityManager para fazer basicamente o que ele já faz.
Em uma palavra: sim.
O EntityManager é a porta de entrada para um Domain Store. Os DomainStore já utilizam o padrão DAO para comunicar com diferentes repositorios fisicos. Encapsular o DomainStore em um DAO é um passo a trás.
Agora, você pode sentir a necessidade de encapsular o uso do EntityManager de forma centralizada. Se o JPA mudar ( e não vai demorar muito para isso acontecer) vc vai querer mudar um conjunto limitado de classes e não o sistema inteiro. É aqui que entra o conceito de repositório. O repositorio encapsula as chamadas ao EntityManager de forma que se o JPA mudar ou a forma da chamada mudar ( adiconar mais um parametro na query pro exemplo) apenas o repositorio vai mudar.
Vc pode pensar que isto é o mesmo que o DAO faria. Pode parecer isso à primeira vista, mas o DAO e o Repositorio tem responsabilidades bem diferentes embora a implementação possa ser bem semelhante ( isso na realidade acontece porque vc já está implementando o padrão Repositorio só que está lhe chamando DAO).
A diferença fundamental é que DAO é suposto existirem vários por entidade, por isso eles são definidos por uma interface e existe um factory para inicializar o DAO certo. O repositório é só um por entidade. É uma classe e não um interface e não são necessárias factories. ( claro que podem ser usadas, mas não são essenciais como no DAO)
[Adicionado]
Nem pense em usar o chamado DAOGenerico que isso é um anti-pattern sem tamanho.
Se vc tem realmente muito codigo semelhante em todos os repositorios de todas as entidades ( o que deve acontecer) use o padrão Layer SuperType que básicamente significa criar um Repositorio abstracto pai de todos os outros que implementa as funcionalidades em comum. Esse sim pode ser genérico. Mas não é um DAO.
[/Adicionado]
Se você esta com receio de adicionar algum outro framework, por conta de adicionar complexidade, então descarte também esta idéia de aplicar ActiveRecord em seu projeto.
A própria especificação fez um verdadeiro samba-do-crioulo-doido nos antigos EntityBeans do J2EE, onde você tinha que misturar códigos de seu DomainObject com códigos de infraestrutura a acesso a dados, por meio de várias interfaces necessárias para tal. O resultado foi um Active Record capenga, limitado, com EntityBeans difíceis de manter e de se construir.
Hoje em dia, poderíamos criar aspectos (AOP) para abstrair a infra e dar alguns comportamentos dinâmicos para acesso a dados, mas mesmo assim o custo para isso não compensa, em frente a tantas outras soluções de arquiteturas bem mais razoáveis para se aplicar em Java. Fora que, do meu ponto de vista, objetos de domínio com update, save, delete, find, findByPK não é uma coisa muito “saudável” no modelo (não são de sua responsabilidade).
Se você usa o Seam como disse, parta para outra abordagem. Você pode utlizar o recurso de persistencia dele out-of-box, que compõem o Pattern “Mediator”, chamado de EntityHome e EntityQuery. Ou pode simplesmente injetar EntityManager em qualquer classe via @In e montar seu próprio Repository ou DAO, ou nenhum dos dois, e fazer uso da especificação;
[]s
bem mais a questão da inserção do EntityManager tudo bem, mas e quanto a um DAOGeneric ou Repository para manipulação de dados, seria correto, pois o DAO seria a unica parte do sitema que conheceria a persistencia dos dados, e neste DAO seria encapsulado a ideia do JPA ou JDBC pra quem queira.
Questão é correto colocar tudo, digo o EntityManager, neste DAO pra encapsular a persistencia ?
Não existe “o correto”, se no final das contas seu objetivo for alcançado.
Pense em “motivação”, esta é a palavra-chave para todo e qualquer padrão de projeto. Se existir no seu projeto algum problema que se encaixe na descrição de motivação de alguma padrão, use-o, caso contrário, não.
Você pode por exemplo querer abstrair seu Entity Manager, Session do Hibernate ou até mesmo Connection de um JDBC, mas não se esqueça que nada disso tem valor se você expor seu critério de consulta para estas APIs, como um JPAQL, HQL, Criteria ou SQL. Neste caso você também teria que usar Specification+QueryObjects para conseguir este nível de abstração.
Como pode ver, isso pode ser um problema ao invéz de ser uma solução, caso você saiba que não vai mudar sua API de persistencia. Por causa disso muita gente prefere não sujar os objetos de domínio e expor apenas uma interface de repositorio para este, e aplicar direto na implementação deste cara um Entity Manager da vida. O principal, que é isolar o negócio foi feito, o resto é perfumaria.