Padrões de Projeto

JEE
Camada de Apresentação
Camada de Negócios
Camada de Integração

----------------------------------------------------------------------------------------------------

Desenvolvimento de Sistemas I
 Introdução

• A camada de apresentação encapsula toda a lógica

relacionada com a visualização e comunicação com a
interface do usuário
• Requisições e respostas HTTP
• Gerenciamento de sessão HTTP
• Geração de HTML, JavaScript e recursos lado-cliente
• Principais componentes: Servlets e JSP
• JSP é indicado para produzir interface do usuário
• Servlets são indicados para processar dados recebidos e
concentrar lógica de controle

2
 Práticas não recomendadas
• Enquanto os padrões promovem as melhores soluções,
as práticas não recomendadas indicam necessidade de
aplicação dos padrões
• Código de controle em vários Views
• Exposição de estruturas da camada de apresentação a outras
camadas e objetos de domínio
• Permissão para requisições de formulário duplicadas
• Permissão de acesso do cliente a recursos sensíveis
• Permissão de inconsistência de propriedades <jsp:property>
• Controladores gordos
• Vários padrões e refactorings sugerem soluções que
resolvem os problemas acima*

* Veja Presentation Tier Bad Practices e Refactorings em [Core] 3

 1

Front Controller

Objetivo: centralizar o processamento de requisições em

uma única fachada. Front Controller permite criar uma
interface genérica para processamento de comandos.
 Problema
View
Código de
Controle

Cliente View
Acesso livre a
qualquer View

View

Código de
Formatação

Camada de Apresentação
6
 Descrição do problema
• Deseja-se um ponto de acesso centralizado para
processamento de todas as requisições recebidas pela
camada de apresentação para
• Controlar a navegação entre os Views
• Remover duplicação de código
• Estabelecer responsabilidades mais definidas para cada
objeto, facilitando manutenção e extensão: JSP não deve
conter código algum ou pelo menos não código de controle
• Se um usuário acessa um View sem passar por um
mecanismo centralizado, código de controle é
duplicado e misturado ao código de apresentação
• Também não é possível controlar a navegação: cliente pode
iniciar em página que não deveria ter acesso.
7
 Solução: Front Controller
Command
Controller Helper
View
Cliente

Acesso restrito:
Controller determina
nível de acesso

Command Command View

Helper Helper

Command
Helper View
Código de
Formatação

Código de
Controle
Camada de Apresentação
8
 Descrição da solução
• Controlador é ponto de acesso para processamento
de requisições
• chama serviços de segurança (autenticação e autorização)
• delega processamento à camadas de negócio
• define um View apropriado
• realiza tratamento de erros
• define estratégias de geração de conteúdo
• O controlador pode delegar processamento a objetos
Helper (Comandos, Value Beans, etc.)
• Solução depende do uso de um Dispatcher
• Usado para redirecionar para o View correspondente

9
Estrutura UML

Fonte: [SJC] 10
 Diagrama de Seqüência

1.1 RequestDispatcher rd = request.getRequestDispatcher("View.jsp");

1.1.1 rd.forward(request, response);

Fonte: [SJC] 11
 Participantes e responsabilidades
• Controller
• Ponto de entrada que centraliza todas as requisições
• Pode delegar responsabilidade a Helpers
• Dispatcher
• Tipicamente usa ou encapsula objeto
javax.servlet.RequestDispatcher
• Helper
• Pode ter inúmeras responsabilidades, incluindo a obtenção
de dados requerido pelo View
• Pode ser um Value Bean, Business Delegate, Command, ...
• View
• Geralmente página JSP

12
 Melhores estratégias de
implementação*
• Servlet Front Strategy
• Implementa o controlador como um servlet. Exemplo 7.14
• Dispatcher and Controller Strategy implementa o
Dispatcher dentro do próprio servlet
• Command and Controller Strategy
• Interface baseada no padrão Command (GoF) para
implementar Helpers para os quais o controlador delega
responsabilidades. Exemplo 7.16
• Logical Resource Mapping Strategy
• Requisições são feitas para nomes que são mapeados a
recursos (páginas JSP, servlets) ou comandos
• Multiplexed Resource Mapping Strategy usa wildcards
para selecionar recursos a serem processados
* Veja exemplos de código em exemplos/preslayer/ 13
Command and Controller Strategy

Fonte: [Core] 14
 Conseqüências

• Controle centralizado
• Facilidade de rastrear e logar requisições
• Melhor gerenciamento de segurança
• Requer menos recursos. Não é preciso distribuir
pontos de verificação em todas as páginas
• Validação é simplificada
• Melhor possibilidade de reuso
• Distribui melhor as responsabilidades

15
 Como implementar?

ƒ Há várias estratégias
ƒ Todas procuram isolar
ƒ As operações de controle de requisições em servlets e
classes ajudantes,
ƒ Operações de geração de páginas em JSP e JavaBeans, e
ƒ Lógica das aplicações em classes que não usam os pacotes
javax.servlet
ƒ Uma estratégia consiste em se ter um único
controlador (FrontController pattern) que delega
requisições a diferentes objetos que implementam
comandos que o sistema executa (Command pattern)

6
 Command Pattern
ƒ É um padrão de projeto clássico catalogado no livro "Design
Patterns" de Gamma et al (GoF = Gang of Four)
ƒ Para que serve: "Encapsular uma requisição como um objeto, permitindo
que clientes parametrizem diferentes requisições, filas ou requisições de log,
e suportar operações reversíveis." [GoF]
ƒ Consiste em usar polimorfismo para construir objetos que
encapsulam um comando e oferecer um único método
execute() com a implementação do comando a ser executado
Command
execute(): Object

ComandoInserir ComandoRemover ComandoListar

execute(): Object execute(): Object execute(): Object

7
 Command Pattern
Command
execute(): Object

new NovoSocioCommand

edit EditarCommand

del RemoverCommand

get MostrarSocioCommand

all all ListarTodosCommand

Cliente
Servlet

Command c = getCommand("all");

service() {
...
Object result = c.execute();
...
}

8
 Command em Java

public interface Command { public interface NewCommand implements Command {

public Object execute(Object arg);
} public NewCommand(Database db) {
this.db = db;
}
public class Server {
private Database db = ...; public Object execute(Object arg) {
private HashMap cmds = new HashMap(); Data d = (Data)arg;
int id = d.getArg(0);
public Server() { String nome = d.getArg(1);
initCommands(); db.insert(new Member(id, nome));
} }
}
private void initCommands() {
cmds.put("new", new NewCommand(db));
cmds.put("del",
new DeleteCommand(db));
... public class DeleteCommand implements Command {
}
public DeleteCommand(Database db) {
public void service(String cmd, this.db = db;
Object data) { }
...
Command c = (Command)cmds.get(cmd); public Object execute(Object arg) {
... Data d = (Data)arg;
Object result = c.execute(data); int id = d.getArg(0);
... db.delete(id);
} }
} } 9
 FrontController com Command Pattern
ƒ Os comandos são instanciados e guardados em uma base de
dados na memória (HashMap, por exemplo)
ƒ Pode-se criar uma classe específica para ser fábrica de comandos
ƒ O cliente que usa o comando (o servlet), recebe na
requisição o nome do comando, consulta-o no HashMap,
obtém a instância do objeto e chama seu método execute()
ƒ O cliente desconhece a classe concreta do comando. Sabe apenas a
sua interface (que usa para fazer o cast ao obtê-lo do HashMap
ƒ No HashMap
Comando c = new ComandoInserir();
comandosMap.put("inserir", c);
ƒ No servlet:
String cmd = request.getParameter("cmd");
Comando c = (Comando)comandosMap.get(cmd);
c.execute();
10
 Exemplo de implementação
cap12/mvc/hellojsp_2

getCommand(cmd)
cmd consulta
ControlServlet CommandFactory mapping.xml
cria
executa Command

despacha DefaultCommand
Model
NewMessageCommand
index.html View
ShowLastMessageCommand
Controller
ShowMessagesCommand
inclui usa
messages.jsp
cria grava / recupera

inclui usa MessageBean MessageBeanDAO

lastMessage.jsp preenche

taglib

PrintMessagesTag
navbar.html JAXB (XML)
PrintFieldTag ou BD
11