Desenvolvimento de Aplicações para Internet Material Apoio AOL 4

Prévia do material em texto

Interação com banco de dados
A maioria das aplicações para web utiliza banco de dados no oferecimento de seus serviços. Nesse contexto, as linguagens e servidores que geram páginas dinâmicas oferecem diversos recursos para realizar a programação que comunica com sistemas de bancos de dados. Sendo assim, veremos de modo sucinto e prático como realizar essa programação.
Para a conexão das classes Java com os sistemas gerenciadores de bancos de dados, a tecnologia utilizada é a Java Database Connectivity (JDBC), que disponibiliza em seu núcleo um conjunto de funções úteis em uma biblioteca para os desenvolvedores, chamada de JDBC Core API. Podemos dizer que a JDBC representa a ponte dos JSPs e Servlets com os bancos de dados para as mais diversas consultas e obtenção do adequado retorno com os dados a serem disponibilizados nos documentos HTML.
Vale ressaltar que a manipulação de bases de dados evoluiu muito desde a chamada era relacional, que utiliza consultas do tipo SQL em tabelas, até os sistemas de bancos de dados orientados a objetos do tipo SQL. A vantagem da utilização do Java para trabalhar com bases de dados é que ela tem boa compatibilidade com a maioria desses sistemas, com vários recursos que facilitam o trabalho do desenvolvedor, como a disponibilidade dos chamados drivers, que fazem a ligação com um determinado tipo de sistema.
Por exemplo, caso o desenvolvedor opte pelo uso do sistema de banco de dados gratuito MySQL, ele deve fazer o download e a instalação de seu driver chamado MySQL Connector/J, que é disponibilizado no formato JAR em versões específicas para o sistema operacional que irá realizar a conexão.
Existem quatro tipos de drivers JDBC que podem ser disponibilizados para que a aplicação Java possa interagir como cliente de um servidor de banco de dados, a saber:
Clique nos botões para saber mais
Tipo 1 - Ponte (bridge)
–
Utiliza outro driver para acessar o banco de dados. Seu maior exemplo é um driver JDBC/ODBC, que é restrito para o sistema Windows e utiliza ODBC para conectar-se com o banco de dados. Esse tipo é normalmente utilizado quando não há um driver puro-Java (tipo 4) para um banco de dados;
Tipo 2 - Driver API-Nativo
–
Traduz as chamadas JDBC para as chamadas da API cliente do banco de dados utilizado. Normalmente é fornecido pelo fabricante do banco de dados e desenvolvido em alguma linguagem nativa da plataforma;
Tipo 3 - Driver de Protocolo de Rede
–
Transfere, de modo flexível, as chamadas JDBC para um protocolo de rede independente de banco de dados;
Tipo 4 - Driver nativo
–
Converte as chamadas JDBC diretamente no protocolo do banco de dados. É o tipo mais recomendado para ser usado, pois é implementado em Java, normalmente sendo independente de sistema operacional e escrito pelos próprios desenvolvedores.
Após a instalação adequada do driver para conexão, ele deve ser chamado no código fonte Java do seguinte modo:
Class.forName(“caminho.para.o.driver”);
Em seguida, o desenvolvedor deve usar os pacotes para trabalhar com bancos de dados, que são o java.sql e o javax.sql, que processam dados de uma determinada fonte de dados. O ponto inicial para interação com esses dados é a conexão, que usa a interface connection que, por fim, usa o endereço do servidor de banco de dados e as credenciais do usuário.
Com a conexão estabelecida com o servidor de banco de dados, o JSP ou Servlet pode executar as consultas usando o objeto Statement, que recebe as declarações em SQL, no caso de bancos relacionais. Logo em seguida, deve ser executada ou aplicada essa consulta, chamada query. Os dados resultantes da consulta são disponibilizados no ResultSet (ou conjunto de resultados, em português). Esse ResultSet pode armazenar um ou vários itens.
Para percorrer esse conjunto de dados são disponibilizados métodos e um cursor, que se inicia na primeira linha do conjunto de resultados.
Recapitulando: são quatro etapas básicas para acessar um banco de dados usando JDBC:
· 1
Instalar e carregar o driver JDBC;
· 2
Realizar a conexão;
· 3
Criar e executar declarações do tipo statement;
· 4
Obter um conjunto de dados ou informação se houve sucesso na consulta.
Existem frameworks que se encarregam de realizar a persistência de objetos em Java, como exemplo mais conhecido podemos citar o Hibernate (https://hibernate.org/). Mesmo com as facilidades providas por frameworks dessa natureza, o entendimento de aspectos técnicos da JDBC não deve ser ignorado, pois eles utilizam a tecnologia JDBC internamente.
Um código completo Java que executa uma interação simples com uma base de dados relacional pode ser visto a seguir:
1.    public static void main(String[] args) {
2.    Connection conn = null;
3.    Statement stmt = null;
4.    try{
5.    Class.forName("com.mysql.jdbc.Driver");
6.    conn = DriverManager.getConnection(DB_URL,USER,PASS);
7.    stmt = conn.createStatement();
8.    String sql;
9.    sql = "SELECT nome FROM alunos";
10.    ResultSet rs = stmt.executeQuery(sql);
11.    while(rs.next()){
12.    String nome = rs.getString("nome"); 
13.    System.out.print("Nome: " + nome);
14.    }
15.    rs.close();
16.    stmt.close();
17.    conn.close();
18.    } catch(SQLException se){
19.    se.printStackTrace();
20.    } catch(Exception e){
21.    e.printStackTrace();
22.    }
23.    }
Na linha 1, começamos o método desejado dentro de uma classe. A partir da linha 5, temos o uso da parte de interação com banco de dados propriamente dito, com escolha do driver, que nesse caso é para o sistema MySQL.
A conexão é, então, criada na linha 6 com a passagem de parâmetros relativos à localização do servidor de banco de dados, seu usuário e senha. Na linha 7, temos a criação do objeto de declaração statement, que vai receber na linha 10 a string de texto da variável SQL que contém o comando escrito em SQL para ser executado. Nas linhas de 11, 12 e 13 temos o processamento do resultado, percorrendo cada item do conjunto de resultados chamado de ResultSet. Para obter o valor encontrado em cada item é possível usar o nome da coluna da tabela pelo método getString.
Com essas informações, você já pode realizar o primeiro contato de sua aplicação com o banco de dados para ir aprimorando-a a partir de um estudo mais profundo dessa área.
Criação e implantação de arquivos WAR
Para o funcionamento das aplicações web em algum servidor, deve ocorrer sua distribuição ou implantação, chamada de deployment, que geralmente é realizada após a etapa de desenvolvimento. Nesse processo, toda estrutura de pastas e seus arquivos são enviados para o servidor que contém o contêiner web.
Existe uma maneira mais fácil e segura de realizar esse processo de envio de arquivos, que é o empacotamento da aplicação em arquivo de aplicação: o chamado WAR – nome proveniente da sigla em inglês para Web Application ARchive – sendo esse um padrão da especificação Java Servlet.
De modo sucinto, um arquivo WAR é um arquivo JAR, do inglês Java ARchive, que contém todos os arquivos compactados do projeto da aplicação web. Ou seja, os arquivos WAR são específicos para projetos web, estando os contêineres web preparados para recebê-los, enquanto os arquivos do tipo JAR são para aplicações genéricas Java geralmente para compor e distribuir bibliotecas de utilitários para aplicações. Essa maneira é a mais fácil de trabalhar, pois você terá que enviar apenas um arquivo para o servidor, contendo toda a aplicação que na prática pode conter centenas ou até milhares de arquivos (sim, essa tecnologia também é utilizada para aplicações de grande porte, para empresas ou instituições que demandam o uso sistemas grandes e complexos).
Ainda é necessário considerar que essa maneira é mais segura, pois o controle de envio do arquivo é facilitado. Imagine que enviando arquivo por arquivo é necessário checar de modo unitário se esses elementos chegaram corretamente no servidor (verificando o tamanho do arquivo no destino, por exemplo). Na prática, após a geração do arquivo WAR, ele deve ser enviado para dentro da pasta webapps, momento em que o contêinerweb já irá reconhecê-lo, provendo o acesso aos arquivos nele contidos do mesmo modo que se eles não estivessem compactados.
Uma pequena desvantagem da implantação utilizando arquivos WAR é que qualquer alteração não pode ser feita no tempo de execução, geralmente essa técnica é usada para correção rápida de algum erro no ambiente de produção.
Qualquer alteração na aplicação, por menor que seja, neste modelo de implantação requer nova geração e reenvio do arquivo WAR. Na verdade, a prática de realizar alterações no ambiente de produção não é recomendada em nenhum caso, considerando as boas práticas de engenharia de software presentes na literatura. Isso ainda considerando que realizar a correção no ambiente de produção é mais rápido (seria como consertar um avião em pleno voo).
CRIANDO UM ARQUIVO WAR
Para criar um arquivo WAR de sua aplicação usando o ambiente Eclipse, o primeiro passo é abrir seu projeto e depois clicar em “File” > “Export” (ou usar a tecla de atalho Alt + F + O, no Windows) e selecionar WAR, conforme pode ser visto na Figura 1.
Figura 1. Captura de tela da exportação o projeto no Eclipse para implantação com arquivo WAR.
Uma alternativa para esse passo é clicar com o botão esquerdo do mouse no nome do projeto e selecionar “Export” > “WAR” no menu de contexto, como pode ser visto na Figura 2.
Figura 2. Captura de tela da alternativa de caminho para exportação de projeto no Eclipse.
Em qualquer um desses caminhos será aberta uma janela com um formulário simples para a geração do arquivo WAR, como pode ser visto na Figura 3.
Figura 3. Captura de tela da janela com formulário para geração do arquivo WAR.
Além da necessidade de especificação de nomes do projeto e do arquivo de destino e seu caminho, existem três caixas de seleção opcionais:
· A primeira que permite otimizar o arquivo para um tempo de execução específico para o servidor. Só deixe essa caixa marcada se você tiver certeza do ambiente em que a sua aplicação irá funcionar;
· A segunda caixa, que é a Export source files, diz respeito se você deseja incluir os arquivos fonte Java no arquivo WAR gerado. Essa opção geralmente fica desmarcada;
· Estando a terceira caixa marcada, irá sobrescrever o arquivo WAR, se o nome especificado já existir.
Com o formulário preenchido adequadamente, basta clicar em Finish para que o Eclipse crie o arquivo WAR desejado.
Além do uso do ambiente Eclipse para a criação dos arquivos WARs, é possível cria-los manualmente utilizando a ferramenta JAR presente no JDK em linha de comando, do seguinte modo:
Em modo de linha de comando de seu sistema operacional, vá para dentro do diretório do projeto (na pasta acima da WEB-INF) e escreva o seguinte comando:
jar -cvf projectname.war *
 Os parâmetros do comando são os seguintes:
· -c é utilizado para criar o arquivo;
· -v para gerar a saída detalhada (também chamado de modo verboso);
· -f para especificar o nome do arquivo do arquivo;
· O símbolo * (asterisco) significa que todos os arquivos desta pasta serão inclusos (os das subpastas também).
DICA
Você pode ver os arquivos que fazem parte do conteúdo de um arquivo WAR antes de implantá-lo. Para tanto, altere a extensão do arquivo de .war para .zip no seu gerenciador de arquivos e utilize a ferramenta de pastas compactadas do Windows para abri-lo (ou o comando unzip no Linux). 
Isso é possível, pois o tipo de compactação utilizada nos arquivos WAR é do tipo ZIP, que é amplamente utilizado nos mais diversos sistemas operacionais.
ENVIANDO UM ARQUIVO WAR PARA O SERVIDOR
Para realizar o envio de um arquivo WAR para o servidor são utilizadas ferramentas comuns de envio de arquivos pela rede, como as que usam o protocolo FTP, sigla de File Transfer Protocol, ou sFTP, que tem a mesma sigla, mas com a palavra security no início, sendo mais indicado por realizar o envio de modo seguro.
DICA
Existem diversos programas de FTP gratuitos, como por exemplo, o Filezilla para Windows. Recomendamos, no entanto, sempre o uso de programas para acesso seguro usando sFTP e, nesse caso, o WinSCP é uma boa escolha.
Essa necessidade de envio da publicação se dá por conta da arquitetura das aplicações web geralmente utilizar um servidor para disponibilizar as aplicações. Em nosso caso, utilizamos o Tomcat e então você deverá buscar onde está a pasta que acomoda as aplicações nesse servidor.
É possível ainda publicar sua aplicação enviando o arquivo WAR pelo navegador, acessando a página de administração do Tomcat, chamada Tomcat Web Application Manager, e fazendo o upload do arquivo. Essa página pode ser vista na Figura 4.
Figura 4. Captura de tela da página de administração do Tomcat.
Conforme pode ser visto na Figura 4, além da opção de envio de arquivos WAR, a página de administração do Tomcat permite:
· A exclusão da aplicação do servidor, processo esse chamado de undeploy;
· O início e a parada da oferta das aplicações pelo servidor;
· A releitura do arquivo da aplicação via botão reload;
· A expiração das sessões abertas de acordo com um período de inatividade configurável.
Após o envio do arquivo para teste da aplicação, basta acessar o servidor pelo seu endereço, com o complemento do nome da aplicação que estiver configurado no Deployment Descriptor, representado pelo arquivo web.xml. Vale ressaltar que em algumas versões e configurações do Tomcat é necessário reiniciá-lo para ter a nova versão de uma aplicação funcionando após o envio de um novo arquivo WAR.
O envio de uma nova versão da aplicação sem necessidade de reinício do Tomcat é chamado de Hot Deploy. No entanto, isso só é possível em ambientes Java 1.4.1, ou superiores, e em casos de novas versões de aplicações em que não foi alterada a estrutura de classes, ou seja, só foi alterado o código de corpos dos métodos das classes.
DICA
Existem ferramentas que automatizam o processo de publicação das aplicações, com envio e conferência do arquivo WAR para o servidor e ainda fazer o reinício do web contêiner, se necessário. Uma das possibilidades para fazer isso é utilizando Shell Script, que executa comandos em lote, ou com o software gratuito Apache Ant, disponível no endereço https://ant.apache.org/.
Servlet X JSP
Agora faremos uma comparação detalhada entre os Servlets e as páginas JSP para que você possa escolher qual tecnologia utilizar para implementação das funções desejadas em uma aplicação web.
Apesar da rápida e correta percepção de que as páginas JSP são mais simples de se usar, os conhecimentos sobre os Servlets não devem ser ignorados, já que eles são a base de toda a tecnologia Java para web.
Outro ponto para estudo dessas tecnologias é o fator de termos aplicações web que são compostas de Servlets e páginas JSP que convivem bem em conjunto, com comunicação eficiente e natural entre as tecnologias. Isso ocorre porque as páginas JSPs são transformadas em Servlets no momento da primeira execução no contêiner web (esses novos arquivos gerados podem ser encontrados nas pastas do servidor).
Geralmente, nos projetos em que existe um misto de tecnologias, as páginas JSP são utilizadas para criar os documentos de interface com o usuário e os Servlets são usados para tratar a lógica de controle da aplicação. Vale ressaltar que arquivos das duas tecnologias ficam em pastas diferentes na estrutura de arquivos da aplicação, promovendo uma boa organização e facilitando o entendimento do projeto pelos desenvolvedores.
Como diferença básica entre as duas tecnologias, podemos citar o menor código necessário quando trabalhamos com JSP, principalmente pela existência dos objetos implícitos. Além disso, o código de documentos HTML dinâmicos fica mais legível nos JSPs, pois os códigos Java ficam dentro do HTML que será formado e não o inverso, como é feito nos Servlets.
No Quadro 1, veremos os principais pontos comentados de diferença entre as tecnologias tratadas aqui.
Quadro 1. Resumo de principais diferenças entre Servlet e JSP.
A arquitetura MVC
A arquitetura Model View Controller, mais conhecida por sua sigla MVC – que significa Modelo Visão Controladora,em português –, estabelece um paradigma de organização clássico de aplicações, incluindo as aplicações web.
A ideia da arquitetura MVC surgiu em 1979 a partir do trabalho de seu criador, Trygve M. H. Reenskaug, que era um desenvolvedor da linguagem orientada a objetos Smalltalk na empresa Xerox PARC. Já os detalhes da implementação da arquitetura foram publicados pela primeira vez em 1992, no artigo "Applications Programming in Smalltalk-80: How to use Model-View-Controller", do pesquisador Steve Burbeck.
Reenskaug relata que a meta da arquitetura MVC é realizar uma sintonia maior entre o modelo mental humano e o modelo digital do computador, fazendo com que o usuário acredite estar visualizando e manipulando diretamente as informações do domínio. Como pode ser percebido na leitura do próprio nome da arquitetura, seu objetivo básico é separar os componentes da aplicação em três partes distintas (também chamadas de camadas), que são:
· Model (modelo): representa os dados modelados, gravando o conteúdo de objetos e incluindo suas restrições lógicas (de negócios, ou não). Faz a materialização das classes que trabalham para armazenamento e busca dos dados;
· View (visão ou apresentação): realiza a apresentação visual dos dados contidos no Model, mostrando o conteúdo armazenado ao usuário;
· Controller (controlador): interpreta as ações de entrada em um sistema, realiza processamentos e faz buscas e inserções de dados no modelo.
Existem diversas estruturas e recomendações prontas chamadas de frameworks Java para web que implementam o padrão MVC, facilitando sua adoção nos mais variados projetos. Entre eles, podemos citar o Java Server Faces (JSF), o Apache Struts e o Spring MVC.
CURIOSIDADE
O termo “modelo” talvez não tenha sido uma boa escolha, porque geralmente pensamos em um modelo como uma representação de um conceito abstrato. Projetistas de carros e aviões constroem modelos para simular carros e aviões. Mas essa analogia leva a um desvio ao pensar na arquitetura MVC para desenvolvimento de software. Nesse padrão de design, o modelo armazena o conteúdo completo (que não é abstrato, pois se refere aos dados reais armazenados).
Para o pleno funcionamento dessa arquitetura, o modelo notifica suas visões e controladores associados quando há alguma mudança em seu estado. Essas notificações permitem que os elementos da camada de visão produzam saídas atualizadas e que os controladores realizem novos processamentos com os dados alterados.
O fato de separar bem a lógica da aplicação assegura que a camada modelo não saiba nenhuma informação do que é exibido, pois seus dados ficam restritos a armazenar as partes dos componentes da aplicação. Por sua vez, a camada de apresentação só está relacionada a exibir os dados, sem se preocupar com a lógica de negócios e de onde provêm os dados. Por exemplo, os dados podem vir de outro servidor, via troca de arquivos do tipo XML, ou de um banco de dados.  
Apesar de essa arquitetura ter surgido na época do desenvolvimento para desktops, com interfaces voltadas para interfaces de textos e janelas simples, ela se mostra eficiente para as aplicações web, sendo bastante utilizada na atualidade.
A ARQUITETURA MVC NO DESENVOLVIMENTO EM JAVA PARA WEB
Autores reconhecidos na literatura, como Kurniawan (2002), sugerem a utilização da arquitetura MVC para o desenvolvimento em Java para web com a especificação de como devem ficar os elementos Java nesse contexto. O conceito básico é o de separar o conteúdo de geração do conteúdo de apresentação.
O conceito base para o MVC nas aplicações web é que o controlador recebe uma requisição GET ou POST, após uma interação do usuário em seu navegador e decide como processá-la, chamando objetos para tratar a lógica de negócio. Por fim, é feita a invocação de um elemento da camada de visão para apresentar a saída como resposta no protocolo HTTP.
De modo mais detalhado e genérico, a divisão em camadas em um projeto Java para web usando MVC fica descrita da seguinte forma:
· Model: classes de lógica de negócio, que podem ser componentes do tipo Java Beans;
· View: páginas HTML, JSP e seus componentes (como formulários, imagens, vídeos, etc);
· Controller: elemento que recebe as requisições HTTP chama algum método de negócio e, dependendo do retorno, escolhe uma página como view para a resposta.
A partir dessa divisão, com uso da arquitetura MVC, são propostos dois modelos para o desenvolvimento de aplicações em Java para web:
· O modelo 1: mais simples e comum que é chamado de page-centric ou centralizado em páginas JSP;
· O modelo 2: para aplicações maiores e mais complexas.
No Diagrama 1 tem-se o modelo de arquitetura 1, na qual o usuário, por meio de seu navegador, faz solicitações a um conjunto de páginas JSPs (representando a camada de visão) que interagem com componentes do tipo JavaBeans, que agregam a lógica de negócio (representando a camada de controle) para posterior consulta às bases de dados (representando a camada de modelo).  
Diagrama 1. Arquitetura MVC aplicada no desenvolvimento Java para Web.
No tipo de arquitetura visto no Diagrama 1, cada página JSP processa a sua própria entrada e, se necessário, um Servlet ou uma página HTML podem ser utilizados no caminho de páginas percorrido pelo usuário em sua interação.
JavaBeans é um padrão de componentes simples reutilizáveis que encapsulam informações necessárias a serem transportadas ao longo das camadas ou módulos. Um componente JavaBean é uma classe Java que possui propriedades que descrevem algo, seguindo uma convenção de nomenclatura simples para os métodos getter e setter. Sua utilização foi proposta aqui para padronizar e facilitar a comunicação com os JSPs e dos componentes com as bases de dados.
Vejamos agora um exemplo simples de um código de classe JavaBean para uma pessoa: 
Código fonte 2. Exemplo de um código de classe JavaBean:
1.    public class Pessoa{
2. private String nome;
3. private int idade;
4. public Pessoa(){
5. }
6. public String getNome(){
7. return nome;
8. }
9. public void setNome(String nome){
10. this.nome = nome;
11. }
12. public int getIdade(){
13. return idade;
14. }
15. public void setIdade(int idade){
16. this.idade = idade;
17. }
18. }
Em relação ao Código fonte 2, tem-se a declaração normal da classe na linha 1 sem diferenciação por ser um componente JavaBean. Nas linhas de 2 a 3, temos a declaração das propriedades da classe, que nesse caso são o nome do tipo String e a idade do tipo inteiro. Para cada propriedade é necessário ter respectivos métodos get e set (esses nomes não podem ser alterados) e isso é feito nas linhas de 6 a 17.
A principal vantagem do uso do modelo 1 é a facilidade de desenvolvimento, porém ela é uma arquitetura que não divide bem o trabalho de design da página com as lógicas de negócio dos controladores. Além disso, ela é difícil de estender, não sendo recomendada para projetos de grandes aplicações.
Já a arquitetura do modelo 2 aplica o conceito MVC de uma maneira melhor, com separações evidentes, tendo de modo explícito a presença de um Servlet controlador entre o navegador do cliente e as páginas JSP ou conteúdo Servlet que gera o conteúdo desejado.
No Diagrama 2 é possível ver em detalhes a arquitetura do modelo 2 conforme descrita por Kurniawan. 
Diagrama 2. Arquitetura MVC aplicada no desenvolvimento Java para web. Fonte: KURNIAWAN, 2012. (Adaptado).
O Servlet controlador tem por função receber e despachar solicitações HTTP às páginas JSP de apresentação correspondentes com base na solicitação de URL e parâmetros de requisição de entrada. Nesse modelo sugerido, as partes de apresentação são isoladas uma das outras, aplicando bem o conceito da arquitetura MVC. Esse tipo de arquitetura é, então, flexível e fácil de manter e estender.
O Servlet controlador tem a vantagem de centralizar funções de gerenciamento das requisições e da navegação do usuário, oferecendo um único ponto de controle para segurança e registro, incluindo o recebimento de dados de formulário, que podem ser devidamente tratados de acordo comas necessidades da aplicação.
BENEFÍCIOS DA ARQUITETURA MVC
O principal benefício da arquitetura MVC é proporcionar uma organização padrão para a estrutura do código com separação de objetos, angariando melhor entendimento e leitura do mesmo pela equipe, que pode mais facilmente compreender, manter e estender projetos  que, na prática, tendem a conter centenas a milhares de arquivos.
Como exemplo disso, imagine que um cliente reclamou de um texto com grafia errada em uma aplicação web. Se a mesma tiver sido feita utilizando a arquitetura MVC, os desenvolvedores, por mais inexperientes que forem em um projeto, vão saber que a correção do erro deve estar em algum arquivo da camada de visão.
Do mesmo modo, se o erro estiver em algum cálculo em regras de negócio da aplicação a alteração deverá ser feita na camada de controle.
É relevante mencionar ainda que as aplicações web precisam passar por renovação estética frequente por necessidades comerciais naturais do mundo moderno em que a concorrência é alta e os requisitos de usabilidade mudam muito. Nesse ponto, a utilização da arquitetura MVC é significativamente útil, pois permite a alteração mais fácil da parte de apresentação, por essa estar separada na camada View. Esse cenário certamente ocorreu em muitas empresas que precisaram alterar suas interfaces para bom funcionamento em dispositivos móveis, como smartphones, tendo a facilidade de alteração desse design na camada View com pouca ou nenhuma mudança nos controles e modelos.
A não utilização da arquitetura MVC nos dias de hoje pode ser vista em projetos que começaram sem planejamento e que carregam uma grande mistura de código HTML com código de servidor em uma mesma página. Essa prática, apesar de funcionar, dificulta muito o crescimento da aplicação.
O PADRÃO DATA ACCESS OBJECT (DAO)
O padrão Data Access Object (DAO), ou objeto de acesso a dados, é uma estrutura comum de interfaces independentes para consultas e persistências de informações em uma base de dados. Esse padrão é frequentemente utilizado em arquiteturas MVC por possibilitar a separação do acesso aos dados de modo adequado.
Podemos dizer, então, que o DAO esconde ou abstrai detalhes das fontes de dados, facilitando manutenções e futuras trocas de sistemas gerenciadores de bancos de dados. Para esse troca, basta implementar um novo DAO com a mesma interface e realizar a substituição o antigo por esse.
Tecnicamente falando, a classe DAO é a responsável pela conexão e pelas consultas no banco de dados para alimentar os dados dos objetos. Por exemplo, considere uma classe Pessoa que tem apenas código identificador, nome e telefone como atributos. A classe PessoaDAO será responsável por realizar todas as operações com banco de dados para popular (preencher) os dados dos objetos da classe Pessoa.
Numa classe DAO, geralmente encontramos os métodos com as seguintes funções de persistência:
· Alteração de um registro;
· Exclusão de um registro;
· Verificação da existência de algum código identificador;
· Buscas em geral;
· Inserção de um registro;
· Listagem de dos registros existentes;
· Consulta de um registro identificado com seu identificador.
Com o uso de classes DAO os códigos de consulta ao banco, comumente do tipo SQL, ficarão todos centralizados nesse tipo de classe, deixando as classes restantes mais limpas e legíveis. Isso ocorre porque em aplicações reais alguns códigos SQL podem ter dezenas de linhas de código e seu reuso é importante e favorecido com uso de classes DAO.
Request Dispatcher
A Request Dispatcher é uma importante interface do pacote javax.Servlet da Servlet API que tem a função de definir um objeto que despacha uma solicitação da requisição atual para outro recurso dinâmico, que pode ser um Servlet ou uma página JSP, por exemplo.
Sua utilização é útil para modularização da aplicação, com a separação de código, pois elementos de uma determinada requisição podem ser enviados para um módulo com código específico para o processamento necessário.
Podemos fazer uma analogia de sua utilização com o seguinte cenário metafórico de um jogo de futebol: “já fiz algo e agora vou passar a bola para outro jogador”.
A interface Request Dispatcher possui apenas dois métodos, que são:
· Void forward (ServletRequest request, ServletResponse response): o Servlet processa uma requisição parcialmente e encaminha dados para outro Servlet gerar a resposta final. Se for chamado depois que a resposta estiver sido enviada, será lançada a exceção IllegalStateException.
· Void include (ServletRequest request, ServletResponse response): chama outro recurso para processamento e, em seguida, volta para o Servlet inicial que chamou o método. O recurso que foi incluído não pode enviar cabeçalhos HTTP e códigos de status para a resposta.
Voltando à nossa metáfora, o método forward funciona como se o jogador passasse a bola para outro terminar a jogada e o método include se diferencia desse, pois a bola volta no jogador inicial que tem a responsabilidade de terminar a jogada.
O funcionamento do método forward, com as suas etapas marcadas em ordem sequencial, pode ser visto no Diagrama 3.  
Diagrama 3. Funcionamento do método forward.
De acordo com o Diagrama 3, na etapa 1 o navegador envia uma requisição ao servidor na página “a.jsp” que faz o encaminhamento dos dados na etapa 2 para a página “b.jsp”, que retorna a resposta contendo o documento HTML ao navegador na última etapa, que é a 3.
Cabe ressaltar que, apesar de a última página processada ter sido a “b.jsp”, o navegador continuará na página “a.jsp”.
Já o funcionamento do método include pode ser visto no Diagrama 4.
Diagrama 4. Funcionamento do método include.
Após o envio da requisição na etapa 1, a página “a.jsp” faz inclusão da página “b.jsp” na etapa 2, que então é devidamente processada no servidor e devolve, de modo automático, o controle sobre a requisição para a página “b.jsp” na etapa 3, que envia a resposta para o navegador na última etapa, que é a 4.
Na sequência, veremos com detalhes a parte de código dos métodos de obtenção, de inclusão e de encaminhamento da Request Dispatcher.
OBTENÇÃO DA REQUEST DISPATCHER
Para utilizar a Request Dispatcher, é preciso obtê-la a partir dos objetos javax.Servlet.ServletContext e javax.Servlet.ServletRequest, pelo método getRequestDispatcher(String path), onde path é o caminho a ser utilizado pelo Servlet.
Existe uma pequena diferença em cada uso: no ServletContext não é possível utilizar o caminho relativo, o caminho deve então iniciar com o caractere “/” (barra).
Já no ServletRequest, é possível o uso de caminhos relativos, como por exemplo ServletRequest.getRequestDispatcher(“../sobre/index.jsp”).
MÉTODO DE INCLUSÃO (INCLUDE)
Vejamos um exemplo de código que usa o método de inclusão da interface Request Dispatcher:
1. RequestDispatcher rD = request.getRequestDispatcher("exemplo.jsp");
2. rD.include(request, response);
Muitos desenvolvedores preferem aplicar o código anterior em sua forma resumida de uma linha, ficando do seguinte modo o trecho em Java:
1. request.getRequestDispatcher("exemplo.jsp").include(request, response);
É importante ressaltar que o método include do Request Dispatcher é chamado sempre antes da página principal, independentemente do número da linha em que ele for inserido.
Outra opção para incluir arquivos em uma página JSP é a utilização de uma marcação própria de inclusão com código como mostrado a seguir:
1. <jsp:include page="exemplo.jsp" />
Mas nesse caso, ao contrário do include da Request Dispatcher, o conteúdo JSP incluso não afeta o ambiente das páginas principais, tendo escopos diferentes e totalmente separados. Assim, somente a saída da página JSP incluída é utilizada. E também a inclusão é feita no exato local onde ocorre a chamada.
Assim, essa segunda forma de inclusão tem uso mais intuitivo e prático para o desenvolvedor do que se compararmos ao uso da Request Dispatcher. Com ela, por exemplo, é possível incluir um rodapé padrão, pois ele só pode ser inserido no final da página.
Nesta última opção deinclusão de páginas ainda é possível passar parâmetros que podem ser lidos na página inclusa, como pode ser visto no código:
1. <jsp:include page="exemplo.jsp" />
2.     <jsp:param name="parametro1" value="valor1" />
3.     <jsp:param name="parametro2" value="valor2" />
4. </jsp:include>
Conforme pode ser visto, foram passados para a página que será incluída chamada exemplo.jsp dois parâmetros. Tais parâmetros são o parametro1 (de valor1) e o parametro2 (de valor2).
MÉTODO DE ENCAMINHAMENTO (FORWARD)
Um exemplo de código que usa o método de encaminhamento de requisição pode ser visto a seguir:
1. RequestDispatcher rD = request.getRequestDispatcher("exemplo.jsp");
2. rD.forward(request, response);
Assim como no caso do método de inclusão, é possível aplicar o código anterior em sua forma resumida de uma linha:
1. request.getRequestDispatcher("exemplo.jsp").forward(request, response);
Com esse código, toda a requisição é transferida para a página passada como parâmetro, que em nosso caso é a “exemplo.jsp”. Ela fica responsável por retornar a resposta ao servidor web que a encaminhará ao navegador do usuário. Outra opção para fazer o encaminhamento de arquivos em uma página JSP é a utilização de uma marcação própria com o código:
1. <jsp:forward page="exemplo.jsp" />
Você pode estar achando semelhante ao recurso de encaminhar dados, via forward, do Request Dispatcher com o redirecionamento do objeto resposta, que é chamado pelo código response.sendRedirect.
Ambos chamam outro recurso, porém existem significativas diferenças: o sendRedirect muda a URL no navegador, redirecionando para um novo endereço, descartando dados da requisição. Já o forward mantém os dados da requisição e a mesma URL no navegador.
Outra diferença é que como o Request Dispatcher é um recurso de transferência de requisições para caminhos que ficam dentro do mesmo servidor, não é possível especificar um destino fora da sua aplicação.
Por exemplo, você não pode utilizar o método assim:
1. request.getRequestDispatcher("http://www.outrosite.com.br").forward(request, response);
Caso o seu desejo seja o de apenas realizar um redirecionamento, sem repassar os dados da requisição, aí é possível fazer a operação via utilização do método sendRedirect, desse modo:
1. response.sendRedirect("http://www.outrosite.com.br");
É importante ressaltar que qualquer outro comando de saída de dados com o uso do objeto implícito out que estiver após o método forward serão ignorados, pois o contêiner web irá passar o controle total de saída de dados para o novo Servlet.
Outro método que pode ser utilizado para o redirecionamento de páginas funciona a partir da utilização de comandos JavaScript. Esse tipo de redirecionamento é feito do lado do cliente e tem os problemas de poder ser desativado no navegador do usuário e, ainda, de incompatibilidade de código entre navegadores.
Ou seja, sempre que possível, prefira a utilização de métodos de redirecionamento feitos no lado do servidor. Para utilização desse método usando JavaScript, um código possível é: window.location.href = “http://www.outrosite.com.br”.
ADICIONANDO ATRIBUTOS
Antes de realizar a inclusão de um código ou o encaminhamento da requisição é possível acrescentar dados no ambiente de programação para requisição. Isso pode ser feito com o seguinte trecho de código:
1. request.setAttribute("nomeExemplo", objetoExemplo);
O nome do atributo é uma String definida pelo desenvolvedor no primeiro parâmetro do método setAttribute para identificar o atributo. Já o valor do atributo deve ir ao segundo parâmetro e pode ser qualquer objeto que se deseja adicionar na requisição.
Os dados que foram adicionados do objeto na requisição podem ser recuperados na página de destino de processamento, do seguinte modo:
1. request.getAttribute("nomeExemplo");
Percebe-se, a partir desses códigos apresentados, que o uso de atributos incorporados na requisição é uma forma de passar dados de uma página à outra no caso de redirecionamentos e inclusões feitos usando Request Dispatcher.
Agora é a hora de sintetizar tudo o que aprendemos nessa unidade. Vamos lá?!
SINTETIZANDO
Esta unidade começou com a apresentação do modo clássico em que pode ocorrer conexão das classes Java com os sistemas gerenciadores de bancos de dados. Isso permitiu e ainda vem permitindo uma evolução constante do uso da web no cotidiano das pessoas que utilizam navegadores para uma infinidade de serviços conectados aos bancos de dados.
Em seguida, foi abordado o conceito de arquivos do tipo WAR, responsáveis por empacotar e facilitar, a distribuição e implantação das aplicações. Foi detalhado como criar esse tipo de arquivos no Eclipse e em linha de comando e como usá-los de modo adequado no Tomcat. No entanto, por ser um padrão da tecnologia Java EE, seu uso pode ser feito com facilidade nos mais diversos contêineres Web.
De modo técnico e factual, foram apresentadas as diferenças básicas entre Servlet e JSP, permitindo que o aluno possa escolher qual delas trabalhar e em que ponto usar cada uma, no caso de usar um misto de tecnologias em seu projeto.
Também vimos detalhadamente o padrão de arquitetura MVC que é amplamente utilizado nos mais variados projetos de software. Foi visto as camadas dessa arquitetura e a interação entre seus elementos. As vantagens de adoção desse padrão compensam seu entendimento e o tempo gasto pela equipe na adequação do projeto, favorecendo a manutenção e entendimento do projeto (de modo lógico e estrutural), mesmo que este aumente em versões futuras da aplicação.
A unidade foi encerrada com a interface Request Dispatcher, com seus métodos de inclusão e de encaminhamento que são importantes para transferir dados do ambiente para processamento em módulos distintos, separando bem a parte lógica processual das aplicações.
Esta é última unidade da disciplina “Desenvolvimento de aplicações para Internet”. Temos consciência de que apresentamos um rol de conhecimentos que são a base para que o aluno possa criar adequadas aplicações Java para Web com eficiência e usabilidade, atendendo à demanda crescente do mercado por esse tipo de aplicações.