Prova 3 · Web, Distribuição, Sessão e Padrões Base
Cap. 4, 6, 7, 14, 15, 17 e 18: MVC e controladores, visões, distribuição, estado de sessão e padrões básicos
Objetivas
0/20 respondidas1.
Um portal tem 400 páginas, autenticação e log em todas, e precisa de um novo tema visual por cliente (white label). Qual combinação é mais adequada?
2.
Um objeto
Pedido tem método renderizarHtml(). Qual princípio foi violado e qual é a consequência prática?3.
Em um fluxo de abertura de sinistro, a próxima tela depende do tipo de seguro e das respostas anteriores, e o mesmo fluxo será usado na web e em um app. Onde concentrar essa lógica?
4.
Qual a diferença essencial entre Template View e Transform View?
5.
Um arquiteto quer separar
Cliente, Pedido e Estoque em processos distintos 'para escalar'. Qual a crítica e a alternativa de Fowler?6.
Um app móvel faz 12 chamadas remotas para montar a tela de pedido. Qual combinação reduz para uma chamada, mantendo o domínio fino e OO?
7.
Qual responsabilidade não pertence a um Remote Facade?
8.
Um sistema roda em cluster sem afinidade, precisa sobreviver à queda de nós e tem sessões com carrinhos grandes. Qual estado de sessão e qual cuidado principal?
9.
Um campo oculto guarda
desconto=10. Um usuário altera para 90 no navegador e consegue a compra. Qual padrão foi usado e qual cuidado faltou?10.
Por que objetos de servidor sem estado são valiosos, segundo o cap. 6?
11.
O domínio precisa de um serviço de cotação de frete externo, lento e pago. Qual combinação permite testes rápidos sem o serviço real?
12.
O código tem
if (cliente == null) em 60 pontos, cada um com o mesmo comportamento padrão. Qual padrão base resolve?13.
Uma conta de R$ 100,00 é rateada entre 3 centros de custo e o total gravado é R$ 99,99. Que padrão e operação corrigem?
14.
Qual a diferença entre Value Object (Fowler) e Data Transfer Object?
15.
Por que Fowler trata o Registry como último recurso?
16.
O pacote
dominio declara interface Notificador; o pacote infra implementa NotificadorSmtp; um arquivo de configuração escolhe a implementação. Quais padrões aparecem?17.
Qual afirmação sobre Page Controller e Front Controller é correta?
18.
Um JSP de 500 linhas mistura consultas SQL, cálculo de impostos e HTML. Quais correções Fowler recomendaria?
19.
Qual a diferença entre os padrões base Gateway e Mapper?
20.
Em uma aplicação com Table Module, a tela de produtos exibe um grid editável que é salvo de uma vez. Qual estrutura de dados suporta isso diretamente?
Dissertativas
autoavaliação · não entram na notaD1.
Descreva os padrões de apresentação web do livro organizando-os em controladores de entrada, controlador de aplicação e visões. Indique quando usar cada um.
Ver resposta modelo
MVC: separar apresentação do modelo (essencial) e controlador da visão (secundário).
Entrada: Page Controller (um por página; padrão para sites simples) e Front Controller (handler único + comandos; comportamento comum, filtros, comandos dinâmicos).
Aplicação: Application Controller (decide comando e próxima tela pelo estado; fluxos complexos como assistentes; independente da UI).
Visão: Template View (HTML com marcadores + helper; designers editam), Transform View (percorre dados, ex.: XSLT; testável), Two Step View (dados → tela lógica → HTML; visual global e temas).
D2.
Explique a 'primeira lei do design de objetos distribuídos' e como Remote Facade e DTO permitem cruzar fronteiras inevitáveis.
Ver resposta modelo
Lei: não distribua seus objetos. Chamadas remotas são ordens de grandeza mais lentas; bom OO tem interfaces finas que viram muitas chamadas. Escale com cluster de processos completos.
Fronteiras inevitáveis: cliente/servidor, aplicação/banco, web/aplicação, sistemas de terceiros.
Nessas fronteiras: Remote Facade oferece interface grossa, sem lógica de domínio, traduzindo para chamadas finas locais e cuidando de transação e segurança. DTO agrega dados de vários objetos em uma estrutura serializável; Assembler converte domínio ↔ DTO. Considere mensagens assíncronas.
D3.
Compare Client, Server e Database Session State quanto a banda, segurança, cluster/failover e complexidade. Recomende um cenário para cada.
Ver resposta modelo
Client: dados no cliente (cookie, campo oculto, URL). Banda: alta se muitos dados. Segurança: fraca (adulteração), exige assinatura/cifra. Cluster: ótimo, servidor sem estado. Cenário: pouco dado, id de sessão.
Server: memória/serialização no servidor; cliente só com id. Simples de programar. Cluster: exige afinidade ou replicação; memória cresce. Cenário: sessões pequenas sem exigência forte de failover.
Database: sessão no banco como dado pendente; servidores sem estado. Cluster e failover excelentes; custo de I/O por requisição; separar dados pendentes dos de registro e limpar sessões abandonadas. Cenário: muitos usuários, cluster sem afinidade.