Padrões de Projeto: Front Controller e Facade
Gabarito: letra D. O cenário descreve um Servlet que atua como ponto único de entrada para todas as requisições HTTP, direcionando o fluxo para o controlador EJB adequado — isso é o padrão Front Controller. Em seguida, os controladores EJBs acessam as classes DAO e delegam a montagem da resposta para templates — os EJBs funcionam como Facades, simplificando a interface para a lógica de negócio e acesso a dados. Nenhuma outra combinação de padrões se encaixa nos requisitos.
Alternativa A — ❌ Incorreta
Proxy e Observer não atendem à centralização de requisições nem à simplificação de acesso a subsistemas. Proxy controla acesso a um objeto; Observer notifica mudanças; nenhum dos dois é adequado ao fluxo descrito.
Alternativa B — ❌ Incorreta
Flyweight (compartilhamento de objetos para economia de memória) e Strategy (algoritmos intercambiáveis) não se aplicam ao papel do Servlet como front-end único nem à função do EJB como fachada para lógica de negócio.
Alternativa C — ❌ Incorreta
Template Method (esqueleto de algoritmo) e Command (encapsulamento de requisição) não refletem a arquitetura descrita. O Servlet não é um esqueleto de algoritmo, e os EJBs não são comandos encapsulados.
Alternativa D — ✅ Correta ⟵ GABARITO
O Servlet atua como Front Controller, centralizando o tratamento de requisições e delegando aos controladores. Os EJBs implementam o padrão Facade, oferecendo uma interface simplificada para o subsistema de lógica de negócio e DAOs. Perfeitamente alinhado aos requisitos.
Alternativa E — ❌ Incorreta
Builder (construção de objetos complexos) e Adapter (conversão de interfaces) não se relacionam com a responsabilidade de roteamento de requisições nem com a fachada para lógica de negócio.
Gabarito: letra D.