Tecnologias Web. Padrões de Projeto - Camada de Apresentação

Tamanho: px

Começar a partir da página:

Download "Tecnologias Web. Padrões de Projeto - Camada de Apresentação"

Cacilda Regueira Taveira
8 Há anos
Visualizações:

1 Tecnologias Web Padrões de Projeto - Camada de Apresentação Cristiano Lehrer, M.Sc.

2 Padrões da Camada de Apresentação (1/2) Intercepting Filter Viabiliza pré e pós processamento de requisições. Front Controller Oferece um controlador centralizado para gerenciar o processamento de uma requisição. Context Object Encapsula estado de forma independente de protocolo para compartilhamento pela aplicação. Application Controller Centraliza e modulariza gerenciamento de s e de ações.

Front Controller Oferece um controlador centralizado para gerenciar o processamento de uma

3 Padrões da Camada de Apresentação (2/2) Helper Encapsula lógica não-relacionada à formatação. Composite Cria uma composta de componentes menores. Service To Worker e Dispatcher Combinam Front Controller com um Dispatcher e Helpers. O primeiro concentra mais tarefas antes de despachar a requisições. O segundo realiza mais processamento depois.

Service To Worker e Dispatcher Combinam Front Controller com um Dispatcher e Helpers.

4 Front Controller (1/6) Objetivo: Centralizar o processamento de requisições em uma única fachada. Front Controller permite criar uma interface genérica para processamento de comandos.

5 Front Controller (2/6) Problema: Código de Controle Código de Formatação Cliente Acesso livre a qualquer Camada de Apresentação

6 Front Controller (3/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 s. 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 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.

Estabelecer responsabilidades mais definidas para cada objeto, facilitando manutenção e extensão.

7 Front Controller (4/6) Solução: Command Helper Código de Controle Código de Formatação Controller Cliente Acesso restrito: Controller determina nível de acesso Command Helper Camada de Apresentação

8 Front Controller (5/6) 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 apropriado. Realiza tratamento de erros. Define estratégias de geração de conteúdo. O controlador pode delegar processamento a objetos Helper (comandos ou ações, Value Beans, entre outros). Solução depende do uso de um Application Controller: Usado para redirecionar para o correspondente.

Realiza tratamento de erros. Define estratégias de geração de conteúdo.

9 Front Controller (6/6) Consequê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.

Melhor gerenciamento de segurança: Requer menos recursos.

10 Application Controller (1/7) Objetivo: Centralizar operações relacionadas com processamento e despacho de requisições, tais como redirecionamento para comandos (ações) e views para permitir o reuso do Front Controller.

requisições, tais como redirecionamento para comandos

11 Application Controller (2/7) Problema: Ação Código de Controle Código de Formatação Controller Cliente Controlador central realiza tarefas diversas e diferentes Ação Camada de Apresentação

12 Application Controller (3/7) Problema: Contexto 1 Controller Cliente Controladores similares, que poderiam ser reutilizados, são rescritos para cada aplicação desenvolvida Contexto 2 Controller

13 Application Controller (4/7) Descrição do problema: Front Controller tem que lidar com código de aplicações diferentes, ou cada aplicação tem o seu Front Controller que faz basicamente a mesma coisa, com pequenas diferenças. Desejamos centralizar e reutilizar operações padrão de requisição e resposta para todas as aplicações e reutilizar código de repasse para ações e views. Desejamos melhorar a modularidade do código, a manutenabilidade, entre outras características, facilitando a extensão da aplicação e o reuso do código de manuseio de requisições de forma independente do container.

Desejamos centralizar e reutilizar operações padrão de requisição e resposta para todas as aplicações e reutilizar código de repasse para ações e

14 Application Controller (5/7) Solução: Contexto 1 Application Controller Cliente Front Controller Genérico Contexto 2 Application Controller Camada de Apresentação

15 Application Controller (6/7) Descrição da solução: Um Application Controller centraliza as operações específicas de recuperação e chamada de componentes que processam requisições, para cada aplicação. Permite que se use um Front Controller genérico que seja mapeado a diferentes Application Controllers, por exemplo, um por aplicação.

processam requisições, para cada aplicação.

16 Application Controller (7/7) Consequências: Melhora a modularidade: Facilita a separação da aplicação em diferentes módulos, que podem ser configurados separadamente e reutilizados. Melhora o reuso: Permite que o Front Controller seja compartilhado entre aplicações. Melhora a extensibilidade: Permite incluir novos serviços ou aplicações sem alterar a estrutura geral da aplicação web.

Melhora o reuso: Permite que o Front Controller seja compartilhado entre aplicações.

17 Composite (1/6) Objetivo: Criar um componente de a partir de s menores para dividir as responsabilidades, simplificar a construção da interface e permitir o reuso de componentes da.

18 Composite (2/6) Problema: Camada de Apresentação

19 Composite (3/6) Descrição do problema: Páginas web sofisticadas dividem seu conteúdo em várias partes, que tem função e tempo de vida diferentes: Podem ser manipuladas por pessoas diferentes já que cada seção tem finalidade, escopo e duração diferentes. Se a página for gerada a partir de uma única que concentra todo o código, a atualização da página é dificultada: É difícil identificar cada parte dentro de um documento. Há risco, quando se atualiza uma seção, de se invadir outra seção e afetar os dados.

Se a página for gerada a partir de uma única que concentra todo o código, a atualização da página é dificultada: É difícil

20 Composite (4/6) Solução: Composite Composite Camada de Apresentação

21 Composite (5/6) Descrição da solução: Usar views que consistem de composições de views menores: Os componentes do template podem ser incluídos dinamicamente e gerenciados separadamente. O layout geral da página pode ser manipulado independente do conteúdo. Componentes podem conter views ou coleções de views.

22 Composite (6/6) Consequências: Promove um projeto modular: Permite maior reuso e reduz a duplicação de código. Melhora a flexibilidade: Suporta inclusão de dados com base em decisões de tempo de execução. Melhora a facilidade de manutenção e gerenciamento: Separação da página em pedaços menores permite que sejam modificados e mantidos separadamente. Reduz a facilidade de gerenciamento: Possibilidade de erros na apresentação devido à composição incorreta das partes. Impacto no desempenho: Inclusões dinâmicas fazem a página demorar mais para ser processada.

Documentos relacionados

J550 Padrões de Projeto J2EE para Aplicações Web

J550 Padrões de Projeto J2EE para Aplicações Web Helder da Rocha (helder@acm.org) www.argonavis.com.br 1 Introdução Este módulo aborda os principais padrões de projeto J2EE, dentre o catálogo organizado