Apresentando a API Morphia – Revista Java Magazine 109

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (2)  (0)

O artigo apresenta a API Morphia, um projeto desenvolvido no Google Code que tem como objetivo facilitar o desenvolvimento das classes de persistência em aplicações que fazem uso do banco de dados NoSQL MongoDB.

Do que se trata o artigo:

O artigo apresenta a API Morphia, um projeto desenvolvido no Google Code que tem como objetivo facilitar o desenvolvimento das classes de persistência em aplicações que fazem uso do banco de dados NoSQL MongoDB.


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

Este tema é útil para os desenvolvedores que buscam uma maneira mais rápida e ágil de desenvolver o mecanismo de persistência em aplicações que utilizam o banco de dados NoSQL MongoDB.

Apresentando a API Morphia:

Morphia é uma API desenvolvida pelo Google Code que tem como objetivo tornar mais simples a interação de uma aplicação Java com o banco de dados NoSQL MongoDB. Durante o artigo serão abordados métodos e classes fornecidos pelo Morphia que reduzem a complexidade no desenvolvimento. Veremos também a excelente forma de mapear classes de entidades através do uso de anotações. Os padrões Singleton e DAO também serão abordados para um maior proveito dos recursos dessa API.

Nos últimos anos, mais precisamente a partir de 2009, um novo conceito de banco de dados passou a estar em evidência no mundo do desenvolvimento de software. O NoSQL (acrônimo para Not Only SQL) apareceu com muita força como uma solução para problemas que passaram a existir em bancos de dados relacionais. Entre esses problemas temos, principalmente, a grande quantidade de dados armazenados, que acabam forçando o aumento do uso da memória física (Hard Disk) de maneira muito rápida, e também a necessidade dos servidores serem de alta performance para atender o grande número de acessos simultâneos, o que elevou muito os custos de operação. Embora o conceito de NoSQL tenha ganhado força há poucos anos, o termo foi cunhado em 1998 por Carlo Strozzi, para descrever seu projeto de banco de dados de código livre sem uma interface SQL. Desde então, vários bancos de dados foram desenvolvidos com base nos conceitos NoSQL, entre eles o Neo4J, Cassandra, CouchDB, Hbase e MongoDB. O Cassandra, por exemplo, teve como participação em seu desenvolvimento a Apache Foundation e os desenvolvedores do Facebook, que buscavam novas soluções para resolver problemas de armazenamento e velocidade, o que já se tornava difícil conseguir com os atuais bancos de dados relacionais. Com este mesmo objetivo, empresas como a Amazon (Amazon Dynamo), Twitter (Cassandra), LinkedIn (Voldemort), Yahoo (Hbase), Engine Yard (MongoDB) e Google (MongoDB) escolheram o banco de dados NoSQL que mais atendia as suas necessidades. Algumas empresas como Facebook e Amazon, tiveram, até mesmo, participação direta no desenvolvimento da tecnologia escolhida.

Porém, diferentemente dos SGBDs tradicionais, que possuem o SQL como linguagem padrão, o que torna uma mesma instrução portável para qualquer banco de dados relacional, o NoSQL ainda não possui um padrão. Sendo assim, cada empresa que desenvolve um banco de dados seguindo os conceitos do NoSQL, acaba não tendo um padrão a seguir, impossibilitando que, por exemplo, um mesmo código usado para persistência em uma aplicação com Cassandra seja compatível com o MongoDB. Deste modo, cada organização que desenvolve um banco NoSQL precisa disponibilizar sua própria API de acesso (driver) para possibilitar a conexão entre a aplicação e o banco.

A empresa 10gem, fundadora do MongoDB, disponibiliza um driver para acesso e manipulação aos dados deste banco. Este driver, conhecido também como API MongoDB, fornece vários tipos de métodos para todas as operações de CRUD. O MongoDB foi desenvolvido de maneira a persistir seus dados em forma de documentos, que por sua vez são armazenados em coleções. Fazendo uma relação com os bancos de dados relacionais, podemos dizer que as coleções substituem as tabelas e os documentos substituem as linhas de uma tabela. A estrutura de um documento MongoDB, manipulada pelo programador junto a API, é do tipo JSON. Já o banco realiza o armazenamento deste documento JSON em um formato binário denominado BSON. O formato JSON trabalha com informações registradas através de chave e valor, como, por exemplo, {“nome”: “Marcio”, “sexo”: “M”}, enquanto uma tabela armazena dados em linhas e colunas. Nessa solução NoSQL, cada documento deverá ter um identificador único que poderá ser gerado automaticamente, e por padrão, este identificador se tornará um índice. Outros índices também podem ser inseridos nos documentos, o que é altamente recomendável para o retorno mais rápido em consultas realizadas dentro de uma grande quantidade de dados. No entanto, a manipulação dos dados a partir da API MongoDB é um tanto complexa para o programador. Isto porque, como o banco trabalha com objetos JSON (chave/valor), o programador precisará converter os objetos Java em JSON e vice-versa, o que pode ser trabalhoso quando o projeto possuir um grande número de classes a serem persistidas.

Para agilizar a programação com MongoDB, o Google Code desenvolveu o projeto Morphia, uma API que reduz a complexidade e aumenta a produtividade dos desenvolvedores que utilizam este banco de dados. Talvez uma das principais vantagens do Morphia seja o uso de anotações nas classes de domínio. Estas anotações funcionam como uma espécie de mapeamento, semelhante ao existente na especificação JPA. Outro fator interessante fornecido pelo projeto Morphia é uma pré-implementação do padrão DAO ("

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?