Framework para mapeamento objeto-relacional

Apresentação em tema: "Framework para mapeamento objeto-relacional"— Transcrição da apresentação:

1 Framework para mapeamento objeto-relacional
Universidade Federal de Santa Catarina - CTC Bacharelado em Sistemas de Informação INE56 Framework para mapeamento objeto-relacional Carlos Alberto Machado Costa ( ) Jéssica Scheneider Schmidt ( ) Robson Rodrigues dos Santos ( ) 1 1

2 Visão Geral O Hibernate é um framework de mapeamento
objeto-relacional para a linguagem Java Conjunto de classes, interfaces e configuração que permite simplificar o trabalho de persistir e recuperar objetos Java em banco de dados relacionais. Visão geral O Hibernate ( é um framework para mapeamento objeto-relacional para a linguagem Java. Na prática, ele é um conjunto de classes, interfaces e arquivos de configuração pré-acabados que permitem a criação de uma camada de serviço capaz de abstrair a existência do banco de dados para sistemas Java. Funcionamento básico Seu processo de funcionamento é simples: Na aplicação Java existe um conjunto de objetos (instâncias de classes Java) que devem ser persistidos em um meio durável, no caso o banco de dados. O banco de dados nesse caso segue o modelo relacional (tabelas + relacionamentos) e por esse motivo diz-se que existe uma impedância entre essas camadas (objetos, propriedades e associações na aplicação; tabelas, colunas e relacionamentos no banco de dados). O Hibernate atua entre essas camadas, provendo funcionalidades para salvamento e recuperação dos objetos Java no banco de dados. Para a aplicação Java persistir esses objetos, ela invoca métodos da API do Hibernate. O Hibernate mapeia esses comandos para os respectivos comandos SQL do banco de dados. Esses comandos são executados sobre uma conexão JDBC normal previamente configurada no Hibernate. Para recuperação dos objetos, a aplicação cliente invoca métodos da API do Hibernate que também são traduzidos em comandos SQL do banco de dados, mas agora para seleção de registros. Utilizando essa abordagem, além de permitir isolamento da aplicação em relação ao banco de dados, o Hibernate habilita a independência de banco de dados, uma vez que a aplicação cliente não possui comandos SQL dentro de seu código. Importante ainda é o fato que todos os comandos SQL gerados pelo Hibernate são nativos do banco de dados corrente. 2 2

3 Histórico Concepção no final de 2001;
Projeto pessoal, de Garvin King, insatisfeito com o modelo CMP de persistência do J2EE 1.3; Versão corrente do Hibernate (3.2.1) (dez/2006) - bastante estável, escalável, customizável e aderente às necessidades de desenvolvedodres . Histórico O projeto Hibernate é de autoria de Gavin King, um desenvolvedor Java que estava insatisfeito com o modelo CMP de persistência do J2EE 1.3. Descontente com o paradigma da época, propos-se a desenvolver um framework próprio, que condizia com as necessidades suas e de seus amigos. Por incrível que pareca, ele apostou com seu chefe (gerente de projeto) que conseguiria fazer algo melhor que o CMP do J2EE. Isso foi o começo, lá pelos idos do ano 2001 na Austrália. Evolução Ao longo dos anos e dos constantes releases da ferramenta no repositório sourceforge ( várias funcionalidades foram sendo adicionadas e desenvolvedores associando-se ao projeto. De importante impacto foi a versão 3.0 da ferramenta, onde a revisão do padrão CMP do J2EE estava em desenvolvimento. Nesse momento, as idéias do framework Hibernate já estavam bem alicerçadas e difundidas pelo planeta. Nesse sentido, o sr. King fora incluído como membro do JCP da Sun (e parceiros) como um engenheiro especialista e praticamente definiu as bases no novo modelo CMP do Java EE 1.5 (JSR 244). O Hibernate que não fora baseado em nenhum padrão acabara de criar um: o Java Persistence API (parte da JSR 220 ou EJB3). Atualmente (dez/2006), a versão corrente do Hibernate (3.2.1) é bastante estável, escalável, customizável e aderente às necessidades de desenvolvedodres cliente/servidor e N camadas. 3 3

4 Características gerais
Abordagem totalmente OO; Suporte à mais de 20 SGBD; Gera comandos SQL nativos para cada SGBD; Suporte total ao Java; Opera em ambientes standalone e sob containers. Características O Hibernate objetiva dar ao desenvolvedor a possibilidade de trabalhar de forma totalmente orientada a objetos – não pensa-se mais em linhas, colunas e tabelas, mas sim em objetos, associações e coleções. Tendo engines específicas de geração de comandos SQL, o Hibernate conta atualmente com o suporte à mais de 20 banco de dados – em outras palavras, ele pode ser usado em cada um desses SGBDs executando comandos SQL nativos. Não obstante, como a aplicação cliente opera sobre sua API, a troca de um SGBD por outro não afeta a camada cliente do sistema (não é necessário reescrever o código do sistema) Na versão 3, o Hibernate adequou-se à sintaxe 1.5 do Java, suportando enumerações, coleções tipadas, anotações e outros recursos avançados dessa linguagem. Quanto ao funcionamento, o serviço do Hibernate pode operar de forma standalone (o Hibernate roda dentro da aplicação cliente) ou gerenciada (o Hibernate roda dentro de containers Java EE, como o JBoss). Detalhes sobre isso, a seguir. 4 4

5 Características gerais
Alta Performance; 2 Níveis de Cache; SQL Nativo Comandos pré-compilados Queries nativas com mapeamento automático; Suporte à transações; Standalone, demarcadas explicitamente Gerenciada por container (XA-Transactions), implícitas; Performance Objetivando escalabilidade, o Hibernate possui um eficiente sistema de cache de 2 níveis (ambos em memória RAM). Seus comandos SQL nativos podem ser gerados tanto em tempo de execução (durante a chamada do cliente) quanto em tempo de deployment (o padrão) e são compilados no BD através de chamadas preparadas no driver JDBC. Importante salientar que, embora o Hibernate ofereça uma API de busca e persistência de objetos e uma linguagem própria de consultas (a HQL, discutida a seguir), ele também permite a execução de comandos SQL nativos diretamente pelo desenvolvedor. Mesmo esses comandos SQL nativos podem contar com os recursos de materialização automáticos, ou seja, as colunas retornadas pelo comando SQL podem ser mapeadas diretamente e automaticamente para as propriedades dos objetos da aplicação. Tudo isso é configurável Transações O Hibernate exige que qualquer comando de alteração de objetos (insert, update, delete) seja encapsulado em uma transação. Quando ele é usado na forma Standalone (em aplicações cliente-servidor, por exemplo), é tarefa do programador demarcar o início e o fim das transações (como apresentado anteriormente). Já em ambientes gerenciados (dentro de servidores de aplicação), o Hibernate pode delegar a demarcação das transações para o próprio container. Isso é possível graças a sua aderência ao padrão JTA (Java Transaction API). Quando isso é feito, o código que usa o Hibernate não precisa abrir o fechar transações, ele simplesmente invoca os métodos de persistência. O container detecta as operações em execução e automaticamente encapsula-as em transações XA (*). Por outro lado, caso o desenvolvedor não queira utilizar o padrão JTA dentro de um container, ele pode informar isso via configuração e continuar demarcando suas transações explicitamente. Nota-se que isso não é recomendado, devido a complexidade que pode estar envolvida (ambientes complexos, cluster de servidores, fail over, múltiplos databases, etc.) (*) Transações XA são um padrão de transações do JTA que permitem funcionalidades como clusterização e replicação em ambientes complexos. Nota-se que essas transações exigem recursos diversos do container (cache, segurança, replicação, etc.) e, principalmente o suporte dos drivers JDBC. Muitos drivers JDBC não suportam esse tipo de operação e, nesse caso, as transações XA são substituídas por transações mais simples. 5 5

6 Características gerais
Linguagem própria de consulta; HQL - Semelhante ao SQL - Orientada a Objeto - Muitas funcionalidades embutidas Configuração flexível; XML Texto puro (arquivo .properties) HQL Uma funcionalidade importante oferecida pelo Hibernate é a linguagem HQL (Hibernate Query Language) que suporta recuperação de objetos via uma sintaxe muito semelhante ao SQL, sendo, porém, orientada a objetos. Configuração A configuração do Hibernate é dada por arquivos XML (que definem o comportamento do serviço e os aspectos relativos ao mapeamento objeto-relacional) e por arquivos texto, que definem aspectos do serviço. Os arquivos texto podem ser suprimidos quando todas as informações necessárias estão contidas nos arquivos XML. Entretanto, o uso do arquivo texto é mais simples e menos prolixo, sendo suportado em qualquer situação. Dentro do pacote de instalação do Hibernate existe um arquivo texto de modelo que pode ser utilizado para os casos mais tradicionais de configuração. Os arquivos XML são um pouco mais complexos e sensíveis ao contexto de uso (standalone ou gerenciado) e por isso é necessário uma leitura da documentação do framerwork para maiores detalhes. 6 6

7 Características gerais
Ferramentas e utilitários disponíveis; Utilitários - Geração/atualização da BD - Validação da BD Plugins para IDEs - Operação visual - Engenharia reversa (geração das classes Java a partir da BD) Software livre; Grande comunidade; Apoiado pela JBoss (RedHad); Ferramentas O pacote do Hibernate representa o kernel de mapeamento, mas também possui alguns utilitários inclusos, tanto para a geração automática da base de dados, como para sua atualização e validação. Ferramentas e plugins para IDEs estão disponíveis através de outros downloads do site do projeto, as quais permitem operação visual e engenharia reversa. Outras características O Hibernate é um projeto Open Source, mantido por desenvolvedores diversos ao redor do mundo. Apoiado pela JBoss, que recentemente foi adquirida pela Red Hat, é uma solução robusta e que possui suporte dessa empresa, caso o cliente necessite (nesse caso, o suporte é pago). Treinamentos e cursos (com certificação) estão disponíveis na JBoss e também em empresas diversas em vários países. Também tutorais, fóruns, listas de discussão e amplo material de pesquisa e exemplos de sucesso estão espalhados pela Internet. 7 7

8 Modos de operação São dois os modos de operação do Hibernate;
Standalone Comum para sistemas 2 camadas (desktop ou web). Nele, o Hibernate controla todo o escopo de operação, e a aplicação cliente tem domínio completo da execução do sistema Gerenciado Comum para sistemas n camadas. Nele, o Hibernate é configurado como um serviço no Servidor de Aplicação, e a aplicação cliente solicita serviços do framework Modos de operação Aqui, são mostrados o uso standalone e gerenciado do Hibernate. Standalone No modo Standalone, o cliente invoca diretamente métodos da API do Hibernate, que então encarrega-se de acessar o BD. Transações são marcadas explicitamente pelo usuário. Aqui, o código cliente depende da API do Hibernate. Gerenciado No modo Gerencaido, o cliente invoca (ou pelo menos é o recomendado invocar) métodos da API de persistência do Java (JSR220), que está disponível no container Java EE. Esses métodos são delegados ao Hibernate que faz o acesso ao banco de dados (*). Essa configuração permite que o container Java EE substitua o Hibernate por outro framework de mapeamento e o cliente continue operando sem maiores complicações (ou seja, sem reescrita de código). (*) Na verdade, o que acontece é que o padrão Java Persistence (JSR220) é uma fachada de classes e interfaces, mas sem uma implementação de fato. O Hibernate implementa essa fachada. Assim, o cliente invoca métodos da fachada Java Persistence e é por isso que ele tem independência de framework de mapeamento. Substituir o Hibernate por outro framework é uma tarefa mais simples com essa abordagem. 8 8

9 Modos de operação Todas as operações executadas no Hibernate são
encapsuladas por transações; Standalone, transações demarcadas pelo usuário No container, podem ser automatizadas via JTA pelo Servidor de Aplicação Transações Como dito, todas operações executadas pelo Hibernate são encapsuladas por transações. Na figura à esquerda, o modo Standalone evidencia que é o código do usuário o responsável por demarcar o início e o fim de uma transação. Ao centro, a figura mostra um típico código de persistência em um ambiente gerenciado (dentro de um container Java EE). Nota-se que não existe código de usuário para demarcar a transação. Essa tarefa é realizada automaticamente pelo container Java EE. À direita, a representação gráfica de uma chamada de um cliente para execução de uma transação. O EJB1 é um EJB de fachada que executa uma série de operações sobre outros EJBs que acessam várias vezes o Hibernate (executando possivelmente comandos de persistência e recuperação de objetos). Quando o método principal do EJB de fachada retornar o container detecta que a transação de negócio terminou e então ele confirma a transação do Hibernate. Tudo isso é automático e transparente. Obviamente, o programador pode decidir não usar transações gerenciadas dentro do container, mas isso é uma prática não recomendada. IMPORTANTE salientar que transações não podem ser aninhadas. 9 9

10 Modos de operação Exemplo Simples do uso do Hibernate 10 10
Persistência Seja um objeto do tipo NotaFiscal. Deseja-se persistir esse objeto Java em uma base de dados relacional. Na aplicação cliente, o código é como da listagem superior. É instanciado um objeto NotaFiscal e suas propriedades são definidas através dos métodos setters. Através de chamadas da API do Hibernate, a fábrica de sessões de trabalho disponibiliza uma sessão para a aplicação cliente. Essa sessão é usada para persistir o objeto NotaFiscal através do método save(). Nota-se que a chamada ao método save() está encapsulada dentro de uma transação do Hibernate. Isso é um requisito importante e obrigatório. Agora, suponha-se o caso que o objeto NotaFiscal possuísse ligações com diversos outros objetos, como Cliente, Item de nota, Produto, etc. Qual seria o impacto no código da aplicação para persistir todo esse grafo de objetos? A resposta é nenhum. O Hibernate pode encarregar-se de executar a persitência de todos esses objetos relacionados (obviamente isso vai depender do tipo de configuração aplicada sobre cada um desses objetos dependentes). Recuperação Finalmente, para recuperação do objeto salvo (na mesma ou em outra sessão de trabalho do usuário), o código também é simples. Obtida uma sessão de trabalho do Hibernate, basta invocar o método load(), passando como parâmetros o tipo da classe e o identificador (chave primária, por assim dizer) do objeto. O retorno, após uma simples conversão é atribuído ao objeto NotaFiscal. Também aqui, as dependências de objetos (Cliente, Endereço, etc.) poderiam ser carregadas junto automaticamente, dependendendo do tipo de configuração adotada. Transações gerenciadas Importante é o fato que o encapsulamento de comandos (como o save() ) sob transações pode ser executado de forma transparente. Isso é possível quando o Hibernate é executado como serviço dentro de ambientes gerenciados em servidores de aplicação Java EE, como o JBoss. Isso será visto depois. 10 10

11 Exemplo prático ... 11 11 Persistência
Seja um objeto do tipo NotaFiscal. Deseja-se persistir esse objeto Java em uma base de dados relacional. Na aplicação cliente, o código é como da listagem superior. É instanciado um objeto NotaFiscal e suas propriedades são definidas através dos métodos setters. Através de chamadas da API do Hibernate, a fábrica de sessões de trabalho disponibiliza uma sessão para a aplicação cliente. Essa sessão é usada para persistir o objeto NotaFiscal através do método save(). Nota-se que a chamada ao método save() está encapsulada dentro de uma transação do Hibernate. Isso é um requisito importante e obrigatório. Agora, suponha-se o caso que o objeto NotaFiscal possuísse ligações com diversos outros objetos, como Cliente, Item de nota, Produto, etc. Qual seria o impacto no código da aplicação para persistir todo esse grafo de objetos? A resposta é nenhum. O Hibernate pode encarregar-se de executar a persitência de todos esses objetos relacionados (obviamente isso vai depender do tipo de configuração aplicada sobre cada um desses objetos dependentes). Recuperação Finalmente, para recuperação do objeto salvo (na mesma ou em outra sessão de trabalho do usuário), o código também é simples. Obtida uma sessão de trabalho do Hibernate, basta invocar o método load(), passando como parâmetros o tipo da classe e o identificador (chave primária, por assim dizer) do objeto. O retorno, após uma simples conversão é atribuído ao objeto NotaFiscal. Também aqui, as dependências de objetos (Cliente, Endereço, etc.) poderiam ser carregadas junto automaticamente, dependendendo do tipo de configuração adotada. Transações gerenciadas Importante é o fato que o encapsulamento de comandos (como o save() ) sob transações pode ser executado de forma transparente. Isso é possível quando o Hibernate é executado como serviço dentro de ambientes gerenciados em servidores de aplicação Java EE, como o JBoss. Isso será visto depois. 11 11

12 Bibliografia Hibernate - Uma visão geral sobre o framework padrão
de fatopara mapeamento objeto-relacional AUTOR: Marcelo Mrack, Porto Alegre, RS – Brasil Open Solaris - Disk Chocolate - 12 12