Vamos começar com o que será necessário. Primeiro de tudo meu ambiente é um linux configurado em inglês por isso as telas aqui estão em inglês, então pode ser que precise adaptar os detalhes das telas para o seu ambiente. Aqui eu uso tanto MySQL quanto PostgreSQL, mas nesse tutorial vou assumir que existe um MySQL instalado com um banco de dados criado de nome “curso” com um usuário “javadb” (e a senha você precisa saber qual configurou aí.) Infelizmente a configuração do MySQL não está no nosso escopo, mas qualquer banco de dados relacional serve (só precisa mudar durante a configuração conforme vou mostrar mais a frente.) Finalmente a última definição é usar o Netbeans 6.7, já temos o 6.8 disponível, mas por questões de projeto ainda não migrei nem testei ele, já a versão 6.7.1 tem alguns problemas com detalhes de web e CVS então sugiro ficar com o 6.7 por enquanto, e pode ser encontrado aqui.

Então agora vamos começar!

Primeiro precisamos entender do que estamos falando, isso costuma ajudar muito no desenvolvimento de qualquer coisa na vida. JPA é a sigla para Java Persistence Api, ou seja, uma especificação de persistência para Java. Isso significa que depois de anos de trabalho tentando mapear sistemas orientados a objetos em bancos de dados relacionais aprendemos quais são os problemas recorrentes e as soluções foram sendo catalogadas. O resultado disso ao longo dos anos foi a construção de ferramentas que ofereciam soluções parcialmente automáticas. Com a chegada do EJB3 a Sun mudou os Entity Beans (entidades do sistema) para marcar seus relacionamentos via anotações, e além disso incorporou os mecanismos das diversas ferramentas de persistência. Como implementação de referência a Oracle disponibilizou gratuitamente o TopLink, na época Oracle ainda não tinha comprado a Sun.

É claro que usar uma ferramenta de persistência pode sacrificar um pouco o desempenho da aplicação, mas tenha em mente o seguinte, nem todas as partes do sistema precisam ser extremamente rápidas. Quando alguma das partes do sistema não estiver satisfatória podemos deixar de lado a ferramenta e prover alguma solução construída manualmente. Mas por experiência própria, são poucas as vezes que isso é necessário em sistemas de informação.

Então para fechar a parte teórica e começarmos a meter a mão na massa. A Sun já tinha proposto anteriormente o JDBC que é a especificação que permite que os fornecedores de bancos de dados disponibilizem os drivers para acessar seus produtos, agora com o JPA temos o papel de provedor de persistência, neste caso temos Hibernate, TopLink, EclipseLink e assim por diante. Entre estes eu não usei ainda o eclipse link.

Agora então temos uma nova camada entre a aplicação e o banco de dados tentando tornar a aplicação cada vez mais independente de tecnologias de infraestrutura. Para o nosso exemplo vamos usar o TopLink que já vem com o Netbeans simplesmente porque o Hibernate requer que a aplicação seja gerenciada por um container, se a ideia fosse uma aplicação web isso seria mais fácil, mas vou usar aqui uma aplicação desktop.

Vamos começar então criando um projeto Java no Netbeans. Escolha Java e Aplicação Java como na figura a seguir.

Agora precisamos dar um nome ao projeto, sugiro TutorialJPA, uma coisa que o Netbeans sempre faz é perguntar se você quer criar uma classe main, pode desabilitar essa opção. E vamos escolher finalizar.

Agora que temos um projeto para trabalhar fica tudo um pouco mais fácil. Para entender melhor o que vamos fazer, a ideia e criar uma aplicação que grave as informações de uma classe Livro no banco de dados. Então precisamos de uma entidade Livro, e vou usar os atributos título, autor, isbn e número de páginas. Para isso vamos criar um pacote java de nome “domain” para guardar todas as entidades do nosso pequeno sistema.

E em seguida indique o nome do pacote, domain.

Certo, agora vamos criar a classe de entidade, para isso temos a opção criar nova classe de entidade que já considera que você vai usar as facilidades de JPA.

Agora precisamos escolher o nome da entidade, Livro.

Note que usamos o tipo Long para o id dos objetos, além disso o Netbeans no diz que não tem uma unidade de persitência configurada, agora começa a mágica do negócio. Antes de criar essa unidade de persistência, vamos entender do que se trata, para que a nossa aplicação tenha tantas indepedências precisamos configurar em algum lugar onde está o banco, e que tipo de banco estamos usando. Isso é feito em um xml que fica embutido no projeto, se você quiser mudar alguma coisa do banco, basta mexer nesse xml sem compilar nada! Aqui escolhemos Toplink, damos um nome para referenciar dentro da aplicação e precisamos escolher também qual a conexão com o banco de dados. Além disso podemos escolher o comportamento do JPA, se deve criar; remover e criar, ou não tomar ações em relação as tabelas, sim! O JPA pode criar as tabelas para nós no banco de ddaos!

Uma facilidade que o Netbeans nos oferece é criar a conexão durante este processo, é claro que se você já tiver conexões de banco de dados (até porque o Netbeans permite conectar no banco e executar comandos SQL) você pode simplesmente escolher. É claro que aqui eu vou mostrar como criar.

E agora configurar a conexão, colocando driver, endereço, nome do banco de dados, login e senha, escolhi também para lembrar a senha.

Terminando esse processo voltamos para a tela de criação da unidade de persistência e clicamos em criar.

O resultado é uma tela que nos permite visualizar de forma amigável o conteúdo do arquivo xml.

Agora vamos retomar nossa classe de Entidade, é claro que se fossemos criar várias classes de entidade, apenas na primeira vez seria necessário. Bom podemos ver que a classe Livro foi criada apenas com o atributo id, e vamos colocar agora 4 novos atributos que estão marcados na figura a seguir.

Pela especificação de java beans (já bem antiga) devemos criar os métodos acessores (get/set) para esses atributos, mas calma! O Netbeans ajuda a gente nisso. Para isso vamos clicar com o botão direito do lado de qualquer um dos atributos e aparecerá um menu no qual vamos escolher Refatorar.

Depois disso aparecerá outro menu no qual vamos escolher Encapsular Campos.

Com isso aparecerá uma nova tela na qual vamos escolher quais campos (atributos) queremos encapsular. Vamos escolher os quatro atributos que acabamos de criar.

Agora temos um detalhe, quando a classe foi criada o Netbeans gerou para a gente automanticamente dois métodos importantes o equals e o hashCode, esses métodos são fundamentais para conseguir comparar corretamente dois objetos, só que como criamos atributos novos precisamos recriar esses métodos, e novamente vamos ter uma ajuda. Podemos remover os métodos gerados.

Agora podemos recriar os métodos clicando novamente com o botão direito na tela, dentro da classe e escolhendo inserir código.

E uma nova janela aparece onde escolhemos equals e hashCode.

Agora, surgirá uma nova tela onde podemos escolher os atributos que serão usados para comparar dois objetos.

Antes de continuar, vamos dar uma pausa para uma outra configuração, precisamos importar para o nosso projeto a biblioteca do MySQL, como esse passo é bem simples é um bom momento para descansar a cabeça Então agora vamos clicar com o botão direito sobre o projeto e vamos escolher propriedades.

Isso nos abre uma outra tela na qual vamos escolher a opção bibliotecas. E agora vamos escolher adicionar bibliotecas.

Com isso vai aparecer a opção para escolhermos quais as bibliotecas queremos adicionar, neste caso a do MySQL.

Fim dos comerciais, agora podemos voltar ao nosso projeto. Vamos agora criar um pacote java chamado app onde ficará nossa classe de “aplicação” que vai representar o que seria uma interface gráfica por exemplo. Isso já está explicado aí em cima né ? Então vamos seguir para criar uma classe Java tradicional.

E basta agora dar o nome de Aplicacao e colocar a classe no pacote app. Vamos deixar essa classe em banho-maria por enquanto. Vamos seguir agora para uma outra parte mágica do JPA, o Netbeans permite criar um tipo de classe chamado JPAController, aplicando o padrão de projetos Controller, ele permite fazer a ponte entre a classe de entidade e o banco de dados efetivamente. Quando criada, está classe já vem com as operações básicas, e que muitas vezes são suficientes para alguns cadastros. Algumas vezes o tipo de recurso que queremos criar não está disponível no menu, basta ir até “outros”.

E em seguida escolher em persistência, JPAController.

Agora uma nova tela surgirá para que escolhamos para qual Entidade vamos criar o JPAController, sim, para cada entidade teremos um controller diferente.

Em nosso projeto só existe uma entidade, e portanto fica fácil de escolher, basta clicar na classe domain.Livro e clicar em adicionar, depois vamos para a próxima tela onde vamos escolher em que pacote as classes vão ser criadas.

Neste momento estamos com toda a infraestrutura do nosso projeto criada e podemos retomar a nossa classe de aplicação que vai utilizar todos esses mecanismos. Para conferir a estrutura e as classes criadas segue a próxima figura.

Agora retomando nossa classe de aplicação, o que queremos fazer com um banco de dados ? Persistir os dados de nossa aplicação! Então precisamos criar objetos, preencher os valores, criar uma instância de JPAController e chamar os métodos para realizar as ações desejadas. Nesta figura temos todos os usos das chamadas, criar, buscar, editar e remover. Esse código precisa ser colocado no método main da nossa classe Aplicacao.

É isso, é claro que até aqui só temos o suficiente para criar um pequeno projeto, mas podemos ampliar os estudos com alguns livros importantes, mais para frente vou colocar aqui umas resenhas de livros importantes para esse tópico.

Atualmente contamos com mecanismos mais adequados para esse tipo de representação, as linguagens estruturadas oferecem uma forma de compor novos tipos, criados pelo usuário, utilizando os tipos primitivos e/ou outros tipos do usuário. Na linguagem C esse mecanismo é o struct, que cria uma “estrutura” composta de outras variáveis, assim podemos criar um struct categoria composta de um inteiro código e um vetor de caracteres nome. Chamamos esses novos tipos definidos pelo usuário de Tipos Abstratos de Dados porque estão relacionados a conceitos mais abstratos do que os conceitos primitivos oferecidos pela própria linguagem de programação. Nas linguagens orientadas a objetos utilizamos classes para representar os conceitos que modelamos para o sistema então as classes são as definições dos Tipos Abstratos de Dados.

A relação com o conceito de “tipo” está no fato de que a partir da definição criada pelo usuário podemos declarar variáveis que representarão durante o processamento os dados que queremos associar com as representações que damos a modelagem do sistema.

No entanto existem diferenças importantes entre a forma de trabalhar com as linguagens estruturadas e as orientadas a objetos. Na orientação a objetos além de estruturar as variáveis que compõe o conceito (do mundo real) podemos incluir métodos para tratar essas variáveis e/ou para expor outros “comportamentos,” assim quando usamos um objeto (instância da classe em tempo de execução) ele pode executar certas funcionalidades ou serviços de acordo com as responsabilidades que se referem ao conceito no mundo real. Apenas para exemplificar, uma classe LancamentoMensal, não deveria ter um método “imprimir” porque não faz parte das responsabilidades associadas a esse conceito. Por outro lado esta classe poderia ter um método “calcularTotal.”

Bom, existem várias respostas para essa pergunta, mas com certeza a mais interessante é a que diz respeito a demanda do usuário. Não vou falar sobre como surge a demanda do usuário por sistemas propriamente, mas é entender que em algum momento o usuário percebe um interesse por um sistema. Até aí tudo bem, o “problema” começa na verdade quando o usuário começa a aumentar a lista de necessidades, porque do ponto de vista puramente abstrato (característica do software) tudo é possível fazer, porém quando tentamos “concretizar” a necessidade do usuário em software essa tarefa em alguns casos se torna mais difícil do que deveria ser. Isso acontece porque quando vamos ampliando os horizontes dos sistemas vamos chegando aos limites que as nossas técnicas comportam. Um dos limites mais importantes é o de gerenciar abstrações de mais alto nível, ou seja, quando chegamos nas fronteiras do desenvolvimento de sistemas não conseguimos mais gerenciar adequadamente as abstrações necessárias para desenvolver os sistemas que atendem as novas demandas dos usuários.

Isso acontece e fica claro quando pensamos na programação estruturada de forma comparada com a programação orientada a objetos. Essas duas formas de visão (ou paradigmas) não são contrárias entre si, apenas fornecem métodos de modelagem diferentes. Costumo dizer que a mudança está no foco, enquanto a programação estruturada trabalha com o foco nas funções do sistema, a programação orientada a objetos tem o foco nos dados, ou mais precisamente nos tipos abstratos de dados e isso é uma diferença fundamental.

O impacto dessa mudança de foco está no fato de que fica mais fácil de se comunicar com o usuário uma vez que estaremos trabalhando com as entidades ou conceitos que são usados diariamente, sejam eles Produto, Compra, OrdemDeVenda, ItemDePedido, Fornecedor entre outras. Com isso gastamos (ou deveríamos gastar) mais tempo com a análise, projetando um sistema mais coerente com as abstrações do próprio usuário e torna-se (ou deveria se tornar) possível construir sistemas maiores, com uma complexidade menor. Na prática surge uma dificuldade diferente que é conseguir lidar com um nível maior de abstração, mas isso se deve muito mais a falta de prática (e/ou vontade de realmente aprender a técnica) do que a mudança de foco em si.

Uma outra característica importante e interessante é o fato de que a programação orientada a objetos contém a programação estruturada, ao contrário do que as pessoas pensam que teram que simplesmente jogar tudo fora e aprender novamente. O ponto é que agora não dá para ir só aglutinando funções, o que gera as dependências, é necessário pensar onde as coisas entram, de quem é a responsabilidade por executar um certo código. Os métodos (o equivalente as funções) precisam fazer parte de uma classe, então não acontece (ou não deveria acontecer) de termos uma classe Recibo com um método imprime porque o Recibo não deveria mesmo conhecer o sistema de impressão, ao invés disso, essa classe fica responsável por aglutinar os dados de um Recibo de forma que seja mais claro e simples carregar essa informação. Por outro lado a classe ServicoDeImpressao pode ter acesso a classe ModeloDeImpressao para preencher com os dados e executar a impressão propriamente dita. O que conseguimos com isso é ter uma separação clara entre classes de dados e classes de controle, além disso, como efeito colateral, temos uma organização do sistema que nos permite achar de forma mais simples e ágil onde estão os códigos que realizam cada tarefa.

É claro que junto com um novo paradigma vem um conjunto de novas formas de pensar o sistema, então torna-se necessário aprender a fazer a análise de forma adequada para poder fornecer para o programador todas as informações necessárias à construção do sistema. Enquanto na programação estruturada quase sempre partíamos diretamente para a codificação, na programação orientada a objetos é muito difícil que essa abordagem funcione de forma satisfatória porque é necessário pensar onde as coisas vão se encaixar.

“Ah, mas se eu colocar em qualquer lugar e fizer a chamada não vai funcionar?” Bem, a resposta é sim, vai funcionar, só que não teremos nenhum benefício de usar a orientação a objetos se não fizermos as coisas como devem ser feitas. Muitas vezes vemos nas empresas sistemas feitos em Java, C++ e C# que, embora usem linguagens orientadas a objetos, são programados de forma estruturada. “Mas isso é possível?” Sim, o fato de usar uma linguagem orientada a objetos não quer dizer que o seu sistema esteja orientado a objetos, de fato é possível até mesmo construir um sistema orientado a objetos com uma linguagem estruturada como C (só que isso é muito mais difícil.)

Isso nos leva a entender que os paradigmas estruturado e orietado a objetso são apenas formas de trabalhar, o uso de uma linguagem que dá suporte a um ou outro não nos obriga a usá-lo. No entanto se estamos escolhendo trabalhar com uma linguagem que suporta o paradigma orientado a objetos (salvo situaçõe puramente de modismo) é porque estamos interessados nos benefícios que esse paradigma pode nos oferecer, quando não gastamos o tempo necessário para aplicar as técnicas estamos jogando fora uma possibilidade de escrever sistemas mais claros e com maior durabilidade (considerando que o usuário tenha interesse no sistema durante um longo período.) Essencialmente, um sistema deveria durar o tempo suficiente para que o usuário perca o interesse ou a necessidade nos serviços prestados no sistema de forma que ele seja substitído. Enquanto o usuário não precisar de um sistema novo, deveria ser possível aplicar evoluções no sistema em uso, muitas vezes isso não é possível porque devido ao uso incorreto das ferramentas o sistema tem tantas dependências entre módulos que quebra. Nesse tipo de situação o usuário ainda tem interesse no mesmo serviço, mas é obrigado a trocar o sistema  por não ser possível mais evoluir e adaptar as dinâmicas diárias.