Mapeamento de herança OR
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Mapeamento de herança OR

on

  • 764 views

 

Statistics

Views

Total Views
764
Views on SlideShare
764
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Mapeamento de herança OR Presentation Transcript

  • 1. Programação Orientada a Objetos Estudo de Frameworks(Mapeamento Objeto-Relacional em Java) Objetivo: Identificar os processos de mapeamento Objeto-Relacional Prof. Nécio de Lima Veras
  • 2. Parte IVMapeamento de Herança
  • 3. Estratégias• SINGLE_TABLE – É a opção default. Há uma única tabela para toda a herarquia de classes. – Há uma coluna na tabela para determinar a classe (DiscriminatorColumn);• JOINED – Define que há uma tabela para cada classe da hierarquia de classes. – Atributos de uma superclasse são persistidos na tabela da superclasse; – Assim, para obter um objeto de uma subclasse, é necessário fazer um join envolvendo todas as tabelas das superclasses. Isso pode ser bastante oneroso para o banco de dados e comprometer a performance da aplicação, especialmente quando a hierarquia é complexa e composta de muitas classes; – Há uma coluna na tabela da classe base para determinar a classe (DiscriminatorColumn);• TABLE_PER_CLASS – Semelhante à estratégia JOINED, mas cada tabela possui os campos dos atributos herdados e os campos dos seus próprios atributos (não herdados);
  • 4. Visualizando Single Table Para o Funcionários e Professores:@Entity@Table(name="TBServidores") @Entity@Inheritance(strategy=InheritanceType.SINGLE_TABLE) @DiscriminatorValue@DiscriminatorColumn (name="Tipo") (value="Funcionario")public class Servidores { public class @Id protected BigInteger rg; Funcionario extends protected String nome; Servidor{ ... … }}
  • 5. Visualizando Joined
  • 6. Observações• É possível determinar uma superclasse da qual uma entidade herda atributos persistentes através da anotação @MappedSuperclass;• Recurso interessante quando várias classes compartilham atributos persistentes;• Pode-se usar as anotações @AttributeOverride ou @AssociationOverride na subclasse para sobrescrever a configuração da superclasse;
  • 7. VisualizandoTable_Per_Class
  • 8. Prática• Crie as classes abaixo e faça o seu mapeamento usando o framework Hibernate; – Use as três estratégias descritas; – Observe as diferenças; e – Documente as suas observações;
  • 9. Parte V - Callbacks
  • 10. Callbacks• JPA permite métodos de callback para acessar o EntityManager.• Eventos disponíveis: – PostLoad – PrePersist – PostPersist – PreRemove – PostRemove – PreUpdate – PostUpdate
  • 11. Exemplos@PrePersistvoid validateCreate() { if (idade > 130) { throw new IllegalStateException(); }} @Entity @EntityListeners(br.cefetpi.Monitor.class) Método public class Pessoa { ...Callback em } classe public class Monitor { @PostPersist Listener public void alertaNovaPessoa(Pessoa p) { emailRH(p); } }
  • 12. Sugestão de Prática• Dadas as classes do exercício anterior, faça os seguintes callbacks: – Informe quando uma pessoa for carregada; – Antes de gravar uma pessoa (física e jurídica), verifique se os documentos estão preenchidos; – Após uma pessoa ter sido gravada, exiba o documento correspondente; – Antes de remover uma pessoa, pergunte se essa é realmente a intenção. Caso não seja, gere uma exceção; – Após a remoção de uma pessoa, informe o documento no qual foi removido; – Após de realizar uma alteração em uma pessoa, para efeito comparativo, mostre os documento antigo e novo;
  • 13. Entendendo caches
  • 14. Cache• O Hibernate trabalha com dois tipos de cache: – first-level-cache – cache simples de sessão que é utilizado sempre, exclusivamente para diminuir os acessos ao banco de dados. Ao invés de realizar atualizações a cada comando dentro de uma transação, as atualizações são feitas somente ao final da transação. • Exemplo: Se um objeto é modificado várias vezes dentro de uma transação, o Hibernate gera somente um único comando SQL UPDATE ao final da transação, contendo todas as modificações. – second-level-cache – Mantém os objetos em memória e os utiliza mesmo entre diferentes sessões de uma mesma session factory. • Não é usado por default, devendo ser explicitamente configurado para que possa ser usado. • Deve-se configurar que entidades vão usá-lo, ou seja, quais vão ficar no cache.
  • 15. Visualizando • Existem diferentes estratégias para o Cache. – Indicamos que tipo de leitura e/ou escrita será feita e o cache saberá quando invalidar uma entrada; – As estratégias são essas: • NONE • NONSTRICT_READ_WRITE • READ_ONLY • READ_WRITE • TRANSACTIONAL@Entity@Cache(usage=CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)public class Cliente { ...}
  • 16. Entendendo as Estratégias• READ_ONLY – Útil para dados que são lidos, mas não, atualizados. – Simples e com excelente perfomance. A melhor em relação às demais.• READ_WRITE – Usado quando os dados são mais lidos que alterados. – Tem mais overhead que caches read-only.• NONSTRICT_READ_WRITE – Não garante que duas transações não modificarão simultaneamente o mesmo dado. – Usado quando as alterações são poucas;• TRANSACTIONAL – Cache inteiramente transacional, que exige um ambiente com suporte à JTA.