[quote=ddduran]Eu disse que o sistema dele agora era JEE? eu preciso de um container EJB para minha aplicação ser JEE?
de que edição é o JPA?[/quote]
Só expliquei para ele como funciona a nova disposição do JPA quanto ao EJB, não questionei sua resposta… EJB e JPA agora são independentes, isso que eu tentei explicar…
ok, entendi
[quote=jgbt]outra coisa, me responde uma coisa:
se vc usa isso:
MinhaClasse minhaClasse = minhaFactory.getMinhaClasse(); quer dizer que p/ cada classe vc vai ter um get na sua factory???
muito bom mesmo… evita o cast, mas…
[]'s[/quote]
Vc prefere um método com 2 linhas ou um mais 3 linhas no seu mundo de XML?!? Sem contar que se seu objeto depender de algum atributo na construção, são mais umas 5 linhas… no final… XMLs e mais XMLs… dependencia de um monte JAR… como uma bazuca pra matar formiga!
Eu utilizo Spring com Spring Annotations, que não tem XML… e como a maioria das aplicações contruidas hoje em dia são pequenas/medias, acho que vc ter 1Mb de classes proprias, 3Mb de XML e 15Mb de bibliotecas é um afronto às pessoas que param e pensam em soluções elegantes e embasadas pelos grandes nomes de padrões por ai…
E falando de Spring, quantas vezes vc alterou uma entrada no seu XML de “inversão de controle”?!?!? Já parou pra pensar que muita gente utiliza Spring por ser moda e por “facilitar mudanças” que em projetos com pressão e atmosfera normais nunca acontecem?!? E se vc tivesse fazendo um sistema que precisa de uma fábrica de 600 objetos?!? Vc utilizaria o Spring como singleton ou não?!?!? E a manutenção dos XMLs?!?!? E se sua fabrica ficasse dividida entre Rio, São Paulo, Porto Alegre e India?!? Como miria ser esse controle de mudanças e manutenções?!?
Pense nisso! “Pode ser seu trabalho de fim de semana”. Pensar em como vc pode fazer o desenvolvimento ficar simples, independente, performatico, de facil manutenção e outros requisitos não-funcionais de todos os softwares de grande porte.
OK, vou estudar isso sim, professor… mas avise ao owner da thread, que é quem realmente e indiretamente te perguntou se o GenericDAO dele está legal, que fazer isso que na semana que vem e, depois que eu colocar o meu estudo e o senhor corrigir, ele terá acesso aos fontes e pode aprender como fazer um autoWireByNameComMuitoMaisEquio, ok?
Só me resta rir desses comentários…
[quote=Titôsca]mas??? eu tow usando assim! minha DAOFactory.getEntidadeDAO();
o que ta errado?[/quote]
Não tem nada de errado se vc tiver levando em consideração o Pattern DAO do Core J2EE…
Existem várias maneiras de uma factory funcionar, e até mesmo as razões dela existir…
Cabe cada um implementar a que mais lhe agrada no contexto do software a ser contruido…
Como a definição de Patterns: Aquilo que resolve o seu problema da maneira mais eficaz possivel! Seja ela com um simples new ou via ID.
[quote=rodrigoallemand][quote=Titôsca]mas??? eu tow usando assim! minha DAOFactory.getEntidadeDAO();
o que ta errado?[/quote]
Não tem nada de errado se vc tiver levando em consideração o Pattern DAO do Core J2EE…
Existem várias maneiras de uma factory funcionar, e até mesmo as razões dela existir…
Cabe cada um implementar a que mais lhe agrada no contexto do software a ser contruido…
Como a definição de Patterns: Aquilo que resolve o seu problema da maneira mais eficaz possivel! Seja ela com um simples new ou via ID.[/quote]
ID = Injeção de dependencia???
Yep!
[quote=rodrigoallemand]
Vc prefere um método com 2 linhas ou um mais 3 linhas no seu mundo de XML?!? Sem contar que se seu objeto depender de algum atributo na construção, são mais umas 5 linhas… no final… XMLs e mais XMLs… dependencia de um monte JAR… como uma bazuca pra matar formiga!
Eu utilizo Spring com Spring Annotations, que não tem XML… e como a maioria das aplicações contruidas hoje em dia são pequenas/medias, acho que vc ter 1Mb de classes proprias, 3Mb de XML e 15Mb de bibliotecas é um afronto às pessoas que param e pensam em soluções elegantes e embasadas pelos grandes nomes de padrões por ai…
E falando de Spring, quantas vezes vc alterou uma entrada no seu XML de “inversão de controle”?!?!? Já parou pra pensar que muita gente utiliza Spring por ser moda e por “facilitar mudanças” que em projetos com pressão e atmosfera normais nunca acontecem?!? E se vc tivesse fazendo um sistema que precisa de uma fábrica de 600 objetos?!? Vc utilizaria o Spring como singleton ou não?!?!? E a manutenção dos XMLs?!?!? E se sua fabrica ficasse dividida entre Rio, São Paulo, Porto Alegre e India?!? Como miria ser esse controle de mudanças e manutenções?!?
Pense nisso! “Pode ser seu trabalho de fim de semana”. Pensar em como vc pode fazer o desenvolvimento ficar simples, independente, performatico, de facil manutenção e outros requisitos não-funcionais de todos os softwares de grande porte.[/quote]
bom, vc pode me dizer aonde eu apontei o Spring como melhor solucão para tudo?? so mostrei alguns usos, e como qualquer outra coisa, vai ser usado se for necessario.
eu sugeri o Spring para controle de transações, nem mesmo falei em injeção de controle, pq na MINHA opinião, controle de transações não deve ser preocupação do seu codigo, e sim logica de negocio.
vc que falou em cast, so te mostrei que não precisa de cast, é so saber usar.
quanto a questão de xml versus configuracao no codigo, depende muito de opinião pessoal. EU particularmente prefiro em xml, e ja trabalhe SIM em um projeto dividido entre Porto Alegre e Atlanta/USA com mais de 30 desenvolvedores e não tinha problema nenhum em relação a manter esse tipo de arquivo.
como vc parece saber muito sobre o assunto e o foco do topico não é este, não vou discutir mais sobre isso.
se quiser discutir sobre o assunto e ver opiniões diferentes da sua(afinal um forum é p/ isso), pode abrir um topico sobre isso.
[]'s
[quote=rodrigoallemand]
[quote=heitor.rapcinski]Acho desnecessário a utilização de um DAO quando você utiliza JPA, eu constumo colocar as consultas com @NamedQuery na Entidade quando referencia apenas uma entidade e no Pacote quando referencia várias entidades. O EntityManager pode ser injetado nas classes de serviço e ele genérico o suficiente para realizar todas as operações de persistência.
só a minha opnião.[/quote]
Estive pensando nisso esses dias. Esse é o primeiro projeto grande que eu utilizo JPA. São 600 entidades + ou -… já imaginaram a zona que iriamos ter no fim do projeto???
Mas Heitor, como vc imagina fazer este controle? Dentro dos objetos de negocio mesmo ou dentro das entidades?[/quote]
Veja você chama o EntityManager no mesmo lugar que chamaria o DAO Genérico, ao invés de chamar o DAO da entidade X vc chama o EntityManager e trabalha com a entidade X como quiser.
E onde vc criaria um metodo “consultarClientesSbrublesSugeridosPeloAmigoDoGerente”, referente somente a entidade Cliente? Ai sim vc criaria uma estrutura de DAO para esta Entidade, correto?!?
Caso sim, então porque não perder mais 5min do seu sistema e fazer uma estrutura para cada entidade, deixando o TypeSafety do Java trabalhar pra vc nos casts?
[/quote]
Existem dois ambientes em que se usa o DAO
Aqui o DAO é o unico elemento da camada de persistencia. O resto do sistema não pode usar o DAO para executar queries genericas e aleatórias.
Neste ambiente cada entidade tem o seu proprio dao e este contém métodos especiais como o “consultarClientesSbrublesSugeridosPeloAmigoDoGerente”. Ele contém , portanto , logica de negocio.
Não é reutilizável para outros dominios e nem para outro mecanismo de persistencia.
Aqui o DAO não é unico elemento da camada de persistencia. O resto do sistema tem como usar o DAO para executar queries genericas e aleatórias com base num intrepretador e uma forma de definir a query
Neste ambiente um só DAO é usado por todas as entidades que existe no mesmo contexto de persistencia ( no mesmo banco). Ele é utilizável para várias entidades e dominios e para outros mecanismos de persistencia.
Métodos especiais como “consultarClientesSbrublesSugeridosPeloAmigoDoGerente” ou ficam na entidade ele mesma (ex: client.pedidos(semanapassada , hoje) ) ou ficam em serviços ( Roteamento.roteiroPara(List lp) ) ou ficam em repositórios. Os repositorios são os unicos que podem usar o DAO e criar as queries genéricas. Os serviços e as entidades têm que se basear nos métodos do Repositorio. Cada entidade tem um repositório. (Se não gostam palavra Reposiorio, usem Manager)
Titôsca desculpe a demora…então existem diversos exemplos sobre isso…mas conforme dito pesquise pela Open Session On view (usado para sistemas WEB)…
é mais ou menos assim…vc acessa uma Servlet qualquer, um filtro abre a sessão…q quando vc sai da jsp o mesmo filtro fecha a transação… (esta bem resumido)…
Para o seui caso…é só tirar os commit de dentro da classe DAO…e quando vc instaciar um entity manager vc faz o que precisa fazer e depois pega esses managers e dá um commit só…entendeu…
Revivendo aqui o topico por te-lo achado muito interessante.
Nao entendi o que o Sergiotaborda quis dizer. Se eu deixar o dao sendo “uma mula” nao vou estar deixando o meu controle muito acoplado a tecnologia usada para persistencia?(No caso um banco de dados). Geralmente uso um mix desses dois que ele falou:
Tem os metodos genericos e mais comuns em qualquer dao(o CRUD) e tenho os metodos do tipo “consultarClientesSbrublesSugeridosPeloAmigoDoGerente”. Nunca tive problemas com essa abordagem e considero que mantenho tudo desacoplado o suficiente da camada de persistencia de modo que se for preciso muda-la so vou ter que reimplementar esses metodos. E se eu usasse a segunda abordagem onde o DAO seria, segundo ele, uma mula o controle ficaria totalmente dependente do tipo de persistencia.
Repito que nao sei se entendi bem e caso a minha forma de implementar a camada de persistencia nao seja a mais correta gostaria que me corrigissem e se possivel indicassem algum material sobre o assunto(e tambem os possiveis problemas dessa abordagem). Geralmente fico “encucado” com problemas de padroes de projeto e sempre que penso estar fazendo errado fico meio preocupado.
Desde ja agradeço a todos!