Paulo implementou um sistema na plataforma Java EE, onde foi adotada a arquitetura MVC, colocando Servlets e JSPs na camada View, entidades JPA na Model e Session Beans na Controller. Como os Session Beans são os únicos componentes que instanciam gestores de persistência do JPA, Paulo segue o padrão de desenvolvimento:
- A)Decorator;
Errada, porque Decorator serve para acrescentar responsabilidades a um objeto, e nao para centralizar o acesso ao JPA.
- B)Facade;
Certa, porque o Session Bean atua como uma fachada para a camada de persistencia, ocultando a complexidade do EntityManager.
- C)Template Method;
Errada, porque Template Method define passos de um algoritmo, e o caso trata de intermediacao entre camadas.
- D)Abstract Factory;
Errada, porque Abstract Factory cria familias de objetos, enquanto aqui o problema e de acesso e coordenacao, nao de criacao de produtos.
- E)State.
Errada, porque State muda o comportamento conforme o estado interno do objeto, o que nao tem relacao com a funcao dos Session Beans no enunciado.
Gabarito: B
Em Java EE, o padrão Facade aparece quando você cria uma camada intermediaria para simplificar o acesso a um conjunto de objetos e serviços mais complexos. A ideia é reduzir a dependencia da View em relacao aos detalhes da Model, deixando a camada de controle conversar com a persistencia de forma mais organizada. Em outras palavras: em vez de cada parte do sistema sair “mexendo nos bastidores”, voce centraliza o acesso em um ponto unico. No enunciado, os Session Beans fazem exatamente esse papel de porta de entrada da regra de negocio e da persistencia. Eles concentram o uso do EntityManager e coordenam as operacoes para a camada de apresentacao nao precisar conhecer detalhes de como os dados sao obtidos ou gravados. Isso bate com a ideia de Facade: oferecer uma interface simples para um conjunto de subsistemas mais chatos por dentro. Por isso o gabarito B esta correto. O Session Bean funciona como uma fachada entre a aplicacao e os mecanismos de persistencia JPA, escondendo a complexidade da criacao e do uso do gestor de persistencia. Em provas, a FGV costuma cobrar exatamente essa traducao: se a camada controla o acesso e simplifica o uso de varios componentes internos, pense em Facade. Os outros padroes da lista nao combinam com a situacao. Decorator adiciona comportamento a objetos dinamicamente, Template Method define o esqueleto de um algoritmo, Abstract Factory cria familias de objetos relacionados e State muda o comportamento conforme o estado interno. Aqui o foco nao e criar variacoes, nem alterar comportamento dinamicamente, mas sim intermediar e simplificar o acesso ao subsistema de persistencia.