Questão 441349

• Banca: FCC
• Órgão: TRE-AP
• Ano: 2011
• Provas: FCC - 2011 - TRE-AP - Analista Judiciário - Análise de Sistemas
• Disciplina: Arquitetura de Software
• Assuntos: Padrões de projeto (Design Patterns)

Padrão que encapsula a lógica de apresentação de dados de negócios dinâmicos ou, ainda, especifica que são usa- dos ajudantes para adaptar os dados do modelo para a camada de apresentação da aplicação. Trata-se de

• A. view helper.
• B. dispatcher view.
• C. business delegate.
• D. data access object.
• E. front controller.

Gabarito: A

Comentários

• View Helper
  
  São classes auxiliares que tem como objetivo simplificar o código. Ou seja, auxiliam a camada de visão, no caso as VIEWS.
  É uma classe que faz a recuperação de dados para a exibição. O seu padrão desacopla classes de negócio de uma outra aplicação permitindo assim variar em suas próprias taxas. A dissociação também promove a reutilização, porque cada componente de negócio ou apresentação tem menos dependências. Assim, a VIEW pode se concentrar na formatação e lógica de apresentação, e deixar que o View Helper lidar com o processamento e recuperação de dados.
  No código podem ser chamadas como uma função direta e podem receber parâmetros.
  En síntese, é um padrão que encapsula a lógica de apresentação de dados de negócios dinâmicos ou, ainda, especifica quais são os agentes que serão usados como ajudantes para adaptar os dados do modelo para a camada de apresentação da aplicação.
  
  
  
  
  
•     a) view helper. Separa a camada de visão da lógica de apresentação.
  
      b) dispatcher view. Lida com pedidos e gera respostas, com um mínimo de lógica do negócio.
  
      c) business delegate. Esconde do cliente a comunicação com os componentes de serviço.
  
      d) data access object. Dados são manipulados e tratados em camadas separadas.
  
      e) front controller. Ponto de acesso central para a camada de apresentação.

• View Helper
  Objetivo: separar código e responsabilidades de formatação da interface do usuário do processamento de dados necessários à construção da View.
  Descrição do Problema
  - Mudanças na camada de apresentação são comuns
  - Alterações da interface do usuário
  - Se código de apresentação (HTML, JavaScript) estiver misturado com código de processamento e controle (Java) as mudanças são dificultadas
  - Menos flexibilidade, menos reuso, menos modularidade e mistura de papéis em um mesmo componente
  - É preciso identificar as responsabilidades de cada trecho de código e encapsulá-lo em objetos usados pela camada de apresentação
  Descrição da Solucação
  - O padrão View Helper recomenda soluções para dividir as responsabilidades do View
  - Uma View contém código relacionado apenas à formatação
  - Responsabilidades de processamento são delegados à classes ajudantes: View Helpers (implementadas como JavaBeans ou como Custom Tags)
  - Helpers também podem guardar modelo de dados intermediário usado pelo View e servir como adaptadores para dados oriundos da camada de negócios
  - Refatoramento pode sugerir separação de determinados trechos de código em objetos Controladores em vez de View Helpers
  - Há várias estratégias para implementação de Views em associação com View Helpers