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!
dê seu feedback
post favorito
JPA 2.0 – Persistência a toda prova - Java Magazine 81
O artigo aborda as inovações realizadas na API JPA (Java Persistence API) em sua versão 2.0, lançada em dezembro de 2009 juntamente com o Java EE 6. As novidades discutidas no artigo são caracterizadas como recursos de grande importância para a adoção dessa API especialmente em sistemas legados.
Java Magazine 81
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 81
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 81
JPA 2.0 – Persistência a toda prova
A API de persistência Java agora muito mais poderosa
O lançamento da JPA – Java Persistence API (versão 1.0), em Maio de 2006, representou um passo importante da plataforma Java em relação à persistência de dados (veja o quadro “JPA 1.0”). A API JPA é utilizada nas aplicações Java para permitir a gravação/leitura de objetos em bancos de dados relacionais de forma transparente. Essa técnica é conhecida como ORM (Object Relational Mapping) e já era utilizada por frameworks de persistência proprietários como Hibernate, TopLink, Kodo, entre outros.
Se compararmos o tempo de existência dos frameworks de persistência com a JPA, vamos perceber que essa API demorou para ser criada na plataforma Java. Mas essa demora acabou por trazer alguns benefícios, entre eles, a capacidade de utilizarmos implementações de diferentes fornecedores, não ficando presos a um framework em particular, e a flexibilidade de utilizarmos esses recursos de persistência tanto em aplicações que rodam dentro de servidores quanto em aplicações stand-alone.
Desde seu lançamento, muitas empresas, com visão de futuro, foram motivadas a migrar suas aplicações para JPA e acabaram enfrentando alguns problemas. Por ser a primeira versão, o principal objetivo da especificação de JPA foi o de disponibilizar os recursos básicos necessários para a persistência de dados. O resultado foi que cerca de 10 a 20% dos recursos dos frameworks já existentes não foram inseridos na versão 1.0. Isso obrigou as pessoas a utilizarem a API JPA combinada com outros frameworks de persistência que já possuíam recursos diferenciados para o mapeamento de objetos, principalmente para bancos de dados legados.
Na versão 2.0, lançada em Dezembro de 2009 juntamente com o Java EE 6, a API JPA surge muito mais madura. Além de reduzir as restrições para oferecer maior flexibilidade no desenvolvimento do modelo de objetos, a API incorporou a maioria dos recursos existentes nos frameworks proprietários que faziam falta na versão 1.0, sendo que grande parte das melhorias foram feitas para atender às necessidades de mapeamento dos sistemas legados. Tais mudanças objetivaram principalmente a possibilidade das aplicações Java se tornarem mais independentes de frameworks proprietários.
JPA 2.0 foi especificada pela JSR 317 do Java EE 6 e sua implementação de referência é o EclipseLink, disponibilizado no servidor GlassFish V3 (veja o quadro “TopLink x EclipseLink”). Por ser considerada uma das especificações mais maduras do Java EE 6, seus recursos já podem ser utilizados nas aplicações Java, desde que a implementação JPA utilizada já suporte essa nova especificação.
Neste artigo vamos abordar as principais mudanças na API JPA 2.0, em particular, as melhorias realizadas no modelo de mapeamento objeto-relacional, os novos recursos adicionados à JPA Query Language e as APIs de MetaModel e Criteria.
JPA 1.0
JPA é utilizado nas aplicações Java para permitir o armazenamento de dados em bancos de dados relacionais sem a necessidade de escrever código JDBC (Java Database Connectivity), utilizar componentes EJB Entity Beans ou ficar preso a um framework de persistência proprietário
Por meio de JPA, o programador delega as operações de manipulação de tabelas para um framework de persistência que implementa a API JPA.
Utilizando recursos de ORM (Object Relational Mapping), o programador cria mapeamentos das classes Java e seus relacionamentos para as tabelas do banco de dados. Esses mapeamentos permitem que um framework, que suporte JPA (como Hibernate, Oracle TopLink, Kodo, OpenJPA, entre outros), faça as devidas inserções, buscas, exclusões e alterações nos dados da aplicação nas tabelas do banco de dados, quando for solicitado. Dessa forma, o código da aplicação fica independente de frameworks de persistência, pois todo o código utilizado para manipular o banco de dados passa a ser da API JPA.
A grande vantagem dessa API é que ela permite a troca do framework de persistência, e consequentemente do sistema de gerenciamento de banco de dados (SGBD), de forma transparente para a aplicação, ou seja, podemos optar por soluções de implementação diferentes de acordo com o perfil do projeto ou do banco de dados.
TopLink x EclipseLink "
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
A API de persistência Java agora muito mais poderosa
O lançamento da JPA – Java Persistence API (versão 1.0), em Maio de 2006, representou um passo importante da plataforma Java em relação à persistência de dados (veja o quadro “JPA 1.0”). A API JPA é utilizada nas aplicações Java para permitir a gravação/leitura de objetos em bancos de dados relacionais de forma transparente. Essa técnica é conhecida como ORM (Object Relational Mapping) e já era utilizada por frameworks de persistência proprietários como Hibernate, TopLink, Kodo, entre outros.
Se compararmos o tempo de existência dos frameworks de persistência com a JPA, vamos perceber que essa API demorou para ser criada na plataforma Java. Mas essa demora acabou por trazer alguns benefícios, entre eles, a capacidade de utilizarmos implementações de diferentes fornecedores, não ficando presos a um framework em particular, e a flexibilidade de utilizarmos esses recursos de persistência tanto em aplicações que rodam dentro de servidores quanto em aplicações stand-alone.
Desde seu lançamento, muitas empresas, com visão de futuro, foram motivadas a migrar suas aplicações para JPA e acabaram enfrentando alguns problemas. Por ser a primeira versão, o principal objetivo da especificação de JPA foi o de disponibilizar os recursos básicos necessários para a persistência de dados. O resultado foi que cerca de 10 a 20% dos recursos dos frameworks já existentes não foram inseridos na versão 1.0. Isso obrigou as pessoas a utilizarem a API JPA combinada com outros frameworks de persistência que já possuíam recursos diferenciados para o mapeamento de objetos, principalmente para bancos de dados legados.
Na versão 2.0, lançada em Dezembro de 2009 juntamente com o Java EE 6, a API JPA surge muito mais madura. Além de reduzir as restrições para oferecer maior flexibilidade no desenvolvimento do modelo de objetos, a API incorporou a maioria dos recursos existentes nos frameworks proprietários que faziam falta na versão 1.0, sendo que grande parte das melhorias foram feitas para atender às necessidades de mapeamento dos sistemas legados. Tais mudanças objetivaram principalmente a possibilidade das aplicações Java se tornarem mais independentes de frameworks proprietários.
JPA 2.0 foi especificada pela JSR 317 do Java EE 6 e sua implementação de referência é o EclipseLink, disponibilizado no servidor GlassFish V3 (veja o quadro “TopLink x EclipseLink”). Por ser considerada uma das especificações mais maduras do Java EE 6, seus recursos já podem ser utilizados nas aplicações Java, desde que a implementação JPA utilizada já suporte essa nova especificação.
Neste artigo vamos abordar as principais mudanças na API JPA 2.0, em particular, as melhorias realizadas no modelo de mapeamento objeto-relacional, os novos recursos adicionados à JPA Query Language e as APIs de MetaModel e Criteria.
JPA 1.0
JPA é utilizado nas aplicações Java para permitir o armazenamento de dados em bancos de dados relacionais sem a necessidade de escrever código JDBC (Java Database Connectivity), utilizar componentes EJB Entity Beans ou ficar preso a um framework de persistência proprietário
Por meio de JPA, o programador delega as operações de manipulação de tabelas para um framework de persistência que implementa a API JPA.
Utilizando recursos de ORM (Object Relational Mapping), o programador cria mapeamentos das classes Java e seus relacionamentos para as tabelas do banco de dados. Esses mapeamentos permitem que um framework, que suporte JPA (como Hibernate, Oracle TopLink, Kodo, OpenJPA, entre outros), faça as devidas inserções, buscas, exclusões e alterações nos dados da aplicação nas tabelas do banco de dados, quando for solicitado. Dessa forma, o código da aplicação fica independente de frameworks de persistência, pois todo o código utilizado para manipular o banco de dados passa a ser da API JPA.
A grande vantagem dessa API é que ela permite a troca do framework de persistência, e consequentemente do sistema de gerenciamento de banco de dados (SGBD), de forma transparente para a aplicação, ou seja, podemos optar por soluções de implementação diferentes de acordo com o perfil do projeto ou do banco de dados.
TopLink x EclipseLink "
ATENÇÃO! 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!
3 COMENTÁRIOS
Jefferson Moreira Da Silva
Ha situacoes onde escrever em Criteria deixa a consulta "criptografica", ou seja, para outro desenvolver ler da muito mais trabalho do que se estivesse o JPQL direto pra ele analisar. Fora o fato que se escreve muito mais por conta deste "purismo" de uso de OO. Ha pros e contras do Criteria, nao apenas pros...
[há +1 ano] -
Responder
Jonas Alves De Almeida Pereira
Primeiramente parabéns pelo artigo, achei bastante interessante e esclarecedor. Ao utilizar a diretiva de compilação -processor no NetBeans, ele gera os *_.java dentro do build. Gostaria de saber se existe alguma forma de gerar os metaModels dentro do mesmo package das entidades. Obrigado.
[há +1 ano] -
Responder
Você está em:
canal Java
Publicidade
1
0
