Qual a melhor implementação de Persistência?

Olá,

Aqui vai minha humilde opinião sobre o assunto, mas tambem gostaria de ouvir outras opiniões.

Já utilizei Hibernate e tambem mexi um pouco com o OJB, confesso que o OJB me agrada mais que o Hibernate, mais isso é por questão de gosto, o Hibernate está bem a frente do OJB ainda. Quanto a utilização de DAOs com SQL puro, ora, é para isso que o Pattern DAO foi criado, você não precisa saber como os dados estão sendo recuperados apenas recebê-los e utilizá-los. É claro que ficar misturando formas de persistência não é a melhor forma de conduzir um sistema, mas acredito que o Hibernate ainda não é a solução para todos os problemas do mundo, portanto muitas vezes recorrer a outros recursos pode ser crucial para o andamento do desenvolvimento.

Eu acredito que a pontos onde, pra quem utiliza o Hibernate, a utilização de SQL puro seria muito mais viável, por exemplo, eu não me conformo dele não ter um session.deleteByPk();, sei lá como ele faz isso internamente, mais ter que ter um objeto associado a uma sessão do Hibernate só pra deletá-lo é no mínimo horrivel.

Em tempo, acredito que a manutenabilidade do sistema, não está relacionada a tecnologia, framework ou pattern utilizado e sim em como esses são empregados, um código SQL bem feito pode ser entendido por qualquer especialista em Hibernate e vice-versa. Ainda se o cara não souber dar manutenção em um código SQL dificilmente saberá fazê-lo no Hibernate e isso é outro problema.

Eu desenvolvo um sistema de médio porte hoje e por questões de problemas para utilização do Hibernate, ele está sendo desenvolvido em DAOs puros e confesso a vocês que não me arrependo nem um pouco, conheço bem SQL e tambem conheço o pattern DAO e isso está sendo suficiente para abstrair completamente minha camada de persistência de maneira transparente e sólida.

Acho que a ferramenta de mapeamento OR “ideal” ainda não foi inventada, pois Hibernate, OJB e outros, podem facilitar muito seu trabalho mais lhe acrescentaram uma centena de erros até que você os domine bem, além é claro, da situação citada pelo Jeveaux, onde a utilização de SQL é muito mais viável. A teoria de que o Hibernate resolve todos os problemas do mapeamento OR ainda é só teoria, e será por um bom tempo até provar o contrário.

Bom, como eu disse, essa é apenas minha opinião, é um assunto que eu realmente gosto e poderia ficar aqui falando mais de uma hora, mais preciso trabalhar… gostaria de ver oque o resto do pessoal acha.

Oi…

Opa, sim, o problema não é com o DAO em si, pois a implementacão fica certa, mas o problema, é que eu fico com DAOs puros e Hibernate, acabo criando duas formas de persitencia, que um dia qualquer em uma migração do tipo de persistência poderá e causar problemas, ou pelo menos uma grande raiva de mim mesmo :lol:

hummm, sendo bem feito eu tb concordo, mas nem todo mundo faz assim, as vezes mesmo querendo nao podemos ou nao conseguimos fazer devido a prazos esmagadores

Isso mesmo, acho que esta foi a razão deste post, cansei de ouvir gente falando: “Pouts, pq tu esta saindo do hibernate aqui e fazendo com SQL direto no DAO?” afffff que raiva disso… ahahha

Entao, desenvolver tudo com DAO puro na mão, eu nao sou muito chegado, eu ainda acho que os desenvolvedores nao deveriam ser experts em SQL e nem escrever muito SQL nas aplicações, pra isso tem os DBAs (mais uma de teoria :roll:)… E depois, usar Hibernate tb esbarra um pouco na teoria, o que me obrigou a fazer de duas formas.

T+

Salve ,
Galera aqui vai uma fonte muito boa . Esse site faz uma comparação entre uma pancada de ferramentas de mapeamento objeto relacional. Um prato cheio … vale a pena adciona-lo aos favoritos :

http://c2.com/cgi/wiki?ObjectRelationalToolComparison

interessante , nao ?

Sobre a melhor implementação ? Acho que está prá nascer Este problema que você relatou não me parece ser muito incomum, e quanto mais complexidade se adiciona à uma aplicação parece que mais beiramos os limites dos mecanismos de persistência. Bom, no meu caso, tenho usado daos “puros” e não tenho me arrependido (inclusive o impacto para a equipe é na verdade menor, pois é menos uma framework), contornamos as questões de produtividade com geradores de código que fazem parte do trabalho braçal. Ainda sigo feliz :lol:

“Brossi”:

Salve ,
Galera aqui vai uma fonte muito boa . Esse site faz uma comparação entre uma pancada de ferramentas de mapeamento objeto relacional. Um prato cheio … vale a pena adciona-lo aos favoritos :

http://c2.com/cgi/wiki?ObjectRelationalToolComparison

interessante , nao ?

Oi

Bom link, estou lendo aqui…

“MHudson”:

Sobre a melhor implementação ? Acho que está prá nascer Wink Este problema que você relatou não me parece ser muito incomum, e quanto mais complexidade se adiciona à uma aplicação parece que mais beiramos os limites dos mecanismos de persistência. Bom, no meu caso, tenho usado daos “puros” e não tenho me arrependido (inclusive o impacto para a equipe é na verdade menor, pois é menos uma framework), contornamos as questões de produtividade com geradores de código que fazem parte do trabalho braçal. Ainda sigo feliz Laughing

Mas entao, isto é o que eu acho problemático, nao acho legal envolver de mais os programadores com o SQL em si, e se a complexidae aumenta o mecanismo de persistencia nao da conta, forçando cair ao SQL, fico entre a Cruz e a espada… hehehe

T+

eu uso DAO em tudo, com SQL nativo por baixo, com hibernate, com oq for!!! se for preciso trocar a implementação, eu troco, mas a interface do DAO permanece a mesma… bem, mas a questão não é essa ao meu ver, e sim, essas 3 variáveis:

performance - manutenção - produtividade

ok, há tecnologias q se enquadram melhor em cada uma dessas… por ex, usar SQL direto no DAO é a melhor opção no caso de performance e perde em produtividade, eu acredito… já o hibernate entra mais com produtividade… e por ai vai… Bom, performance é muito importante em sistemas grandes, e a gente apanha mais disso qnd se entra relacionamentos, vamos a um exemplo, temos a tabela Produto e a tabela Fornecedor… cada fornecedor tem um arraylist de produtos no banco… ok, agora imaginem q eu tenho 200 fornecedores, e uns 30.000 produtos… eita… ja imaginaram a carga q vai dar um fornecedorDAO.findAll()? Ok, mas pra isso existe lazy loading… não foi um exemplo perfeito… heaehahea… Se dependesse de mim, eu usava o SQL nativo puro de cada banco pra cada implementação concreta de DAO, uma vez q aqui na minha impresa somos representantes Oracle e SyBase… ora, se o cliente adquire um Oracle, é muito dificil ele querer trocar de banco depois! … mas tenho outro exemplo aqui, de um cliente q tem Oracle na matriz, e MySQL nas filiais, e queria usar a mesma aplicação em ambos os lugares, sem ter q reescrever código… solução? Hibernate… ah, e eu só conheço hibernate como tecnologia alternativa pra persistência, nao tive tempo ainda de testar outras…

Jeveaux, só discordo de você quando você diz que programadores não tem obrigação de saber SQL, eu acho que se todos os programadores sobessem SQL, mesmo usando o Hibernate, teriamos um ganho significativo em performance em tudo que é aplicação.

A produtividade que o Hibernate proporciona, só é realmente proporcionada quando o programa é relativamente simples, pois pra mim, a HQL não melhora nada a situação do SQL a não ser na hora de popular os beans, e isso um método fetch no meu DAO tira de letra.

Lazy load? E se eu sei quando vou precisar das minhas coleções? Em que ele ajuda?

Pra mim o Hibernate está crescendo desgovernadamente e está ficando cada vez mais complicado assim como aconteceu com o Struts…

“Volnei”:

Lazy load? E se eu sei quando vou precisar das minhas coleções? Em que ele ajuda?

bem, não vai ajudar nessa hora né, e nem sei oq te ajudaria nessa hora!! … mas o lazy vai te ajudar qnd for precisar de uma lista de Fornecedores, mas não precisar de informações quanto a produtos… … ta ok, não foi um bom exemplo o meu anterior :lol:

ahm… e vejam só, por ex, o Struts é muito difundido hj, o mais usado, mas todos sabemos q existem problemas nele resolvidos por outros frameworks (não entraremos em detalhes aqui, não é o foco do tópico) … assim como o hibernate, é o mais conhecido, usado e difundido… não nos limitemos a discutir de hibernate… bem, uma coisa q eu não colocaria na persistencia nem a pau por ex seriam entity beans… eu acho totalmente desnecessário, trabalhoso e improdutivo… claro, improdutivo qnd vai ser feito a mão, mas ai se vc quiser usar uma ferramenta oferecida por algum fornecedor, tu ja te prende a ele… não vale… mas ai vem a especificação do EJB 3, q eu não conheço, mas espero coisa boa na parte de persistencia

Bom pessoal,

Acho que não vou ajudar em nada a resolver a dúvida existencial do jeveaux (heheh), mas quero deixar minha humilde opinião.

Eu iniciei na área, trabalhando com banco de dados, portanto (acredito) tenho um bom conhecimento em SQL, por este motivo eu trabalho com classes DAO puro, e como a equipe de desenv. aki é pequena, e todos têm o mesmo nível de conhecimento em SQL, isso nunca foi um problema. Quanto à produtividade, como disseram, existem ferramentas que te auxiliam na geração automático dos códigos, e vc apenas faz alguns ajustes (vide).

Nunca trabalhei com Hibernate, mas realmente acredito que uma implementação que misture duas formas de persistência não seria a ideal.

Mas por outro lado, o que fazer quando as ferramentas não nos dão o suporte necessário para determinada tarefa? Eu diria que no lugar do jeveaux eu provalvemente estaria fazendo a mesma coisa. Fazendo uma comparação, existem horas q é preciso fazer mágica no struts para resolver determinado problema, isso foge da abstração ideal, mas nestes casos não há mto oq fazer! Poderia trocar o framework, mas isto daria mais trabalho, e tomaria mais tempo, e o prazo geralmente é apertado.

Bom, aproveitando o ensejo, alguém aki trabalha com Prevalência? se sim, gostaria de uma opinião, se é mais viável à persistência.

[]'s

Oi

Opa, tb não é muito assim Volnei, acho que me expressei um pouco radical de mais… O que eu penso é que os programadores nao deveriam fazer uma imersão em SQL, em fazer SQL muito elaborados e tals, acho este é o trabalho dos DBAs e nao dos programadores, mas conhecer é sempre bom.

Não sei se chegaria a tanto, mas se for, pode ter conserto, aguardemos a nova versão do Struts né

Esta colocação do Matheus é bem importante tb, imaginem aquele findAll, aliás, imagine um find fazendo inner join em cima de inner join 8O

Prevelência??? 8O 8O 8O, já usei em vários testes aqui, á realmente muito bonito e legal de brincar, mas eu achei uma m****, nao é 100% confiável e se tu tiver um snapshot grande pra subir, esqueça, não sobe.

T+

prevayler nunca vai vingar do jeito q esta, ele só é bom pra quem desenvolve, não pra empresa… e quem desenvolve é pau mandado :lol: , se o banco free q todos amam (prevalencia oq for) não garantir 110% os dados da empresa, a empresa não ta nem ai, paga milhões se for necessário por um banco q o faça…

Concordo!
Imagina meu chefe fazendo consultas no banco… direto no SQL, isso é um costume de todos eles. Como ele aceitaria o prevayler?
Ainda não inventaram nada melhor pra armazenar os dados doque os banco relacionais e nada melhor que os objetos para trabalhar com eles. Oque está faltando é a integração, pois oque existe até hoje é uma grande gambiarra.

“andersonra”:

Eu iniciei na área, trabalhando com banco de dados, portanto (acredito) tenho um bom conhecimento em SQL, por este motivo eu trabalho com classes DAO puro, e como a equipe de desenv. aki é pequena, e todos têm o mesmo nível de conhecimento em SQL, isso nunca foi um problema. Quanto à produtividade, como disseram, existem ferramentas que te auxiliam na geração automático dos códigos, e vc apenas faz alguns ajustes (vide).

E eu achei que eu era o único louco a trabalhar com DAO puro…

no meu caso tb a equipe aqui é pequena.

Galera, eu ando começando ficar purista em relação a usar algo especifico.
Mas creio que usar coisas tão especificas para persistencia é fria.
1 - O que você acha que é mais provavel as empresas (grandes) trocarem? A aplicação ou o BD? Até hoje só vejo trocarem a aplicação pois os dados são carissimos.
2 - Porque perder certas funcionalidades do banco a ser usado? SP, Triggers, algumas funcões especificas de cada que há no SQL Server, Oracle ou DB2 qualquer um destes tem funcionalidades que dão um ganho de produtividade e rapidez muito grande, por isso o papel do DBA também.
Se formos sempre ficar adotando arquiteturas de desenvolvimento daqui uns dias irão inventar uma frameork apenas para DAO’s, outro framework apenas para SQL sei lá, e nisso a pessoa tera que conhecer, 10 frameorks para fazer um sistema.
Concordo que hibernate é hiper agil para desenvolvedores, mas fica-se preso.
um dos problemas também que o jeveaux citou é grandes consultas, a maioria dos frameoworks trabalham com o objeto em memória, isso gera um gasto de memoria extremamante alto aos servidores…
Imagina vc trazendo uma consulta com 1 milhão de registros? aqui é facil facil eu fazer algo assim, ou melhor ter de usar algo assim.

é como eu ja disse, se formos pensar como desenvolvedores, o mundo perfeito seria aquele onde OO domina e o Java comanda… mas não é assim… as empresas dão muito mais valor pro banco, a minha por ex, da a bunda pro Oracle (com o perdão da palavra)… pro meu chefe, J2EE é um emaranhado de JSP acessando o oracle direto… :???:

Isso é a pura verdade, mas não temos que pensar só como desenvolvedores não matheus, temos que pensar em questões financeiras, em optimização, em vigilancias.
Java é uma linguagem ótimo, achamos madura. mas em um contexto global só nós achamos realmente ela madura, como seu chefe disse J2EE é Jsp acessando ao banco. como o outro topico abordado por vc foi citado os frameworks não interessa a ele o meio… mas o final ele sabe que é o jsp mostrando os dados do banco.
Muito está sendo investido em bdoo, mas muito mais já foi investido em bd er. creio que temos que ser coerentes e saber usar o java em beneficio, usando o que mais nos torna produtivos com a estrutura já adiquirida, sugerida para tal sistema. usando de alguns artificios que o java nos da.

Bem,

só digo o seguinte:
Não existe verdades absolutas no desenvolvimento, há momentos em que é melhor usar um framework e casos em que um código puro resolve.
não há ninguém que utilize o struts por exemplo que em algum momento não tenha que usar jsp, simplemsente por que o struts não resolve tudo.
e não adianta tentar.
mesma coisa com banco de dados, sempre chega a hora em que é necessário colocar código sql e pronto.
é igual projeto, fica um ano fazendo um projeto de hello world, chega na hora de implementar acaba tendo que mudar alguma coisa, ou não dá pra fazer assim, etc… se projeto resolvesse tudo não precisaria de programadores, faz um a ferramenta pra projeto que ela implementa pra você, mas a gente sabe que não é assim.

se alguém puder provar o contrário das afirmações acima, por favor leia novamente.

Abraço
Andrei

Opa…

perdi toda a bagunça por aqui =\ que droga… não ter internet em casa eh uma merda =\ e o trampo trava tudo que eh coisa =\ foda foda…

Bom, mas tbm quero falar alguma coisa, mas ja falaram quase tudo… mas vamos la…

Uma coisa que falaram bastante aqui, foi do uso das tecnologias, que devem ser ponderadas né…
uma coisa que eu li, acho qeu foi o Volnei que falou que eu concordo, que é o caso de : Para que SQL’s dinâmicas se eu sei o que minha aplicação vai fazer?! hahahaha muito boa!! =)

Bom, eu sou da opinião que é preciso saber tudo isso ai, e cada projeto éum projeto, e cabe a vc escolher qual tecnologia usar no projeto, se um Prevayler for a melhor opção, cabe a vc decidir… porém, eu ainda Fico com o seguinte modelo (DAO + Command) satisfaz mutcho bien todas as necessidades…

=)

ps: eu li ontem a noite as msg, e tinha mais idéias para falar,mas agora num lembro mais do quefoi tratado =\

Abraços!

existe algum BD orientado a objetos q seja free?? :?:

tem um… db40… ou algo assim - GPL! não use em aplicações comerciais -

tem o caché tb, vc pode baixar um demo

…parou pq??? pq parou??? baixem o draft do documento q descreve a persistência na especificação do EJB 3, q vai vir pra ser usada tanto em J2EE quanto em J2SE… dêem uma lida… just for fun

Link direto para o pdf:
http://192.18.97.134/ECom/EComTicketServlet/BEGIN373FDC1B140AFD085CC66859E8D712BC/-[telefone removido]/735136683/1/586850/586838/735136683/2ts+/westCoastFSEND/ejb-3_0-edr2-spec-oth-JSpec/ejb-3_0-edr2-spec-oth-JSpec:2/ejb-3_0-edr2-spec-persistence.pdf

Ae galera, comecei com Java faz pouco tempo, vim de Delphi, 5 anos, imaginem o sufoco…

Mas uma coisa que to percebendo é esse preconceito com Sql e algo que me indgna, preconceito com um bd …

Acho que se vc for desenvolver um sistema para um petshop é uma coisa, usa oq quiser lah, hibernate, dao puro, prevayler, ou faz em arquivo de texto, vc nunca vai ter problemas…

Agora, no meu caso, um sistemam, p/ call center, resposanvel por fazer pesquisas com o cleinte… com centenas de regras de fluxo e outras centenas de regras de validação … n tipos de clientes, de n estados, de n cidades… tendo que ser adaptavel a qq tipo de pesquisa…

chuchu beleza fazer em Java, agora, sem Bd, impossivel…
pricipalmente quando o cliente que solicitou o serviço de pesquisas liga pedindo relatórios homéricos querendo isso em dez min … prevayler vaipro saco!

hibernate nesse caso, não da, os sqls p/ regras de fluxo são de doer os olhos …

Outra coisa que eu não me conformo eh desenvolvedor não querer saber sql… não sei se eh pq sempre trabalhei sendo pau p/ toda obra, tipo, precisa de um dba, tamu lah, precisa de um desenvolvedor, tamu lah …

vc sabe tudo oq o seu sistema vai fazer, todas as condições, obviamente sabe os Sqls … fora q os bds te dão ferramentas p/ te ajudar e muito, existem as views por exemplo … seus dados tão lah, prontinhos do jeito q vc quer, eh soh chamar …

acho q oq precisa ser feito eh um jeito viavel de unir as duas coisas …
Hibernate, Prevayler te ajudam muito p/ trabalhar com “poucos” dados e relacionamentos simples… fugiu disso, sql na mão, funções dentro do bd e assim vai …

minha opinião foge do post e foge mto ainda do nivel de vcs, comecei com java a pouco tempo, mas eh a opinião de quem tah de fora…

espero não ter falado demais … hehehe

abraços

o argumento q os kra usam eh d q a aplicacao tem q ser independente d BD…

mas eu nao acho q uma empresa q tenha um oracle ou um banco free como firebird ou postgresql qeira muda d banco toda hora…

c alguem pedi pra mim faze um sistema q use access, sqlserver, paradox ou algum otro banco microsoft eu nao faco d jeito nenhum

“LichKing”:

o argumento q os kra usam eh d q a aplicacao tem q ser independente d BD…

Uma empresa que tem Oracle, nunca vai querer mudar de Banco, com certeza! O Postgress é uma boa opção, imita em muito o Oracle, e eu acho ele muito bom mesmo.

“LichKing”:

c alguem pedi pra mim faze um sistema q use access, sqlserver, paradox ou algum otro banco microsoft eu nao faco d jeito nenhum

“noelrocha”:

acho q oq precisa ser feito eh um jeito viavel de unir as duas coisas …
Hibernate, Prevayler te ajudam muito p/ trabalhar com “poucos” dados e relacionamentos simples… fugiu disso, sql na mão, funções dentro do bd e assim vai …

Abraços!

Banco de dados pos relacional, orietado a objetos.
Eh free para os desenvolvedores e uso nao comercial. É preciso apenas ter licensa para o servidor.

http://www.intersystems.com/cache/

ou

http://www.intersystems.com.br/cgi-bin/nph-mgwcgi?MGWCHD=0&wlapp=ISC&guid=qh4A6optDbGjVKp2EzaQDgYNMnUj4U