Aula 4. Carlos Eduardo de Carvalho Dantas

(1)

10/09/2011 Persistência com JDBC e JPA

Persistência com JDBC e JPA

Aula 4

Carlos Eduardo de Carvalho Dantas

(

[email protected]

)

“A sabedoria não se transmite, é preciso que nós a descubramos fazendo uma caminhada que ninguém pode fazer em nosso lugar e que ninguém nos pode evitar, porque a sabedoria é uma maneira de ver as coisas.”. Marcel Proust

(2)

 Apresentação mudanças;

 Hibernate/Jpa – estados dos objetos;

 Hibernate/Jpa - conceitos;

 Hibernate/Jpa – mapeamentos

(3)

 DB = Database ou Banco de dados;

 DAO = Data Acess Object;

 JPA = Java Persistence API;

 ORM = object-relational mapping ou mapeamento

objeto-relacional;

 Java EE = Java Enterprise Edition

(4)

 Projetos pequenos sobreum projeto-base;

 Projeto-base é o mínimo necessário

para rodar Hiberna/Jpa;

(5)

Script ant para:

 Carregar o servidor do banco HSQLDB;

 Carregar o client do banco HSQLDB;

 Exportar estado dos POJOs para o

banco (top-down);

 Exportar estado do banco para os

Pojos (bottom-up)

Obs: qualquer operação acima será realizada com 1 clique

(6)

 Além do básico, possui apenas um pool de conexões

C3P0

 Pools com o Hibernate basta a configuração abaixo

no persistence.xml

 … e o jar referente ao pool no classpath

c3p0-0.9.1.2.jar

(7)

10/09/2011 Persistência com JDBC e JPA  Transientes;  Persistentes;  Removidos;  Desligados

(8)

 Transientes (qualquer modificação em uma instância

transiente não é sabida pelo Hibernate);

 Persistentes (sempre estão associadas a um

contexto de persistência. Estão sob um cache no Hibernate, que pode detectar alterações);

 Removidos (não devem ser usados pois ainda são

gerenciados pelo contexto de persistência,

consequentemente deletados quando a unidade de trabalho terminar);

 Desligados (o estado não está mais sincronizado

com o estado do banco). Podem voltar a ser persistentes com fundição (merge)

(9)

 EntityManager → fila de declarações SQL que

precisam ser sincronizadas com o banco em algum ponto (assíncrono);

 EntityTransaction → define os limites da transação.

Pode ser programado ou não (JTA? RESOURCE_LOCAL?);

 Dialeto → classe que informa quais variações SQL

ele deve gerar para conexão com o banco;

 EntityManagerFactory – deve ser instanciada uma

única vez na aplicação (ThreadSafe)

(10)

 Mapeamentos como @Table, @Column e

@JoinColumn são opcionais;

 XML possui precedência sobre anotações;

 Pode ser necessário o uso de recursos específicos

do motor ORM ex: EntityManager em; HibernateEntityManager hib = (HibernateEntityManager)em; Session s = hib.getSession();

Conceitos

(11)

 Exemplos de metadados do fornecedor que não

existem na JPA:

@org.hibernate.annotations.BatchSize @org.hibernate.annotations.Formula

 Jpa está automaticamente em um contexto Java EE;

 Modelos de domínio não devem consultar o banco

(persistência transparente);

 Anotações devem ser colocadas nos campos ou nos

métodos de acesso?;

 Granulosidade fina → mais classes que tabelas;

(12)

 Objetos podem ser de tipos entidade ou valor

 Entidade → Possuem uma identidade com o banco;

 Valor → Depende de uma entidade para possuir

identidade com o banco;

 Igualdade

== → mesmo local de memória; equals() → equivalência;

@Id → identificador do banco de dados;

 Atributos @Transient – são ignorados pelo contexto

de persistência

(13)

 Suportado pela JPA

 AUTO

 SEQUENCE

 IDENTITY

 TABLE

 Definir sequence do Banco

@GeneratedValue(strategy=GenerationType.SEQUENC E, generator="generator")

@SequenceGenerator(name="generator", sequenceName="seqAcao")

(14)

 Chaves compostas

 Projeto ClassesEmbutidas classes ItemPedido.java e

TesteItemPedido.java

(15)

 Projeto ClassesEmbutidas classes Validade.java,

Acao.java, Desconto.java e TesteAcao

(16)

 Projeto Mapeamentos (classe Acao e TesteAcao);

 Mapeamento de data/hora;

(17)

 Projeto Mapeamentos (classe Anexo e TesteAnexo);

 Mapeamento para binário e valor grande;

(18)

 Projeto Mapeamentos;

 Mapeamento de enums (classes Cliente e

TesteCliente);

 Mapeamento de fórmulas (classes ItemPedido e

Pedido)

(19)

 Objeto de tipo de valor não possui identidade no

banco;

 Devemos escolher a interface e implementação que

melhor se encaixe no modelo de domínio

Private <<Interface>> imagens = new <<Implementacao>>();

 Obs: inicialize a coleção de imediato, conforme

mostrado acima

Mapeamento coleções do tipo

valor

(20)

 java.util.Set → java.util.HashSet – ordem não é

preservada e a duplicação não é permitida;

 java.util.SortedSet → java.util.TreeSet – atributo sort

pode ser definido por um comparator ou por ordenação natural;

 java.util.List → java.util.ArrayList – preserva a

posição de cada elemento com uma coluna do índice na tabela;

 java.util.Collection → java.util.ArrayList – trabalha

com o conceito de Bag (sacola), onde a ordem dos elementos não é preservada e pode ter duplicações

Mapeamento coleções do tipo

valor

(21)

 java.util.Map → java.util.HashMap – preserva pares

de chave-valor;

 java.util.SortedMap → java.util.TreeMap - atributo sort

pode ser definido por um comparator ou por ordenação natural;

 Arrays primitivos. Ex: String[] - são suportados, mas

raramente utilizados, pois, com eles, não existe

mais lazy loading e checagem de sujeira otimizada.

Mapeamento coleções do tipo

valor

(22)

 Projeto – MapeamentoColecoesValor

 Set – ProdutoSet.java e TesteProdutoSet.java

 List – ProdutoList.java e TesteProdutoList.java

 Map – ProdutoMap.java e TesteProdutoMap.java

 SortedSet – ProdutoSortedSet.java e

TesteProdutoSortedSet.java

Mapeamento coleções do tipo

valor

(23)

 Projeto – MapeamentoColecoesObjetosEmbutidos

Mapeamento coleções com

objetos embutidos

(24)

 A maioria das dificuldades envolvidas na

implementação de uma solução ORM está

relacionada ao gerenciamento da associação;

 O ciclo de vida as entidades são independentes;

 Associações do Hibernate/Jpa são por natureza

unidirecionais (se alterar de um lado, não necessariamente o outro lado será alterado)

(25)

 Muitos para um @ManyToOne;

 Um para muitos @OneToMany;

 Um para um @OneToOne;

 Muitos para muitos @ManyToMany

(26)

 Projeto: MapeamentoEntidadesUmMuitos

 Mapeamentos bidirecionais são opcionais.

Obviamente, sem o uso deles, querys são inevitáveis;

 Mapeamentos bidirecionais são uma característica,

não uma necessidade;

 Em relacionamentos bidirecionais, é bom usar

mappedBy para informar ao Hibernate que a

coleção é uma imagem espelhada da associação do outro lado;

 Com mappedBy, o Hibernate é ”informado” sobre

qual a extremidade não deve sincronizar com o DB

(27)

 Cascatear = um tomar conta do outro (tratamento

automático);

 Novos objetos são transientes e é necessário que se

tornem persistentes para guardar no banco;

 Opções:

Cuidar das instâncias independentes;

Tornar o outro lado um tipo de valor (apenas para referências que não precisam ser compartilhadas); Persistência transitiva (cascades). Pode-se escolher

quais operações deseja-se que sejam transitivas

Multiplicidade – cascatear o

estado do objeto

(28)

 Cascata é para economizar linhas de código

necessárias para gerenciar o outro lado (estado do objeto transitivo)

 Opções cascade JPA:

PERSIST MERGE REMOVE REFRESH DETACH

ALL (todos os mencionados acima)

Multiplicidade – cascatear o

estado do objeto

(29)

 Um para Um (quer escrever o mapeamento?)

 Muitos para muitos (projeto

MapeamentoEntidadesMuitosMuitos)

 Após a apresentação, pegar o projeto

MapeamentoEntidadesMuitosMuitos e criar um atributo em tbPermissaoUsuario com a data/hora em que a permissão foi concedida

(30)

Classe concreta com polimorfismo implícito

 Projeto HerancaPolimorfismoImplicito;

 O identificador pode ou não estar na superclasse;

 Não suporta associações polimórficas;

 Colunas diferentes de tabelas diferentes

compartilham a mesma semântica;

 Recomendado apenas para o mais alto nível da

hierarquia onde não precisa de polimorfismo e

futuras mudanças na superclasse são improváveis

(31)

Classe concreta com uniões

 Projeto HerancaClasseConcretaUnioes;

 Classe pai precisa ser abstrata, senão também será

uma tabela;

 Faz uma query com unions para cada subclasse;

 Existe polimorfismo

(32)

Tabela por hierarquia de classe

 Projeto HerancaTabelaHierarquia;

 Simplicidade (especialmente para implementar sql na

mão) e performance;

 Precisa permitir valor nulo para os filhos;

 Normalização ???

(33)

Tabela por subclasse

 Projeto HerancaTabelaPorSubclasse;

 Associações relacionais por chave estrangeira;

 Esquema SQL normalizado;

 Difícil de implementar à mão (inner joins);

 Possibilidade de junções de muitas tabelas

(34)

Mistura de estratégias

 Projeto HerancaMisturaEstrategia

 Pode-se trocar a estratégia de uma subclasse, não

da classe pai;

(35)

 Polimorfismo implícito é mais útil para interfaces não

relacionadas à persistência;

 Se for necessário associações polimórficas e as

subclasses estenderem mais comportamento e menos propriedades, use tabela por hierarquia de classe;

 Subclasses declaram muitas propriedades? Tabelas

por subclasse;

 Dependendo da largura e profundidade de herança, é

preferível tabela por classe concreta.

(36)

 Entregar, até o dia17/09, todos os mapeamentos do

projeto (lembrando que, conforme combinado, o projeto deve ter no mínimo 5 tabelas);

 É altamente desejável que, o projeto precise no

mínimo dos mapeamentos abaixo:

 Herança;

 Granulosidade;

 Associações (no mínimo @ManyToOne e

@OneToMany);

 Tipos especiais como ENUM, Date

(37)

[1] Bauer, Christian e King, Gavin – Java persistence com Hibernate. Rio de Janeiro, Ed. Ciência Moderna, 2007; [2] ”Programando com Pools” - Java Magazine 57;

[3] ”Buscando informações em arquivos XML de forma simples com JDOM” - Mundo Java 36;

[4] ”JAXB – automatização e abstração de operações em XML” - Mundo Java 26;

[5] http://blog.caelum.com.br/jaxb-xml-e-java-de-maos-dadas/;