Artigos Java JPA/Hibernate ou NoSQL, qual utilizar?

De que se trata o artigo:

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. Por meio de análises claras e objetivas, serão apresentadas algumas limitações de cada tecnologia e o que isso pode afetar nas fases de projeto e desenvolvimento. Alguns trechos de código também serão apresentados com o intuito de demonstrar a complexidade ou simplicidade do recurso quando comparado ao outro. Após a apresentação das características, será apontado quando utilizar e não utilizar cada uma das duas tecnologias.

Em que situação o tema é útil:

Para desenvolvedores e projetistas de software que estão em dúvida quanto a qual recurso adotar em seu projeto ou que simplesmente estão à procura de uma nova tecnologia.

Resumo DevMan:

A tecnologia ORM já vem sendo utilizada há algum tempo, principalmente depois da criação do framework Hibernate e da especificação JPA. Juntos, esses dois recursos podem solucionar muitos problemas de software que necessitem de um meio simplificado e eficiente de persistência. Em contrapartida, com uma forma contrária de funcionamento, os bancos de dados NoSQL vêm ganhando espaço entre os desenvolvedores e cientistas da computação há alguns anos. Juntamente com essas tecnologias muitos questionamentos surgem em relação às suas características principais, como por exemplo: Qual delas é a mais segura? Qual é a mais rápida? As duas são totalmente íntegras? Este artigo auxilia o leitor na escolha de uma das duas tecnologias para o desenvolvimento de seus sistemas, de maneira clara e objetiva, apontando vantagens e desvantagens de cada uma e quando devem ou não devem ser utilizadas.

Autores: Everton Coimbra de Araújo e 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).

No modelo ACID, a Atomicidade refere-se à transação. Isso quer dizer que, se a transação do banco de dados falhar, se ocorrer um mínimo erro em qualquer parte da instrução SQL ou em qualquer parte do meio físico, nada é persistido. Uma informação só é persistida caso todas as outras da mesma transação estejam regularizadas e prontas para serem persistidas. Assim, SGBDs (Sistemas Gerenciadores de Banco de Dados) que possuem essa função bem definida, ao sofrerem desligamentos inesperados ou pequenas falhas de hardware por parte de seus servidores, não perderão quantidades significativas de dados ou não terão apenas parte das informações de uma transação gravadas no disco rígido. Geralmente, a atomicidade vem acompanhada da instrução commit. Commit significa “efetuar”, “cometer” e é essa instrução que fecha a transação e permite que a consolidação dos dados seja feita. Bancos de dados NoSQL não garantem essa segurança, uma vez que não possuem transações. Sendo assim, ao executar uma instrução NoSQL, as informações serão persistidas no decorrer da execução e não como ocorre em bancos de dados relacionais (somente após o ...

Quer ler esse conteúdo completo? Tenha acesso completo