Aula 04

Analista de Tecnologia da Informação - Embasa
Curso de Engenharia e Desenvolvimento de Software

Prof. Diego Carvalho – Aula 04
▪ EntityManager.persist(Object): persiste o objeto Object;

▪ EntityManager.remove(Object): remove o objeto Object;
▪ EntityManager.find(Object): busca o objeto Object;
▪ EntityManager.refresh(Object): atualiza o objeto Object;
▪ EntityManager.createQuery(String): realiza uma consulta String;
Sabe quando você deseja realizar uma inserção no banco de dados? Pois é, o objeto
do EntityManager irá realizar essa tarefa! Esse gerenciador de entidades interage
com um Persistence Context, que é um local em que ficam armazenados os objetos
(entidades) que estão sendo manipulados pelo EntityManager corrente. Ele funciona
como um contêiner que guarda as entidades gerenciadas pelo EntityManager.
Um artigo do DevMedia faz uma excelente comparação entre Persistence Context

e a Memória Cache de um Processador (aquela mais rápida):
Imagine o Persistence Context como um container capaz de armazenar todas as

entidades que serão manipuladas pelo EntityManager. No início da nossa aplicação,
não temos Persistence Context ou EntityManager, pois não realizamos nenhuma
operação com o banco. Então, você decide buscar o usuário “Mario” no BD e, neste
momento, são criados 1 EntityManager + 1 PersistenceContext (ligados diretamente).
O EntityManager vai até o Persistence Context e checa se o usuário “Mario” já está

lá, e como não está, ele irá ao banco de dados realizar a consulta desejada retornando
o objeto Mario preenchido e populado. Depois de retornar o usuário “Mario” do BD,
o EntityManager grava esse objeto no Persistence Context (Nosso Cache). Assim, da
próxima vez que precisar deste objeto, não precisará ir ao banco de dados.
Então como você pode perceber no cenário acima, o EntityManager sempre consulta
o Persistence Context, checando se o objeto já está lá e, caso não esteja, aí sim ele irá
até o banco de dados. Quando o EntityManager é destruído (no fim de uma
requisição) o Persistence Context também será destruído, impossibilitando de usá-los
em outros EntityManager com outros PersistenceContext.
Lá em cima, eu afirmei que um EntityManager mapeava um conjunto de classes

para um banco de dados particular. Esse conjunto de classes é denominado
Persistence Unit2. Antes esmo e pensar iar tidades ou c nsultá-las por
meio do EntityManager, é necessário pacotar sse conjunto e classes em m
Persistence Unit, que é definido no Descritor de Implantação (persistence.xml).
2
Ele especifica qual implementação será utilizada (Hibernate, Toplink, JDO, etc); conexão com banco, etc.
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 6 de 89

banco de dados. Objetos ecuperados o anco e dados or m EntityManager

também estão no estado Gerenciado.
Se um objeto Gerenciado é modificado dentro de uma transação ativa, a mudança

é detectada pelo EntityManager e a atualização é propagada no banco de dados
após o Commit. Um bjeto Gerenciado também pode ser ecuperado o anco e
dados marcado ara remoção, tilizando o étodo emove do EntityManager
dentro de uma transação ativa.
O objeto modifica seu estado de Gerenciado para Removido, e é fisicamente

deletado do banco de dados após o Commit. O ltimo ado, stacado,
representa um bjeto que foi esconectado o EntityManager Quando um objeto
é Destacado, mudanças sucessivas não irão mais ser rastreadas e nenhuma
sincronização automática do banco de dados será realizada.

objeto-relacional para objetos Java simples e comuns (POJOs), denominados

beans de entidade, também é utilizado para gerenciar o desenvolvimento de
entidades do modelo relacional em plataforma nativa Java SE e Java EE.
a) JSF
b) SVN
c) JPA
d) spring
e) struts
Comentários:
Em suma, podemos dizer que o JPA padrão a persistência de s e

fornece s senvolvedores mapeamento bjeto/relacional a gerenciamento
de s elacionais m Aplicações ava – em outras palavras, ele simplifica a
persistência de dados. Ele pode ser utilizado pelo Container EJB, pelo Container Web
ou pelo Application Client.
Rapidamente: algumas pessoas me perguntam qual a diferença entre um POJO e

um JavaBean! Todo JavaBean é um POJO, mas nem todo POJO é um JavaBean. Eles
são muito parecidos, mas o JavaBean segue diversas convenções de programação,
tais como: nomenclatura dos métodos, construtor público padrão e sem parâmetros,
entre outros. Para o JPA, o POJO é a unidade básica!
E foi assim que surgiu o Java Persistence API (JPA)! Olha que engraçado: a
especificação surgiu após as implementações! Como uma das vantagens, pode-se
trocar de implementação (Ex: Hibernate para TopLink) sem a necessidade de
modificar o código-fonte. Enfim, ele foi incorporado ao EJB 3.0 (apesar de ser
independente deste), permitindo sua utilização em Ambientes Java SE Java EE.
Ele também é importante para desacoplar o código da aplicação dos frameworks de

infraestrutura. Mudou o framework? O POJO continuará funcionando – inclusive, a
mudança será fácil e conterá menos riscos! Até a Especificação EJB 2.0, a persistência
de dados era parte da Plataforma EJB e ra realizada por io ntity ans ue
eram uma espécie de POJO.
Conforme vimos em aula, JPA é utilizado para realizar o mapeamento

objeto/relacional, utilizando POJOs, em ambientes Java SE e Java EE.
Gabarito: C

e) possui uma interface EntityBeans que padroniza operações Create Read

Update Delete (CRUD) que envolvem tabelas.
Comentários:
E foi assim que surgiu o Java Persistence API (JPA)! Olha que engraçado: a
especificação surgiu após as implementações! Como uma das vantagens, pode-se
trocar de implementação (Ex: Hibernate para TopLink) sem a necessidade de
modificar o código-fonte. Enfim, le oi incorporado JB 3.0 (apesar d er
independente dessa), permitindo sua utilização em Ambientes Java SE Java EE.
(a) Conforme vimos em aula, pode ser usada independente do EJB 3.0, inclusive em
Ambiente Java SE.
(b) Esse item é obsoleto atualmente. Não vale a pena discuti-lo, vai confundir a
cabeça de vocês. Está errado!
Essas ferramentas facilitam o mapeamento s ributos d base os

relacional ao delo d bjetos aplicação r io scritores d
Implantação XML) u Anotações (Annotations) – principalmente para consultas e
atualizações de dados. O desenvolvedor define como os objetos são mapeados e o
framework faz o resto – acessa o banco, gera os comandos SQL, etc.
(c) Conforme vimos em aula, pode-se utilizar Descritores de Implantação (XML) e

Anotações (Annotations).
▪ Java Persistence API (JPA): define um mapeamento objeto/relacional para

gerenciamento de dados relacionais;
▪ Java Persistence Query Language (JPQL): define queries, em geral, estáticas, para
entidades e seus estados persistentes;
▪ Java ersistence iteria API (JPCA): define queries, em geral, dinâmicas para
entidades e seus estados persistentes;
▪ Mapeamento tadados / define um mapeamento por meio de Descritores

de Implantação (XML) ou Anotações (Annotations).
(d) Conforme vimos em aula, pode-se utilizar JPQL e JPCA, com acesso feito por
SQL ou Java.

A SERVER FACES (JSF)
Galera, vou contar uma historinha para vocês! Durante muito empo, suários e
acostumaram m plicações Desktop. O que é isso, professor? É aquele
programinha que você baixa e instala em seu computador local, acessando
diretamente bancos de dados ou gerenciadores de arquivos. Para criar essas
aplicações eram utilizadas as tecnologias Visual Basic, Delphi, Swing (Java), etc.
Pois es programas eral ão ecessitam e um avegador ara rodar! Eles

são construídos como um conjunto de componentes oferecidos pela plataforma de
desenvolvimento para cada sistema operacional e estão associados a eventos, ações
ou procedimentos que executam lógicas de negócio. Muitas das vezes, são
componentes muito ricos.
No tanto, sabe-se que Aplicações Desktop sofrem com problemas de

manutenção gerenciabilidade. Vejam que as regras de negócio rodam no cliente
– aliás, uma cópia integral da aplicação está no cliente! Logo, se deu pau em alguma
funcionalidade, eu tenho que propagar as alterações para todas as máquinas que
têm o programa, visto que as regras de negócio estão no cliente!
Para resolver esse tipo de problema, surgiram as Aplicações Web. Elas rodam em
um servidor central onde os usuários podem acessá-las por meio de um navegador
(Chrome, Firefox, etc) e um protocolo HTTP. Nesse caso, odas egras de negócio
da aplicação e encontram o ervidor, endo uito ais il erenciá-las ,
eventualmente, epurá-las.
Ora, deu pau em alguma funcionalidade, eu vou lá no servidor central e conserto –

não preciso ir em todas as máquinas que têm a aplicação! Claro, nem tudo são
flores, é necessário conhecer diversas tecnologias, linguagens, scripts, entre outros
– além de seguir um modelo de requisição/resposta. Agora vejam que interessante,
eu posso combinar esses dois universos.
É possível unir as melhores características desses dois mundos, com componentes

ricos, abstraindo protocolos, etc. Vocês já ouviram falar da Arquitetura Model-View-
Controller (MVC)? Pois é, trata-se de uma arquitetura que divide s componentes
de uma aplicação adas ndependentes (Modelo, isão Controle)! O
Controle faz o meio campo entre a Visão e o Modelo.

Com o ínimo e esforço possível criar ma página web; adicionar componentes

em uma página ao adicionar tags de componentes; vincular componentes de uma
página a dados server-side; conectar eventos gerados por componentes ao código
da aplicação; salvar e restaurar o estado da aplicação além da vida da requisição do
servidor; e reutilizar e estender componentes por meio de customização.
Podemos definir a Tecnologia JSF como uma tecnologia que nos permite criar
Aplicações Web utilizando componentes visuais pré-prontos, de forma que o
desenvolvedor não se procupe com Javascript ou HTML. A uncionalidade fornecida
por ma Aplicação F similar qualquer outra Aplicação e . Ela possui as
seguintes partes:
▪ Um conjunto de Páginas Web em que são colocados os componentes;

▪ Um conjunto de tags para adicionar componentes à página web;
▪ Um conjunto de Managed Beans (ou Beans Gerenciados);
▪ Um Descritor de Implantação Web (web.xml);
▪ Um ou mais arquivos de configuração (Ex: faces-config.xml);
▪ Um conjunto de objetos customizados (Ex: validadores, conversores, etc);
▪ Um conjunto de tags customizadas para representar objetos customizados;
Pessoal, F ferece diversos alidadores embutidos ara validar seus

Componentes UI a validação corre no ado do ervidor. Eles podem ser
invocados a partir de sua tag específica e podem validar o tamanho de um campo,
tipo de entrada, range de um valor numérico, expressão regular, entre outros. É
possível, inclusive, criar o seu próprio validador customizado.

Observem imagem ma! Uma Página Web myfacelet.xhtml é construída utilizando

tags de Componentes JSF. Essas tags são usadas para adicionar componentes à
visão (myView), que é uma representação server-side da página. Além dos
componentes, uma página web pode referenciar objetos como listeners,
validadores, conversores, entre outros.
Em resposta a uma requisição do cliente, uma página web é renderizada por um

contêiner web que implementa a tecnologia JSF! Uma de suas randes vantagens
que ele oferece uma clara separação tre comportamento apresentação. Ele
mapeia solicitações HTTP para o tratamento de eventos específicos dos
componentes e gerencia os componentes como objetos stateful no servidor.
Outro importante objetivo é aproveitar componentes e conceitos já familiares aos

programadores, sem imitá-los ma tecnologia de script u uma linguagem de
marcação ecíficas. Isso possibilita a utilização de diferentes tecnologias de
apresentação, a criação de componentes próprios a partir das classes de
componentes, e a geração de saídas para diversos dispositivos (Ex: Celular, Tablet).
O JSF fornece uma maneira fácil e amigável para criar Aplicações Web por meio de,
basicamente, três atividades:
▪ Criar uma Página Web (usando tags de componentes);

▪ Desenvolver Managed Beans;
▪ E mapear a instância FacesServlet.
Aqui vamos fazer uma pequena pausa! Professor, o que é um Managed Bean? São
apenas OJOs m annotation @ManagedBeans. Pensem no seguinte: meu sistema
precisa escrever “Olá, pessoal” no navegador. Bem, esse texto não precisa de
nenhuma informação, não acessa nada, é muito simples – basta colocá-lo
diretamente na camada de visão e mostrá-lo!
E se eu tenho que dar um “Olá, X”, em que X é o nome da pessoa que acessou o
sistema? Em outras palavras, se eu acessei, deve mostrar “Olá, Diego”; se o Messi
acessou, deve mostrar “Olá, Messi”! Para tal, eu vou precisar acessar o banco de
dados, buscar informações do sistema, talvez saber o horário de acesso, i.e., vou
precisar interagir com o modelo, ógica de negócio ou componentes visuais.
Ora, nós prezamos pela separação de responsabilidades! Logo, esse código ficará
em uma classe de modelo e, jamais, na visão. Os naged Beans ão s bjetos
que intermediam comunicação tre a visão o odelo. Eles são registrados no

O @SessionScoped ersiste o empo ue durar ma sessão, .e., té invocar m

método nválido ou empo bar (lembrar e um rinho e compras); o
@FlashScoped dura um redirecionamento de página; o @NoneScoped indica que
o escopo não está definido para a aplicação; por fim, o @CustomScoped é um
escopo personalizado.

Agora eu queria falar uma curiosidade interessante! xiste um adrão e Projeto

Java EE amado Front ntroller. Nesse padrão, todas as requisições do usuário
são recebidas pelo mesmo componente. Dessa forma, tarefas que devem ser
realizadas em todas as requisições podem ser implementadas por esse componente
– evitando repetição de código e facilitando a manutenção do sistema.
No JSF, esse componente é o FacesServlet! Como mostra a imagem da estrutura

geral de uma Aplicação JSF, o rocessamento e uma requisição viada por m
navegador omeça na FacesServlet. Observem que ela controla a execução das seis
etapas do ciclo de vida, interagindo com o Model (Entidades e repositórios) e com
as Views (Telas, Templates, etc).
Os Managed Beans ão disposição da FacesServlet durante todo o

processamento a requisição. Nas etapas Render Response e Restore View, a ela
aciona os Managed Beans para recuperar os dados que devem ser usados na
construção ou reconstrução da árvore de componentes. Na etapa Update Model, a
FacesServlet armazena nos Managed Beans os dados já convertidos e validados.
Na etapa Invoke Application, a FacesServlet dispara um método em um Managed

Bean responsável pelo processamento da regra de negócio correspondente à
requisição atual. Todas egras e negócio são mplementadas o odelo, ue
também ministra os ados a aplicação. Os Managed Beans acionam o modelo
para executar regras de negócio, recuperar dados administrados pelo modelo, etc.
As telas da aplicação são definidas na camada de visão. A FacesServlet acessa essa

camada toda vez que necessita construir ou reconstruir a árvore de componentes
de uma determinada tela. Isso ocorre nas etapas Restore View e Render Response.
Aliás, amos er gora rapidamente orque não uuuuito m rovas lo
de vida do JSF! Ele é apresentado na imagem abaixo:

Pelo o o amework JSF er alvez uma evolução a linguagem P, o o e

vida do F é parecido com o o SP. Por exemplo, quando o cliente faz uma
Requisição HTTP para a página, o servidor responde com a página traduzida para
HTML. Porém, ele é dividido em múltiplas fases, apresentando um modelo de
componentes de interface com usuário mais sofisticado.
▪ Restore View: restauram-se os objetos e estruturas de dados que representam

a visão. Claro, se essa for a primeira visita à página, deve-se criar a visão. Quando
o JSF cria e renderiza uma página JSF, ele cria objetos de interface com o usuário
para cada componente da visão. Os componentes são armazenados em uma
árvore de componentes e o estado da visão é salvo para requisições futuras.
▪ Apply quest Values: qualquer dado que for enviado como parte da requisição
é passado para os componentes apropriados. Essas visões atualizam seus
estados com os valores dos dados. Dados podem vir de formulários, cookies
enviados com a requisição ou por meio de cabeçalhos da requisição. Alguns
dados são validados e, se houver erro, são adicionados à FacesServlet.
▪ Process alidation: os dados que foram submetidos com o formulário são

validados (se já não o foram anteriormente). Assim como na fase anterior, isso
ainda não atualiza os objetos de negócio na aplicação. Isso ocorre porque, se a
Aplicação atualizar os objetos de negócio junto com a validação dos dados e
uma parte da validação falhar, o modelo será atualizado com um estado inválido.
▪ Update Model Values: após todas essas validações terminarem, os objetos de

negócio que criam a aplicação são atualizados com os dados validados da
requisição. Ademais, se qualquer um dos dados precisar ser convertido em um
formato diferente para atualizar o modelo (Ex: String para Data), a conversão
ocorrerá nessa fase.
▪ Invoke plication: durante essa fase, os métodos de ação de qualquer botão

ou link que foi ativado serão chamados. Além disso, todos os eventos que foram
gerados durante as fases anteriores e que ainda não tenham sido manipulados
são passados para a Aplicação Web para que ela possa concluir qualquer outro
processamento da requisição que seja necessário.
▪ Render R s onse: os Componentes UI de resposta são renderizados e a resposta

é enviada para o cliente. O estado dos componentes é salvo de modo que a
árvore de componente possa ser restaurada quando o cliente enviar outra

A DATABASE CONECTIVITY (JDBC)
De rdo m documentação ficial: rata-se de uma API ue fornece acesso

universal dados artir da linguagem de programação va. É possível acessar
praticamente qualquer fonte de dados, desde bancos de dados relacionais a
planilhas ou arquivos simples. O JDBC também fornece uma base comum sobre a
quais ferramentas e interfaces alternativas podem ser construídas.
Ele estabelece conexões com um banco de dados, envia comandos SQL e processa
os resultados. Aliás, com a utilização de JDBC, torna-se fácil enviar um comando
SQL para diferentes bancos de dados relacionais. Em utras alavras, ão é
necessário esc ever m rograma para acessar m anco de dados Oracle, outro
para acessar um banco de dados SQL Server, e assim por diante.
Essa tecnologia permite invocar comandos SQL a partir de métodos em classes Java.
Ela fornece uma API do tipo call-level para acesso a bancos de dados baseado em
SQL. Os mponentes dessa API estão ocalizados os acotes java.sql e javax.sql. Para
conseguir acesso a diversos bancos de dados diferentes de maneira uniforme e
padronizada, utilizam-se Drivers.
Como assim, professor? O Driver faz a interface entre a Aplicação Web e o SGBD!
Para eu e conectar um anco e dados ndividual, reciso er os rivers ara
aquele banco de dados pecífico. O JDBC permite a conexão com praticamente
qualquer SGBD (Oracle, DB2, SQL Server, MySQL, PostgreSQL, etc). Existem,
atualmente, quatro tipos de Drivers:
▪ JDBC-ODBC Bridge: É o tipo mais simples. Utiliza ODBC para conectar-se com o
banco de dados, convertendo métodos JDBC em chamadas às funções do
ODBC. Esta ponte é normalmente usada quando não há um driver puro-Java
para determinado banco de dados, pois seu uso é desencorajado devido à
dependência de plataforma.
▪ Native A I: converte chamadas JDBC na API do cliente em chamadas para o

SGBD Oracle, Sybase, Informix, etc. São escritos parcialmente em Java e
parcialmente em código nativo. Requer que algum código binário específico do
SO seja carregado em cada máquina cliente e usa uma biblioteca nativa
específica no cliente para a fonte de dados para que eles se conectem.

▪ Network Protocol: traduz chamadas JDBC em um protocolo de rede

independente do SGBD, que é então convertido para um protocolo específico
do SGBD por um middleware. Em geral, esta é a alternativa JDBC mais flexível de
todas, em que fornecedores disponibilizam produtos adequados para uso na
internet.
▪ Database Protocol: permite chamada direta da máquina do cliente para o

Servidor SGBD. Converte as chamadas JDBC diretamente no protocolo do banco
de dados. Implementado em Java, normalmente é independente de plataforma
e escrito pelos próprios desenvolvedores. É o tipo mais recomendado para ser
usado.
Open Database Connectivity (ODBC) é um adrão erto esenvolvido ara ue

linguagens de programação ou istemas peracionais e comuniquem om bancos
de dados e maneira independente de plataforma. O JDBC utiliza um driver
específico para banco de dados; o ODBC utiliza sempre o mesmo Driver e depois
configuram-se as propriedades do sistema para acessar determinado banco.
Dado que foi utilizado o driver adequado para acesso ao banco de dados, pode-se
utilizar a classe Connection para estabelecer a conexão, de fato, com o banco. Essa
classe se encontra no pacote java.sql – que contém uma biblioteca para acesso e
processamento de dados em uma fonte de dados. As classes, métodos e interfaces
dele mais importantes são:
▪ Driver: interface pública abstrata que todo driver deve implementar para
executar instruções SQL.
▪ DriverManager: classe que contém o registro de cada driver, oferecendo

métodos estáticos para gerenciá-los.
▪ Connection: interface que representa uma conexão com o banco de dados –

possui diversos métodos importantes.
▪ Statement: interface pública abstrata que é utilizada para executar instruções

SQL estáticas e obter os resultados de sua execução.
▪ ResultSet: essa interface é uma tabela de dados que representa o resultado

de uma instrução SQL em um banco de dados.

▪ PreparedStatement: interface pública abstrata utilizada para estender a

interface Statement e criar um objeto que represente uma instrução SQL.
▪ CallableStatement: interface que permite executar funções ou procedimentos

armazenados no banco.
try
{
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver").getInstance();
Connection con =
DriverManager.getConnection("jdbc:odbc:meusCdsDb","conta","senha");
}
catch(SQLException e)
{ // Se o carregador não localizar o driver do banco para conexão, lança a
// exceção java.lang.ClassNotFoundExeption
e.printStackTrace();
}
Para acessar m anco de dados, o rimeiro asso estabelecer ma conexão! É

possível fazer isso em duas etapas: primeiro, carrega-se o driver do banco de dados.
Uma vez carregado, o driver se registra para o DriverManager e está disponível para
a aplicação. Então usa-se o DriverManager para abrir uma conexão com o banco
de dados. A interface Connection designa um objeto con para receber a conexão.
Statement stm = con.createStatement();

String SQL = "Select coluna1, coluna2, coluna3 from TabelaX";
Estabelecida a conexão, odemos tar mandos QL o anco e dados. ara

realizar ma operação, odemos sar rês interfaces. A primeira delas é a interface
Statement, que permite a execução dos comandos fundamentais de SQL (SELECT,
INSERT, UPDATE ou DELETE). A interface PreparedStatement nos permite usufruir
de SQL armazenado ou pré-compilado no banco.
ResultSet rs = stm.executeQuery(SQL);
A terceira interface é CallableStatement, permite executar procedimentos

funções armazenados o banco quando anco uportar s e recurso). A interface
ResultSet permite colher os resultados da execução de nossa query no banco de
dados. Esta interface apresenta uma série de métodos para prover o acesso aos
dados. Depois é só encerrar o acesso, liberando recursos.
finally
{
try
{

con.close();
}
catch(SQLException onConClose)
{
System.out.println("ERRO NO FECHAMENTO DA CONEXÃO");
onConClose.printStackTrace();
}
}
Podemos azer sso chando o Statement, ue libera os ecursos sociados

execução esta consulta, mas deixa a conexão aberta para a execução de uma
próxima consulta; ou fechando diretamente a conexão, que encerra a comunicação
com o banco de dados. Para termos certeza de que vamos encerrar esta conexão
mesmo que uma exceção ocorra, reservamos o fechamento para a cláusula finally().

d) O JSTL permite ao programador escrever páginas JSPs sem necessariamente

utilizar códigos Java, facilitando a integração entre webdesigners e
programadores.

Aula 04

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula 04

Enviado por

Direitos autorais:

Formatos disponíveis

Analista de Tecnologia da Informação - Embasa

Curso de Engenharia e Desenvolvimento de Software

▪ EntityManager.persist(Object): persiste o objeto Object;

Um artigo do DevMedia faz uma excelente comparação entre Persistence Context

Imagine o Persistence Context como um container capaz de armazenar todas as

O EntityManager vai até o Persistence Context e checa se o usuário “Mario” já está

Lá em cima, eu afirmei que um EntityManager mapeava um conjunto de classes

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 6 de 89

banco de dados. Objetos ecuperados o anco e dados or m EntityManager

Se um objeto Gerenciado é modificado dentro de uma transação ativa, a mudança

O objeto modifica seu estado de Gerenciado para Removido, e é fisicamente

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 8 de 89

objeto-relacional para objetos Java simples e comuns (POJOs), denominados

Em suma, podemos dizer que o JPA padrão a persistência de s e

Rapidamente: algumas pessoas me perguntam qual a diferença entre um POJO e

Ele também é importante para desacoplar o código da aplicação dos frameworks de

Conforme vimos em aula, JPA é utilizado para realizar o mapeamento

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 13 de 89

e) possui uma interface EntityBeans que padroniza operações Create Read

Essas ferramentas facilitam o mapeamento s ributos d base os

(c) Conforme vimos em aula, pode-se utilizar Descritores de Implantação (XML) e

▪ Java Persistence API (JPA): define um mapeamento objeto/relacional para

▪ Mapeamento tadados / define um mapeamento por meio de Descritores

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 22 de 89

A SERVER FACES (JSF)

Pois es programas eral ão ecessitam e um avegador ara rodar! Eles

No tanto, sabe-se que Aplicações Desktop sofrem com problemas de

Ora, deu pau em alguma funcionalidade, eu vou lá no servidor central e conserto –

É possível unir as melhores características desses dois mundos, com componentes

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 25 de 89

Com o ínimo e esforço possível criar ma página web; adicionar componentes

▪ Um conjunto de Páginas Web em que são colocados os componentes;

Pessoal, F ferece diversos alidadores embutidos ara validar seus

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 27 de 89

Observem imagem ma! Uma Página Web myfacelet.xhtml é construída utilizando

Em resposta a uma requisição do cliente, uma página web é renderizada por um

Outro importante objetivo é aproveitar componentes e conceitos já familiares aos

▪ Criar uma Página Web (usando tags de componentes);

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 28 de 89

O @SessionScoped ersiste o empo ue durar ma sessão, .e., té invocar m

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 30 de 89

Agora eu queria falar uma curiosidade interessante! xiste um adrão e Projeto

No JSF, esse componente é o FacesServlet! Como mostra a imagem da estrutura

Os Managed Beans ão disposição da FacesServlet durante todo o

Na etapa Invoke Application, a FacesServlet dispara um método em um Managed

As telas da aplicação são definidas na camada de visão. A FacesServlet acessa essa

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 31 de 89

Pelo o o amework JSF er alvez uma evolução a linguagem P, o o e

▪ Restore View: restauram-se os objetos e estruturas de dados que representam

▪ Process alidation: os dados que foram submetidos com o formulário são

▪ Update Model Values: após todas essas validações terminarem, os objetos de

▪ Invoke plication: durante essa fase, os métodos de ação de qualquer botão

▪ Render R s onse: os Componentes UI de resposta são renderizados e a resposta

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 32 de 89

A DATABASE CONECTIVITY (JDBC)

De rdo m documentação ficial: rata-se de uma API ue fornece acesso

▪ Native A I: converte chamadas JDBC na API do cliente em chamadas para o

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 60 de 89

▪ Network Protocol: traduz chamadas JDBC em um protocolo de rede

▪ Database Protocol: permite chamada direta da máquina do cliente para o

Open Database Connectivity (ODBC) é um adrão erto esenvolvido ara ue

▪ DriverManager: classe que contém o registro de cada driver, oferecendo