Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
JPA/Hibernate ou NoSQL, qual utilizar? - Revista Java Magazine 103
O artigo traz uma análise entre as vantagens e desvantagens da utilização da especificação ORM com JPA e Hibernate e o uso de bancos de dados não relacionais (NoSQL) para o desenvolvimento de aplicações Java.
[fechar]
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
Java Magazine 103
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 103
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 103
Por; EVERTON COIMBRA DE ARAÚJO / GIOVANI GUIZZO
Em sistemas orientados a objetos, um grande impedimento é encontrado quando se diz respeito à persistência. Pode não parecer tão problemático assim, mas a transformação de objetos em dados persistentes no espaço relacional pode ser um trabalho árduo. O grande problema nessa situação são as duas estruturas totalmente diferentes que são empregadas em cada camada do sistema. No mundo relacional são criadas tabelas e colunas para armazenar informações, enquanto no modelo orientado a objetos, classes e objetos são prevalecentes.
Para solucionar esse problema, há alguns anos era preciso criar instruções SQL para transformar objetos em tuplas do banco de dados, porém muito tempo era perdido com essa prática, tanto no momento do desenvolvimento, quanto no de testes. Além de o desenvolvedor precisar implementar o código para a criação do banco de dados totalmente compatível com o modelo orientado a objetos, a cada nova operação de inserção, alteração, exclusão ou pesquisa, uma quantidade imensa de código no sistema era gerada a fim de tratar essa incompatibilidade de estruturas. Em longo prazo, isso tudo se tornava um trabalho exaustivo, não reutilizável e, muitas vezes, falho.
Surge então o conceito de ORM (Object-Relational Mapping ou Mapeamento Objeto-Relacional). Ele propõe a transformação de classes e objetos em tabelas e tuplas de maneira invisível, fácil e reutilizável ao programador. Ao invés do programador ter que criar todas as instruções SQL para as operações no banco de dados, ele pode utilizar um framework capaz de fazer essas operações sem sair do paradigma de orientação a objetos, de maneira transparente. Assim, todo aquele trabalho árduo de codificação e testes se resume a algumas configurações e um mínimo de código, sem manter um contato direto com o banco de dados.
Até então o ORM era só um conceito para qualquer linguagem orientada a objetos e para que esse conceito saísse do papel, em 2006 a Sun lançou a JSR 220 especificando os Enterprise JavaBeans (EJB) 3.0 (ver Links). Juntamente com o EJB 3.0, a Java Persistence API 1.0 foi disponibilizada ao público desenvolvedor. Mais posteriormente, em 2009, a JSR 317 foi divulgada, dessa vez contendo apenas a especificação JPA 2.0 (ver Links). Em suma, essa API apresenta anotações e interfaces, para que os frameworks que forem desenvolvidos sigam um padrão de funcionamento. A JPA não possui grande quantidade de código. De fato ela não faz o papel de um framework ORM. Ela apenas dita como eles deverão funcionar na plataforma Java.
É nesse contexto que o Hibernate entra. O Hibernate faz o papel de um provedor de persistência. Um provedor de persistência geralmente é um framework ORM que implementa as especificações JPA e disponibiliza toda a programação necessária para o efetivo Mapeamento Objeto-Relacional e a persistência de dados. Mesmo o Hibernate tendo um papel tão fundamental na persistência de dados e no Mapeamento Objeto-Relacional, todo o acesso às suas funcionalidades acontece de uma maneira quase que transparente, uma vez que o programador utiliza na maior parte do tempo apenas as anotações e interfaces disponibilizadas pela JPA.
O Hibernate surgiu antes da especificação JPA e foi ele quem motivou a criação dessa especificação. Quando o Hibernate ganhou popularidade, a Sun previu que muitos outros frameworks seriam desenvolvidos e se uma maneira padronizada de mapeamento objeto-relacional não fosse criada, os desenvolvedores desses outros frameworks sairiam prejudicados caso optassem por uma migração da ferramenta. Prejudicados pelo fato de não poderem reutilizar código para persistência, configurações e mapeamentos.
É importante lembrar que existem outros provedores ORM e não apenas o Hibernate. Alguns exemplos são o EclipseLink, OJB, OpenJPA e DataNucleus. Desses exemplos, o mais notável é o EclipseLink. Ele foi o RI (Reference Implementation) do JPA 2 e hoje é um dos mais utilizados.
Muitas corporações mundiais já adotaram o Hibernate como sua ferramenta de desenvolvimento. Alguns exemplos são: Sony, AT&T, PwC e Cisco. Para mais informações sobre ORM e Hibernate, veja a seção Links.
Os bancos de dados NoSQL
NoSQL (Not only SQL) é muito mais do que apenas um tipo de banco de dados. Esse termo é bem abrangente, envolvendo vários conceitos, tecnologias e estruturas. Ele foi criado em 1998 por Carlo Strozzi e teve como objetivo substituir bancos de dados relacionais, a fim de prover uma maneira mais leve e dinâmica de armazenamento de dados sem expor a utilização da linguagem SQL.
Outro aspecto importante no qual os bancos de dados NoSQL se diferenciam, é a maneira como operam. Enquanto os bancos de dados relacionais se baseiam no conceito ACID (Atomicidade, Consistência, Isolamento e Durabilidade), bancos de dados NoSQL utilizam o conceito BASE (Basically Available, Soft state, Eventually consistent).
"
Este é um post disponível para assinantes MVP
Em sistemas orientados a objetos, um grande impedimento é encontrado quando se diz respeito à persistência. Pode não parecer tão problemático assim, mas a transformação de objetos em dados persistentes no espaço relacional pode ser um trabalho árduo. O grande problema nessa situação são as duas estruturas totalmente diferentes que são empregadas em cada camada do sistema. No mundo relacional são criadas tabelas e colunas para armazenar informações, enquanto no modelo orientado a objetos, classes e objetos são prevalecentes.
Para solucionar esse problema, há alguns anos era preciso criar instruções SQL para transformar objetos em tuplas do banco de dados, porém muito tempo era perdido com essa prática, tanto no momento do desenvolvimento, quanto no de testes. Além de o desenvolvedor precisar implementar o código para a criação do banco de dados totalmente compatível com o modelo orientado a objetos, a cada nova operação de inserção, alteração, exclusão ou pesquisa, uma quantidade imensa de código no sistema era gerada a fim de tratar essa incompatibilidade de estruturas. Em longo prazo, isso tudo se tornava um trabalho exaustivo, não reutilizável e, muitas vezes, falho.
Surge então o conceito de ORM (Object-Relational Mapping ou Mapeamento Objeto-Relacional). Ele propõe a transformação de classes e objetos em tabelas e tuplas de maneira invisível, fácil e reutilizável ao programador. Ao invés do programador ter que criar todas as instruções SQL para as operações no banco de dados, ele pode utilizar um framework capaz de fazer essas operações sem sair do paradigma de orientação a objetos, de maneira transparente. Assim, todo aquele trabalho árduo de codificação e testes se resume a algumas configurações e um mínimo de código, sem manter um contato direto com o banco de dados.
Até então o ORM era só um conceito para qualquer linguagem orientada a objetos e para que esse conceito saísse do papel, em 2006 a Sun lançou a JSR 220 especificando os Enterprise JavaBeans (EJB) 3.0 (ver Links). Juntamente com o EJB 3.0, a Java Persistence API 1.0 foi disponibilizada ao público desenvolvedor. Mais posteriormente, em 2009, a JSR 317 foi divulgada, dessa vez contendo apenas a especificação JPA 2.0 (ver Links). Em suma, essa API apresenta anotações e interfaces, para que os frameworks que forem desenvolvidos sigam um padrão de funcionamento. A JPA não possui grande quantidade de código. De fato ela não faz o papel de um framework ORM. Ela apenas dita como eles deverão funcionar na plataforma Java.
É nesse contexto que o Hibernate entra. O Hibernate faz o papel de um provedor de persistência. Um provedor de persistência geralmente é um framework ORM que implementa as especificações JPA e disponibiliza toda a programação necessária para o efetivo Mapeamento Objeto-Relacional e a persistência de dados. Mesmo o Hibernate tendo um papel tão fundamental na persistência de dados e no Mapeamento Objeto-Relacional, todo o acesso às suas funcionalidades acontece de uma maneira quase que transparente, uma vez que o programador utiliza na maior parte do tempo apenas as anotações e interfaces disponibilizadas pela JPA.
O Hibernate surgiu antes da especificação JPA e foi ele quem motivou a criação dessa especificação. Quando o Hibernate ganhou popularidade, a Sun previu que muitos outros frameworks seriam desenvolvidos e se uma maneira padronizada de mapeamento objeto-relacional não fosse criada, os desenvolvedores desses outros frameworks sairiam prejudicados caso optassem por uma migração da ferramenta. Prejudicados pelo fato de não poderem reutilizar código para persistência, configurações e mapeamentos.
É importante lembrar que existem outros provedores ORM e não apenas o Hibernate. Alguns exemplos são o EclipseLink, OJB, OpenJPA e DataNucleus. Desses exemplos, o mais notável é o EclipseLink. Ele foi o RI (Reference Implementation) do JPA 2 e hoje é um dos mais utilizados.
Muitas corporações mundiais já adotaram o Hibernate como sua ferramenta de desenvolvimento. Alguns exemplos são: Sony, AT&T, PwC e Cisco. Para mais informações sobre ORM e Hibernate, veja a seção Links.
Os bancos de dados NoSQL
NoSQL (Not only SQL) é muito mais do que apenas um tipo de banco de dados. Esse termo é bem abrangente, envolvendo vários conceitos, tecnologias e estruturas. Ele foi criado em 1998 por Carlo Strozzi e teve como objetivo substituir bancos de dados relacionais, a fim de prover uma maneira mais leve e dinâmica de armazenamento de dados sem expor a utilização da linguagem SQL.
Outro aspecto importante no qual os bancos de dados NoSQL se diferenciam, é a maneira como operam. Enquanto os bancos de dados relacionais se baseiam no conceito ACID (Atomicidade, Consistência, Isolamento e Durabilidade), bancos de dados NoSQL utilizam o conceito BASE (Basically Available, Soft state, Eventually consistent).
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
O que você achou deste post?
Cursos relacionados
Publicidade
