Você está na página 1de 14

CHAPTER 1 Introduction

Introduo
As aplicaes corporativas so definidas pela sua necessidade de coletar, processar,
transformar e apresentar relatrios sobre grandes quantidades de informao. E, claro, que
a informao tem que ser mantido em algum lugar. Armazenamento e recuperao de dados
um negcio multibilionrio, evidenciado em parte pelo crescimento do mercado de banco de
dados, bem como o surgimento de servios de armazenamento baseados em nuvem. Apesar
de todas as tecnologias disponveis para o gerenciamento de dados, projetistas de aplicaes
ainda gastam muito do seu tempo a tentar mover seus dados de forma eficiente para e de
armazenamento. Apesar do sucesso da plataforma Java tem tido em trabalhar com sistemas
de banco de dados, por um longo tempo sofreu do mesmo problema que tem atormentado
outras linguagens de programao orientada a objeto. Movendo dados e para trs entre um
sistema de banco de dados eo modelo de objeto de um aplicativo Java foi muito mais difcil do
que precisava ser. Desenvolvedores Java ou escreveu um monte de cdigo para converter os
dados de linha e coluna em objetos ou encontravam-se vinculados a estruturas proprietrias
que tentaram esconder o banco de dados a partir deles. Felizmente, uma soluo padro, o
Java Persistence API (JPA), foi introduzido na plataforma para preencher a lacuna entre os
modelos de domnio de orientao a objetos e sistemas de banco de dados relacionais. Neste
livro vamos apresentar a verso 2.1 do Java Persistence API e explorar tudo o que ele tem
para oferecer aos desenvolvedores. Um dos seus pontos fortes que ele pode ser encaixados
em qualquer camada, camadas, ou quadro um aplicativo precisar dela para se estar. Se voc
est construindo aplicativos de servidor cliente para coletar dados de formulrios em uma
aplicao Swing ou a construo de um web site utilizando a mais recente aplicao quadro,
JPA pode ajud-lo a fornecer persistncia de forma mais eficaz. Para definir o cenrio para JPA,
este captulo assume pela primeira vez um passo para trs para mostrar onde ns estivemos
e quais os problemas que estamos tentando resolver. A partir da, vamos olhar para a histria
da especificao e dar-lhe uma viso de alto nvel do que ela tem para oferecer.

Bancos de Dados Relacionais


Muitas formas de dados que persistem surgiram e desapareceram ao longo dos anos, e nenhum conceito teve mais
poder de permanncia do que o banco de dados relacional. Mesmo na era da nuvem, quando "Big Data" e "NoSQL"
roubar regularmente as manchetes, servios de banco de dados relacionais esto na demanda consistente para
permitir que aplicaes corporativas atuais em execuo na nuvem. Enquanto valor-chave e lojas NoSQL orientados
a documentos tm o seu lugar, lojas relacionais continuam a ser os mais populares bancos de dados com finalidades
gerais de existncia, e eles so, onde a grande maioria dos dados corporativos do mundo esto armazenados. Eles
so o ponto de partida para cada aplicativo empresarial e muitas vezes tm um tempo de vida que continua muito
tempo aps a aplicao desapareceu. Compreender dados relacionais a chave para o desenvolvimento
empresarial bem sucedida. Desenvolvimento de aplicaes para funcionar bem com sistemas de banco de dados
um obstculo comumente reconhecido de desenvolvimento de software. Uma boa parte do sucesso de Java pode ser
atribuda sua adoo generalizada para a construo de sistemas de banco de dados da empresa. A partir de sites
de consumo para gateways automatizados, aplicativos Java esto no centro de desenvolvimento de aplicaes
corporativas.

Mapeamento objeto-relacional
"O modelo de domnio tem uma classe. A base de dados tem uma tablea. Eles parecem
bastante semelhantes. Deve ser simples para converter um para o outro automaticamente.
"Este um pensamento que provavelmente todos j teve em um ponto ou outro durante a
gravao de mais um Data Access Object (DAO) para converter Java Database Connectivity
(JDBC) conjuntos de resultados em algo Orientado a Objeto. O modelo de domnio
semelhante o suficiente para o modelo relacional do banco de dados que parece clamar por
uma forma de fazer os dois modelos de falar uns aos outros. A tcnica de fazer a ponte entre
o modelo de objeto e do modelo relacional conhecido como mapeamento objeto-relacional,
muitas vezes referido como mapeamento OR ou simplesmente ORM. O termo vem da idia de

que somos de alguma forma o mapeamento dos conceitos de um modelo para outro, com o
objetivo de introduzir um mediador para gerenciar a transformao automtica de um para o
outro. Antes de entrar nos detalhes de mapeamento objeto-relacional, vamos definir um
breve manifesto do que a soluo ideal deveria ser.
Objetos, no tabelas: As candidaturas devero ser escritos em termos de modelo de
domnio, no vinculado ao modelo relacional. Deve ser possvel operar em e consultar contra
o modelo de domnio sem ter de express-la na linguagem relacional de tabelas, colunas e
chaves estrangeiras.
Convenincia, no ignorncia: ferramentas de mapeamento deve ser usado somente por
algum familiarizado com a tecnologia relacional. OU mapeamento no significado salvar os
desenvolvedores de compreender os problemas de mapeamento ou para escond-los
completamente. Ele destinado para aqueles que tm uma compreenso das questes e
saber o que eles precisam, mas que no querem ter que escrever milhares de linhas de
cdigo para lidar com um problema que j foi resolvido.
Discreto, no transparente: No razovel esperar que a persistncia ser transparente
porque um aplicativo precisa sempre ter o controle dos objetos que ele est persistentes e
estar ciente do ciclo de vida da entidade. A soluo no deve intrometer persistncia no
modelo de domnio, no entanto, e classes de domnio no deve ser obrigado a estender as
classes ou implementar interfaces, a fim de ser persistente.
dados legados, novos objetos: muito mais provvel que um aplicativo ter como alvo um
esquema de banco de dados relacional existente do que criar um novo. Suporte para
esquemas legado um dos casos mais relevantes de uso que iro surgir, e bem possvel
que essas bases de dados vai sobreviver a cada um de ns.
O suficiente, mas no muito: os desenvolvedores da empresa tem problemas para resolver,
e eles precisam de recursos suficientes para resolver esses problemas. O que eles no gostam
est sendo forado a comer um modelo de persistncia dos pesos pesados que apresenta
grande sobrecarga porque a resoluo de problemas que muitos nem sequer concordam
so problemas.
local, mas mvel: uma representao persistente de dados no precisa ser modelado como
um objeto remoto de pleno direito. A distribuio algo que existe como parte da aplicao,
no faz parte da camada de persistncia. As entidades que contm o estado persistente, no
entanto, deve ser capaz de viajar a qualquer camada precisa deles para que se um aplicativo
for distribudo, as entidades apoiar e no inibir uma arquitetura particular.
API padro, com implementaes conectveis: Grandes empresas com aplicaes
considerveis no quer correr o risco de ser acoplado a bibliotecas e interfaces especficas do
produto. Por dependendo apenas interfaces padro definidas, o aplicativo dissociado dos
APIs proprietrias e pode alternar implementaes se outro torna-se mais adequado.
Este parece ser um conjunto um tanto exigente de requisitos, mas aquele que nasceu de
ambos experincia prtica e necessidade. As aplicaes corporativas tm necessidades muito
especficas de persistncia, e esta lista de compras de itens uma representao
razoavelmente especfico da experincia da comunidade empresarial.

A diferena de impedncia
Os defensores de mapeamento objeto-relacional, muitas vezes descrever a diferena entre o
modelo de objeto e o modelo relacional como a incompatibilidade de impedncia entre os
dois. Esta uma descrio apropriada, porque o desafio de mapeamento um para o outro no
est nas semelhanas entre os dois, mas nos conceitos de cada um para o qual no existe
equivalente lgico nas other. Nas sees a seguir, vamos apresentar alguns bsico modelos
de domnio de orientao a objetos e uma variedade de modelos relacionais a persistir o
mesmo conjunto de dados. Como voc ver, o desafio de mapeamento objeto-relacional no
tanto a complexidade de um mapeamento nico, mas que h tantos meta possvel

mappings. The no explicar como chegar de um ponto a outro, mas a compreender o


estradas que podem ter que ser tomadas para chegar a um destino pretendido.
Classe Representao
Vamos comear esta discusso com uma classe simples. A Figura 1-1 mostra uma classe de
funcionrios com quatro atributos: id empregado, nome do empregado, a data comearam, e
salrio atual.

Agora, considere o modelo relacional mostrado na Figura 1-2. A representao ideal desta
classe na base de dados corresponde ao cenrio (A). Cada campo na classe mapeia
diretamente para uma coluna na tabela. A identificao do empregado torna-se a chave
primria. Com a exceo de algumas diferenas ligeiras de nomenclatura, este um
mapeamento simples.

No cenrio (B), vemos que a data de incio do empregado armazenado como trs colunas
separadas, cada um para o dia, ms e ano. Lembre-se que a classe usado um objeto Date
para representar este valor. Porque esquemas de banco de dados so muito mais difceis de
mudar, a classe deve ser forado a adotar a mesma estratgia de armazenamento, a fim de
manter a coerncia com o modelo relacional? Considere tambm o inverso do problema, na
qual a classe tinha usado trs campos, e a tabela utilizada uma coluna de data nica. Mesmo
um nico campo torna-se complexo para mapear quando o banco de dados e modelo de
objeto diferem em representao. Informaes de salrio considerada comercialmente
sensvel, por isso, pode ser sensato para colocar o valor do salrio diretamente na tabela EMP,
o qual pode ser usado para uma srie de finalidades. No cenrio (C), a tabela EMP foi dividido
de modo que a informao de salrio armazenado em uma tabela EMP_SAL separado. Isso
permite que o DBA para restringir o acesso SELECT na informao do salrio para aqueles
usurios que realmente necessitam dele. Com esse mapeamento, mesmo uma nica
operao de loja para a classe Employee agora requer inseres ou atualizaes de duas
tabelas diferentes. evidente que, mesmo armazenar os dados a partir de uma nica classe
na base de dados pode ser um exerccio desafiador. Ns preocupamo-nos com esses cenrios,

porque os esquemas de banco de dados reais em sistemas de produo nunca foram


projetados com modelos de objetos em mente. A regra de ouro em aplicaes empresariais
que as necessidades do trunfo de banco de dados as necessidades da aplicao. Na verdade,
geralmente h muitas aplicaes, algum objeto orientado e alguns baseados em Structured
Query Language (SQL), que recuperar a partir e armazenar os dados em um nico banco de
dados. A dependncia de mltiplas aplicaes no mesmo banco de dados significa que a
mudana do banco de dados afetaria cada uma das aplicaes, claramente uma opo
indesejvel e potencialmente caro. at o modelo de objeto para se adaptar e encontrar
maneiras de trabalhar com o esquema de banco de dados, sem deixar o design fsico dominar
o modelo de aplicativo lgico.

Relacionamentos
Objetos raramente existem isoladamente. Assim como relacionamentos em um banco de
dados, classes de domnio dependem e associar-se com outras classes de domnio. Considere
a classe de funcionrios introduzido na Figura 1-1. Existem muitos conceitos do domnio que
poderiam estar associados com um empregado, mas por agora vamos introduzir a classe de
domnio de endereo, para o qual um funcionrio pode ter no mximo uma instncia. Ns
dizemos que neste caso o funcionrio tem um relacionamento um-para-um com endereos,
representada no modelo Unified Modeling Language (UML) pela notao 0..1. Figura 1-3
demonstra essa relao.

Discutimos diferentes cenrios para representar o estado empregado na seo anterior, e do


mesmo modo que existem vrias abordagens para representar um relacionamento em um
esquema de banco de dados. Figura 1-4 demonstra trs cenrios diferentes de um
relacionamento um-para-um entre um empregado e um endereo.

O bloco de construo para as relaes no banco de dados a chave estrangeira. Cada


cenrio envolve relaes de chave estrangeira entre as vrias mesas, mas para que haja uma
relao de chave estrangeira, a tabela de destino deve ter uma chave primria. E assim antes
mesmo de chegar a funcionrios associados e endereos uns com os outros, temos um
problema. A classe de domnio de endereos no tem um identificador, no entanto, a tabela
que ele seria armazenado no deve ter uma, se para ser parte de quaisquer relaes. Ns
poderamos construir uma chave primria de todas as colunas na tabela de endereos, mas
isso considerado m prtica. Portanto, a coluna ID introduzido, eo mapeamento objeto
relacional tero de se adaptar de alguma forma.
Cenrio (A) da Figura 1-4 mostra o mapeamento ideal dessa relao. O EMP tabela tem uma
chave estrangeira para a tabela de endereo armazenado na coluna ADDRESS_ID. Se a classe
de funcionrios prende em uma instncia da classe Address, o valor da chave primria para o
endereo pode ser definida durante operaes de armazenamento, quando uma linha
funcionrio recebe escrito. E ainda considerar cenrio (B), que apenas ligeiramente
diferente, mas de repente muito mais complexa. No modelo de domnio, uma instncia de
Address no se apegar a instncia Employee que possuiu, e ainda a chave primria
empregado devem ser armazenados na tabela de endereos. O mapeamento objetorelacional deve ou conta para esse descompasso entre a classe de domnio e de mesa ou uma
referncia de volta para o empregado ter de ser adicionado para cada endereo. Para piorar
a situao, o cenrio (C) apresenta uma tabela associativa para relacionar as tabelas EMP e
endereo. Em vez de armazenar as chaves estrangeiras directamente numa das mesas de
domnio, a tabela de juno segura sobre o par de chaves. Cada operao de banco de dados
envolvendo as duas tabelas agora devem percorrer a tabela de juno e mant-lo
consistente. Poderamos introduzir uma classe de associao EmployeeAddress no modelo de
domnio para compensar, mas que derrota a representao lgica que estamos tentando
alcanar. Relaes apresentam um desafio em qualquer soluo de mapeamento objetorelacional. Esta introduo cobre apenas relacionamentos um-para-um , e ainda temos sido
confrontados com a necessidade de chaves primrias no no modelo de objeto e a
possibilidade de ter que introduzir relaes extras para as classes do modelo de associao
ou mesmo para compensar o esquema de banco de dados .

Herana
Um elemento definidor de um modelo de domnio orientada a objeto a oportunidade para
introduzir relaes generalizadas entre as classes. A herana o caminho natural para
expressar essas relaes e permite polimorfismo no aplicativo. Vamos rever a classe
Employee mostrado na Figura 1-1 e imagine uma empresa que precisa de distinguir entre a
trabalhadores de tempo integral e de tempo parcial. Trabalhadores a tempo parcial trabalham
para uma taxa por hora, enquanto os empregados de tempo integral recebem um salrio.

Esta uma boa oportunidade para herana, movendo informao de salrio para as
subclasses PartTimeEmployee e FullTimeEmployee. Figura 1-5 mostra este arranjo.

Herana apresenta um verdadeiro problema para o mapeamento objeto-relacional. No


estamos mais lidando com uma situao em que existe um mapeamento natural a partir de
uma classe para uma tabela. Considere os modelos relacionais mostrado na Figura 1-6. Mais
uma vez, trs estratgias diferentes para persistir o mesmo conjunto de dados so
demonstrados.

Indiscutivelmente a soluo mais fcil para algum mapear uma estrutura de herana para
um banco de dados seria colocar todos os dados necessrios para cada classe (incluindo
classes pai) em tabelas separadas. Esta estratgia demonstrada por cenrio (A) na Figura 16. Note-se que no h nenhuma relao entre as tabelas (ou seja, cada tabela independente
das outras). Isto significa que consultas contra essas tabelas so agora muito mais

complicadas se o usurio precisa para operar em ambos funcionrios de tempo inteiro e de


tempo parcial em um nico step. Uma eficiente, mas desnormalizada alternativa colocar
todos os dados necessrios para cada classe no modelo em uma nica tabela. Isso faz com
que seja muito fcil de consulta, mas observe a estrutura do quadro apresentado no cenrio
(B) da Figura 1-6. Existe uma nova coluna, tipo, que no existe em qualquer parte do modelo
de domnio. A coluna TYPE indica se o empregado a tempo parcial ou a tempo inteiro. Esta
informao deve agora ser interpretado por uma soluo de mapeamento objeto-relacional
para saber que tipo de classe de domnio para criar uma instncia para qualquer linha na
tabela. Cenrio (C) leva isso um passo alm, desta vez normalizar os dados em tabelas
separadas para tempo inteiro ea tempo parcial funcionrios. Ao contrrio do cenrio (A), no
entanto, estas tabelas so relacionadas por uma tabela EMP comum que armazena todos os
dados comuns a ambos os tipos empregados. Pode parecer um exagero para uma nica
coluna de dados extras, mas um esquema real com muitas colunas especficas para cada tipo
de funcionrio provavelmente usaria este tipo de estrutura de tabela. Ele apresenta os dados
de uma forma lgica e tambm simplifica a consulta, permitindo que as tabelas sejam unidas.
Infelizmente, o que funciona bem para o banco de dados no necessariamente funciona bem
para um modelo de objeto mapeado para um tal esquema. Mesmo sem associaes com
outras classes, o mapeamento objeto-relacional da classe de domnio deve agora tomar as
unies entre vrias tabelas em account. Quando voc comear a considerar superclasses
abstratas ou classes pai que no sejam persistentes, herana torna-se rapidamente uma
questo complexa em object- mapeamento relacional. No s existe um desafio com o
armazenamento dos dados de classe, mas as relaes de tabela complexas tambm so
difceis de consultar de forma eficiente.

Suporte Java Persistence para


Desde os primeiros dias da plataforma Java, interfaces de programao j existiam para
fornecer gateways no banco de dados
e abstrair muitos dos requisitos de persistncia especficas de domnio de aplicaes de
negcios. Nos prximos
sees iremos discutir solues atuais e passados de persistncia Java e seu papel na
aplicativos empresariais.

Solues proprietrias
Pode vir como uma surpresa saber que as solues de mapeamento objeto-relacional tem
sido em torno de um longo tempo; mais at do que a prpria linguagem Java. Produtos como
o Oracle TopLink tem seu incio no mundo Smalltalk antes de fazer a mudana para Java. A
grande ironia na histria de solues de persistncia Java que uma das primeiras
implementaes de beans de entidade foi precisamente demonstrado pela adio de uma
camada de bean de entidade adicional sobre TopLink mapeada objetos. Os dois mais
populares APIs de persistncia proprietrios foram TopLink no espao comercial e Hibernate
na comunidade de cdigo aberto. Os produtos comerciais como TopLink estavam disponveis
nos primeiros dias de Java e foram bem sucedidos, mas as tcnicas foram apenas nunca
padronizado para a plataforma Java. Foi mais tarde, quando arrivista solues open source de
mapeamento objeto-relacional, como Hibernate se tornou popular, que as mudanas em torno
de persistncia na plataforma Java surgiu, levando a uma convergncia para mapeamento
objeto-relacional como os solution. Esses dois produtos preferidos e outros poderiam ser
integrado com todos os principais servidores de aplicativos e aplicativos fornecidos com todas
as caractersticas de persistncia que precisavam. Os desenvolvedores de aplicativos foram
ok com o uso de um produto de terceiros para as suas necessidades de persistncia,
especialmente tendo em conta que no existiam normas comuns e equivalentes vista.

Mappers de dados

Uma abordagem parcial para resolver o problema objeto-relacional era usar mapeadores de
dados. O padro de mapeador de dados cai no espao entre plancie JDBC (ver seco "JDBC")
e uma soluo de mapeamento full-objeto-relacional, porque o desenvolvedor do aplicativo
responsvel por criar as cadeias SQL matrias para mapear o objeto para as tabelas de banco
de dados, mas um costume ou off-the-shelf quadro normalmente usado para chamar o SQL
a partir dos mtodos do mapeador de dados. O quadro tambm ajuda com outras coisas,
como o mapeamento conjunto de resultados e parmetros de instruo SQL. O quadro
mapeador de dados mais popular era Apache iBatis (agora chamado MyBatis e hospedada no
Google Code). obtida uma comunidade grandes e ainda encontrada num certo nmero de
aplicaes. A maior vantagem de usar uma estratgia de mapeamento de dados como
MyBatis que o aplicativo tem controle completo sobre o SQL que enviada para o banco de
dados. Procedimentos armazenados e todos os recursos SQL disponveis a partir do driver so
todas justas jogo, ea sobrecarga adicionada pela estrutura menor do que quando se utiliza
um quadro ORM full-blown. No entanto, a grande desvantagem de ser capaz de escrever SQL
personalizada que ela tem de ser mantido. Quaisquer alteraes feitas ao modelo de objeto
pode ter repercusses sobre o modelo de dados e, eventualmente, causar churn SQL
significativa durante o desenvolvimento. Um quadro minimalista tambm abre a porta para o
desenvolvedor para criar novos recursos como os requisitos das aplicaes crescer, acabou
levando a uma reinveno da roda ORM. Mapeadores de dados ainda pode ter um lugar em
algumas aplicaes, se tiver certeza de que suas necessidades no vai crescer alm de
mapeamento simples, ou se eles exigem SQL muito explcito que no pode ser gerada.

JDBC
A segunda verso da plataforma Java, Java Development Kit (JDK) 1.1, lanado em 1997,
inaugurou a primeira grande suporte para a persistncia de banco de dados com JDBC. Foi
criado como uma verso especfica de Java do seu antecessor mais genrico, a especificao
conectividade de banco de dados de objetos (ODBC), um padro para acessar qualquer banco
de dados relacional a partir de qualquer linguagem ou plataforma. Oferecendo uma abstrao
simples e porttil das interfaces de programao proprietrias cliente oferecidos por
fornecedores de banco de dados, JDBC permite que programas em Java para interagir
plenamente com o banco de dados. Essa interao fortemente dependente de SQL,
oferecendo aos desenvolvedores a oportunidade de escrever consultas e instrues de
manipulao de dados no idioma do banco de dados, mas executados e processados usando
uma simples programao Java model. A ironia de JDBC que, embora as interfaces de
programao so portteis , a linguagem SQL no . Apesar das muitas tentativas para
normalizar a ele, ainda raro para escrever SQL de qualquer complexidade que ser
executado inalterado em duas principais plataformas de banco de dados. Mesmo onde os
dialetos SQL so semelhantes, cada banco de dados executa de forma diferente dependendo
da estrutura da consulta, necessitando de ajuste especfico do fornecedor na maioria
cases.There tambm a questo da forte ligao entre a fonte de Java e SQL texto. Os
desenvolvedores esto constantemente tentados pela atrao de consultas SQL prontas para
rodar ambos construdos dinamicamente em tempo de execuo ou simplesmente
armazenados em variveis ou campos. Este um modelo de programao muito atraente at
que um dia voc percebe que a aplicao tem de suportar um novo fornecedor de banco de
dados que no suporta o dialeto de SQL que voc est utilizando. Mesmo com texto SQL
relegado a arquivos de propriedade ou outros metadados do aplicativo, chega um ponto
quando se trabalha com JDBC no s se sente mal, mas tambm se torna simplesmente um
exerccio complicado na tomada de linha de tabela e de dados da coluna e continuamente ter
que convert-lo para trs e em objetos . O aplicativo tem um objeto modelo de porque que
tem que ser to difcil de usar com o banco de dados?

Enterprise JavaBeans
A primeira verso da plataforma J2EE introduziu uma nova soluo para Java persistncia na
forma do beans de entidade, parte do Enterprise JavaBeans (EJB) famlia de componentes.
Destina-se a isolar totalmente os desenvolvedores de lidar diretamente com persistncia,

introduziu uma abordagem baseada em interface onde a classe bean concreta nunca foi
usado diretamente pelo cdigo do cliente. Em vez disso, um compilador de bean
especializada gerou uma implementao da interface de bean para facilitar as coisas tais
como a persistncia, segurana e gerenciamento de transaes, delegando a lgica de
negcios para a implementao de bean de entidade. Beans de entidade foram configurados
usando uma combinao de descritores de implementao padro e XML especfico do
fornecedor, que se tornou notrio por sua complexidade e de verbosity.It provavelmente justo
dizer que os beans de entidade foram mais de engenharia para o problema que eles estavam
tentando resolver, mas ironicamente o primeiro lanamento da tecnologia no tinham muitas
caractersticas necessrias para implementar aplicativos de negcios realistas. As relaes
entre as entidades tiveram que ser gerenciadas pelo aplicativo, exigindo campos de chaves
estrangeiras para ser armazenadas e gerenciadas na classe bean. O mapeamento real do
bean de entidade para o banco de dados foi feita inteiramente usando configuraes
especficas de cada fornecedor, como foi a definio de localizadores (o termo bean de
entidade para consultas). Finalmente, os beans de entidade foram modeladas como objetos
remotos que costumavam RMI e CORBA, introduzindo a sobrecarga da rede e restries que
nunca deveriam ter sido adicionado a um objeto persistente para comear. O bean de
entidade comeou realmente resolvendo o problema persistente componente distribudo,
uma cura para o qual no havia nenhuma doena, deixando para trs o caso comum de
especificao acessado localmente leve persistente objects.O EJB 2.0 resolveu muitos dos
problemas identificados no incio dos lanamentos. A noo de beans de entidade
gerenciados por continer foi introduzido, onde as sessions de beans tornou-se abstrato e o
servidor foi responsvel por gerar uma subclasse para gerenciar os dados persistentes.
Interfaces locais e relacionamentos gerenciados por continer foram introduzidos, permitindo
associaes sero definidos entre beans de entidade e automaticamente mantidos
consistentes por parte do servidor. Esta verso tambm viu a introduo do Enterprise
JavaBeans Query Language (EJB QL), uma linguagem de consulta projetado para trabalhar
com entidades que poderiam ser compilados portably a qualquer dialeto SQL. Apesar das
melhorias introduzidas com EJB 2.0, um grande problema permaneceu: a complexidade
excessiva. A especificao do princpio de que as ferramentas de desenvolvimento isolaria o
desenvolvedor do desafio de configurar e gerenciar os diversos artefatos necessrios para
cada bean. Infelizmente, estas ferramentas levou muito tempo para se materializar, e assim a
carga caiu sobre os ombros dos desenvolvedores, assim como o tamanho e o escopo de
aplicaes EJB aumentado. Os desenvolvedores se sentiu abandonado em um mar de
complexidade sem a infra-estrutura prometida para mant-los tona.

Java Data Objects


Devido em parte a algumas das falhas do modelo de persistncia EJB, e alguma frustrao por
no ter uma API de persistncia padronizado satisfatria, outra especificao persistncia foi
tentada. Java Data Objects (JDO) foi inspirada e apoiada principalmente pelo banco de dados
orientado a objetos (OODB) vendedores e nunca realmente foi adotado pela comunidade de
programao mainstream. necessrio fornecedores para melhorar o bytecode de objetos de
domnio para produzir arquivos de classe que eram binrio compatveis com todos os
fornecedores, e produtos de cada fornecedor compatvel tinha que ser capaz de produzir e
consumir-los. JDO tambm tinha uma linguagem de consulta que foi decididamente orientado
a objetos na natureza, o que no se coaduna com os usurios de banco de dados relacionais,
que estavam em um majority.JDO esmagadora alcanado o status de ser uma extenso do
JDK, mas nunca se tornou uma parte integrante da plataforma Java corporativo. Ele tinha
muitas caractersticas boas e foi adotado por uma pequena comunidade de usurios
dedicados que ficaram por ele e tentou desesperadamente para promov-lo. Infelizmente, os
principais fornecedores comerciais no partilham a mesma viso de como um framework de
persistncia deve ser implementada. Poucos apoiou a especificao, de modo JDO foi falado,
mas raramente usado. Alguns podero argumentar que ele estava frente de seu tempo e
que a sua dependncia de realce bytecode causou a ser injustamente estigmatizada. Esta
provavelmente era verdade, e se tivesse sido introduzido trs anos mais tarde, poderia ter
sido melhor aceite por uma comunidade de desenvolvedores que agora acha nada de usar
estruturas que fazem uso extensivo de aperfeioamento bytecode. Uma vez que o movimento

persistncia EJB 3.0 estava em movimento, no entanto, e os principais fornecedores


assinaram tudo para ser uma parte do novo padro da empresa persistncia, a escrita estava
na parede para JDO. As pessoas logo se queixou a Sun que agora tinha duas especificaes de
persistncia: uma que fazia parte da sua plataforma corporativa e tambm trabalhou em Java
SE, e um que estava sendo padronizado apenas para Java SE. Pouco tempo depois, Sun
anunciou que JDO seria reduzido para modo de manuteno especificao JPA e que gostaria
de chamar de ambos JDO e os fornecedores de persistncia e se tornar o padro suportado
nico daqui para frente.

Why Another Standard?


Por outro padro?
Os desenvolvedores de software sabiam o que queriam, mas muitos no poderia encontr-lo
nas normas existentes, de modo que decidiu procurar em outro lugar. O que eles descobriram
foi uma variedade de frameworks de persistncia de propriedade, tanto comerciais e open
source. Muitos dos produtos que implementaram essas tecnologias adotou um modelo de
persistncia que no intrometer-se os objetos de domnio. Para esses produtos, a persistncia
foi no intrusiva para os objetos de negcios em que, ao contrrio de beans de entidade, que
no tem que estar ciente da tecnologia que foi persistindo eles. Eles no tm de implementar
qualquer tipo de interface ou estender uma classe especial. O desenvolvedor pode
simplesmente tratar o objeto persistente como qualquer outro objeto Java, e, em seguida,
mape-lo para um armazenamento persistente e usar uma API de persistncia de que ele
persista. Como os objetos eram objetos Java regulares, este modelo de persistncia veio a ser
conhecido como Plain Old Java Object (POJO) persistncia. Como Hibernate, TopLink, e outras
APIs de persistncia tornou-se abrigado em aplicaes e atendeu s necessidades da
aplicao perfeitamente bem, a questo foi muitas vezes perguntou: "Por que se preocupar a
atualizao do padro EJB para coincidir com o que estes produtos j fez? Porque no basta
continuar a usar estes produtos como j foi feito por anos, ou por que no at mesmo apenas
padronizar em um produto de fonte aberta como Hibernate? "Na verdade, existem muitas
razes por que isso no poderia ser feito e seria uma m idia mesmo se pudesse. A norma
muito mais profundo do que um produto, e um nico produto (mesmo um produto to bem
sucedido como Hibernate ou TopLink) no pode conter uma especificao, mesmo que ele
pode implementar um. Na sua essncia, a inteno de uma especificao que ele seja
implementado por diferentes fornecedores e que tm produtos diferentes oferecem interfaces
padro e semntica que podem ser assumidas por aplicativos sem acoplar a aplicao de
qualquer produto. Vinculando um padro para um projeto de cdigo aberto como o Hibernate
seria problemtico para o padro e provavelmente ainda pior para o projeto Hibernate.
Imagine uma especificao que foi baseado em uma verso especfica ou do ponto de
verificao da base de cdigo de um projeto open source, e como confusa que seria. Agora
imagine um projeto de software de fonte aberta (OSS) que no poderia mudar ou poderia
mudar apenas em verses discretas controlados por uma comisso especial a cada dois anos,
em oposio s mudanas que esto sendo decididas pelo prprio projeto. Hibernate, e na
verdade qualquer projeto de cdigo aberto, provavelmente seria sufocado. Embora a
normalizao no pode ser valorizado pelo consultor ou a loja de software de cinco pessoas,
para uma corporao enorme. Tecnologias de software so um grande investimento para a
maioria dos departamentos de TI corporativos e de risco deve ser medido quando grandes
somas de dinheiro esto envolvidos. Usando uma tecnologia padro que reduz
substancialmente o risco e permite que a empresa seja capaz de mudar de fornecedor, se a
escolha inicial no atender a necessidade. Alm de portabilidade, o valor de padronizar a
tecnologia se manifesta em todos os tipos de outras reas tambm. Educao, padres de
design, comunicao e indstria so apenas alguns dos muitos benefcios que os padres
trazem para a tabela.

The Java Persistence API

A API Java Persistence um quadro leve, baseado em POJO Java para persistncia. Apesar de
mapeamento objeto-relacional ser um componente importante da API, tambm oferece
solues para os desafios de arquitetura de integrao de persistncia em aplicativos
corporativos escalveis. Nas sees seguintes, vamos olhar para a evoluo da especificao
e fornecer uma viso geral dos principais aspectos desta tecnologia.

History of the Specification


A API Java Persistence notvel no s por aquilo que ele oferece aos desenvolvedores, mas
tambm pela maneira pela qual ele veio a ser. As seguintes sees descrevem a pr-histria
de solues de persistncia objeto-relacional e da gnese da JPA.

EJB 3.0 and JPA 1.0


Depois de anos de queixas sobre a complexidade da construo de aplicaes corporativas com Java,
"facilidade de desenvolvimento" foi o tema para o lanamento do Java EE 5 plataforma. EJB 3.0 liderou
o ataque e encontrou maneiras de tornar Enterprise JavaBeans mais fcil e produtivo para usar. Em
caso de beans de sesso e beans controlados por mensagens, solues para os problemas de
usabilidade foram alcanados por simplesmente removendo alguns dos requisitos de implementao
mais onerosas e componentes de locao parecem mais com objetos Java simples. No caso dos beans
de entidade, no entanto, um problema mais grave existia.
Se a definio de "facilidade de uso" manter interfaces de implementao e descritores fora do
cdigo do aplicativo e de abraar o modelo de objeto natural da linguagem Java, como voc faz de
granulao grossa, interface-driven, beans de entidade gerenciados por continer parecer como um
modelo de domnio?
A resposta foi comear de novo para deixar os beans de entidade sozinho e introduzir um novo modelo
de persistncia. O Java Persistence API nasceu do reconhecimento das demandas de profissionais e as
solues proprietrias existentes que eles estavam usando para resolver seus problemas. Ignorar essa
experincia teria sido loucura. Assim, os principais fornecedores de solues de mapeamento objetorelacional veio para a frente e padronizou as melhores prticas representadas por seus produtos.
Hibernate e TopLink foram os primeiros a assinar com os fornecedores EJB, seguido mais tarde pelos
vendedores JDO. Anos de experincia na indstria, juntamente com a misso de simplificar o
desenvolvimento combinados para produzir a primeira especificao que realmente abraa os novos
modelos de programao oferecidas pela plataforma Java SE 5.
O uso de anotaes, em particular, resultou em uma nova maneira de usar a persistncia em
aplicaes que nunca tinha sido visto antes. A especificao EJB 3.0 resultante, lanado em 2006,
acabou sendo dividido em trs partes distintas e dividido em trs documentos separados. O primeiro
documento continha todo o contedo do modelo de componente EJB legado, e o segundo descreveu o
novo modelo de componente POJO simplificado. O terceiro foi o Java Persistence API, uma especificao
independente que descreveu o modelo de persistncia nos ambientes Java SE e Java EE.

JPA 2.0
No momento em que a primeira verso do JPA foi iniciado, persistncia ORM j tinha vindo a
evoluir para uma dcada. Infelizmente houve apenas um perodo relativamente curto de
tempo disponvel (aproximadamente dois anos) no ciclo de desenvolvimento para criar a
especificao inicial, de modo que nem todos os recursos possveis que tinham sido
encontradas poderiam ser includos na primeira verso. Ainda assim, foram especificados um
nmero impressionante de recursos, com o restante deixado para verses subsequentes e
para os fornecedores para apoiar de forma de propriedade sobre o mesmo perodo.
O prximo lanamento, JPA 2.0, foi no final de 2009 e incluiu uma srie de caractersticas que
no estavam presentes na primeira verso, especificamente aqueles que tinha sido o mais
solicitado pelos usurios. Incluiram novos recursos adicionais de mapeamento, formas

flexveis para determinar a forma como o provedor podeia acessar o estado da entidade, e
extenses para o Java Persistence Query Language (JP QL). Provavelmente, a caracterstica
mais significativa foi a Criteria API Java, uma maneira programtica para criar consultas
dinmicas. Isto permitiu principalmente quadros de usar JPA como um meio para construir
cdigo de programao para acessar os dados.

JPA 2.1
O lanamento do JPA 2.1 em 2013 tornou possvel para quase todos os aplicativos baseados
em APP a ser satisfeitos utilizando as funcionalidades includas na norma sem ter de reverter
para adies de fornecedores. No entanto, no importa como muitas caractersticas so
especificadas, h sempre vai ser aplicaes que necessitam de recursos adicionais para
trabalhar em torno de circunstncias incomuns. A especificao JPA 2.1 adicionou alguns dos
recursos mais exticos, como conversores de mapeamento, o apoio procedimento
armazenado e contextos de persistncia no sincronizadas para melhoria das operaes de
conversao. Ele tambm adicionou a capacidade de criar grficos entidade e pass-las para
consultas, no montante de que comumente conhecido como buscar restries de grupo no
set objeto retornado. Ao longo deste livro que distinguir entre os recursos adicionados no JPA
2.1 daqueles que estavam presentes em JPA 2.0. Isso ajudar os leitores ainda usando um
velho implementao JPA 2.0 para saber o que no est disponvel em seu provedor (e
esperamos incentiv-los a atualizar para um provedor de JPA 2.1).

JPA and You


No final, ainda pode haver alguma caracterstica que voc, ou algum outro usurio JPA, pode
procurar no padro que ainda no foi includo. Se o recurso for solicitada por um nmero
suficiente de usurios, ento ele provavelmente vai eventualmente tornar-se parte do padro,
mas que, em parte, depende de voc, os desenvolvedores. Se voc acha que um recurso
deve ser padronizado, deve falar-se e solicit-lo a partir de seu provedor de JPA; voc tambm
deve entrar em contato com o grupo de peritos da prxima verso APP. A comunidade ajuda a
moldar e conduzir os padres, e voc, a comunidade, que deve fazer suas necessidades
conhecidas.
Note, no entanto, que sempre haver um subconjunto de recursos raramente usados que
provavelmente nunca vai faz-lo no padro, simplesmente porque eles no so mainstream o
suficiente para justificar sua incluso. A filosofia bem conhecido das "necessidades de muitos"
superam as "necessidades de poucos" (nem mesmo fingir que voc no sabe o episdio exato
em que essa filosofia foi expressa em primeiro lugar) deve ser considerado porque cada nova
recurso adiciona uma certa quantidade de complexidade diferente de zero para a
especificao tornando-se que muito maior e muito mais difcil de entender, usar e
implementar. A lio que mesmo que estamos a pedir-lhe para a sua entrada, nem todo ele
pode eventualmente ser incorporada a especificao.

Viso geral
O modelo de JPA simples e elegante, poderoso e flexvel. natural de usar e fcil de
aprender, especialmente se voc tiver usado qualquer um dos produtos de persistncia
existentes no mercado hoje em que a API se baseou. O principal API operacional, que uma
aplicao vai ser exposto a est contido dentro de um pequeno nmero de classes.

POJO Persistence
Talvez o aspecto mais importante da JPA o fato de que os objetos so POJOs, o que significa
que no h nada de especial sobre qualquer objeto que feita persistente. Na verdade, quase
qualquer objeto de aplicao no-final existente com um construtor padro pode ser feita
persistente sem tanto como mudar uma nica linha de cdigo. Mapeamento objeto-relacional

com JPA inteiramente metadados-driven. Isso pode ser feito quer pela incluso de anotaes
para o cdigo ou usando XML definido externamente. Os objetos que so persistentes so
apenas to pesado quanto os dados que so definidos ou mapeado com eles.

Object Queries
Um framework de consulta poderoso oferece a capacidade de consultar entre as entidades e seus relacionamentos
sem ter que usar chaves estrangeiras ou colunas de banco de dados concretos. As consultas podem ser expressos
em JP QL, uma linguagem de consulta que modelado aps o SQL para a sua familiaridade, mas no est vinculado
com o esquema de banco de dados, ou definido utilizando a API de critrios. As consultas usam um esquema de
abstraco que baseada no modelo de entidade, em oposio s colunas em que a entidade armazenada. Java
entidades e seus atributos so usados como o esquema de consulta, de modo que o conhecimento das informaes
do banco de dados de mapeamento no necessria. As consultas acabar por se traduzir pela implementao JPA
para o apropriado SQL para o banco de dados de destino e executado no banco de dados.
A consulta pode ser definido estaticamente em metadados ou criados dinamicamente passando critrios de consulta
ao construir-lo. Tambm possvel escapar para SQL se uma exigncia de consulta especial existe que no podem
ser atendidas pela gerao SQL a partir do framework de persistncia. Estas consultas podem retornar resultados na
forma de entidades, projees de atributos especficos da entidade, ou mesmo valores de funo de agregao,
entre outras opes. Consultas JPA so abstraes valiosos que permitem a consulta atravs do modelo de domnio
Java em vez de atravs de tabelas de banco de concreto.

Mobile Entities
Entidades mveis
Os aplicativos cliente / servidor e Web e outras arquiteturas distribudas so claramente os mais populares tipos de
aplicaes em um mundo conectado. Para reconhecer esse fato significa reconhecer que as entidades persistentes
deve ser mvel na rede. Objetos devem ser capazes de ser movidos de uma Java Virtual Machine (JVM) para outra
e, depois, voltar, e deve ainda ser utilizveis pelo aplicativo.
Objetos que deixam a camada de persistncia so chamados destacado. Uma caracterstica fundamental do modelo
de persistncia a capacidade de mudar entidades separadas e, em seguida, anex-los em cima de seu retorno a
JVM de origem. O modelo de descolamento fornece uma maneira de conciliar o estado de uma entidade que est
sendo recolocado com o estado em que estava antes de se tornar independente. Isto permite mudanas de entidade
a ser feito off-line, mantendo consistncia entidade em face da concorrncia..

Simple Configuration
H um grande nmero de recursos de persistncia que a especificao tem para oferecer e que vamos explicar os
captulos deste livro. Todos os recursos so configurveis atravs do uso de anotaes, XML, ou uma combinao
dos dois. As anotaes oferecem facilidade de utilizao que no tem paralelo na histria de metadados Java. Eles
so convenientes para escrever e indolor para ler, e que tornam possvel para os principiantes obter um aplicativo vai
rapidamente e facilmente.
Mais importante do que os metadados language o facto de a APP faz uso pesado de padres. Isso significa que
no importa qual o mtodo escolhido, a quantidade de metadados que sero necessrios apenas para comear a
correr o mnimo absoluto. Em alguns casos, os padres so suficientemente bons, quase sem metadados ser
exigida em todas.

Integration and Testability


Aplicaes multicamadas hospedados em um servidor de aplicativos tornaram-se o padro de fato para arquiteturas
de aplicativos. Testes em um servidor de aplicativos um desafio que poucos relish. Ele pode trazer dor e sofrimento,
e muitas vezes proibitivo para a prtica de testes unitrios e testes de caixa branca.
Isto resolvido definindo o API para trabalhar fora, bem como no interior do servidor de aplicaes. Embora no seja
to comum um caso de uso, os aplicativos que so executados em dois nveis (o aplicativo falando diretamente para

a camada de banco de dados) pode usar a API de persistncia sem a existncia de um servidor de aplicativos em
tudo. O cenrio mais comum para testes de unidade e de quadros de testes automatizados que podem ser
executados facilmente e convenientemente em ambientes Java SE. Com o Java Persistence API agora possvel
escrever cdigo de persistncia integrada no servidor e ser capaz de reutiliz-lo para testar fora do servidor. Ao
executar dentro de um recipiente de servidores, todos os benefcios de suporte do recipiente e facilidade de uso
superior aplicar, mas com algumas mudanas e um pouco de estrutura de testes de suportar o mesmo aplicativo
tambm pode ser configurado para ser executado fora do recipiente.

Summary
Este captulo apresenta uma introduo ao Java Persistence API. Comeamos com uma introduo ao principal
problema de frente para desenvolvedores tentando usar modelos de domnio de orientao a objetos em conjunto
com um banco de dados relacional: a incompatibilidade de impedncia. Para demonstrar a complexidade de colmatar
a lacuna, foram apresentados trs modelos de objetos pequenos e nove maneiras diferentes para representar a
mesma informao. Ns exploramos cada um pouco e discutimos como objetos de mapeamento para diferentes
configuraes de mesa podem causar diferenas, no s na forma como evolui dados no banco de dados, mas
tambm como caro as operaes de banco de dados resultantes so e como as executa aplicativos. Em seguida,
apresentou um resumo de algumas das solues proprietrias e os padres atuais para persistncia, olhando para
JDBC, EJB e JDO. Em cada caso, ns olhamos a evoluo do padro e onde ele ficou aqum. Voc ganhou algumas
idias gerais sobre aspectos especficos do problema persistncia que foram aprendidas ao longo do caminho.
Conclumos o captulo com uma breve olhada em JPA.
Ns olhamos para a histria da especificao e os fornecedores que se juntaram para cri-lo.
Ns, ento, olhou para o papel que ela desempenha no desenvolvimento de aplicaes corporativas e deu uma
introduo a alguns dos recursos oferecidos pela especificao. No prximo captulo, voc vai molhar os ps com
JPA dando um passeio turbilho de o bsico e construo de uma aplicao simples no processo.