GabaritoE — Errado
Gabarito: E — ERRADO. No padrão MVC, o Model não deve ter acesso direto à View; a comunicação entre eles ocorre sempre por intermédio do Controller. A afirmação inverte o fluxo de controle do padrão, que é justamente o papel do Controller de mediar as interações entre Model e View.
O padrão MVC (Model-View-Controller) é um dos estilos arquiteturais mais cobrados em concursos de TI. Ele organiza a aplicação em três componentes com responsabilidades bem definidas:
Model: representa os dados e a lógica de negócio. É a camada que conhece as regras do domínio, persiste informações e notifica mudanças de estado. O Model não conhece a View nem o Controller — ele é independente da interface.
View: é a camada de apresentação, responsável por exibir os dados ao usuário e capturar as interações. A View não contém lógica de negócio; ela apenas renderiza o que o Model fornece (via Controller).
Controller: é o intermediário. Ele recebe as requisições do usuário (via View), interpreta, aciona o Model para processar os dados e, em seguida, seleciona a View adequada para exibir o resultado. O Controller orquestra o fluxo.
A regra central do MVC é a separação de responsabilidades e o baixo acoplamento entre as camadas. O Model não pode "enxergar" a View, pois isso criaria uma dependência indesejada: qualquer alteração na interface exigiria modificação no Model, violando o princípio da responsabilidade única e dificultando a manutenção e os testes.
Na prática, quando o Model muda, ele notifica o Controller (ou um mecanismo de observação, como o padrão Observer), e o Controller decide como atualizar a View. Em frameworks web (como Spring MVC, ASP.NET MVC, Laravel), o fluxo típico é:
O usuário interage com a View (ex.: clica em um botão).
A View envia a requisição ao Controller.
O Controller processa a requisição, chama o Model para obter/alterar dados.
O Controller seleciona a View que renderizará a resposta, passando os dados do Model.
A pegadinha da banca está em afirmar que o Model atualiza a View diretamente, sem passar pelo Controller. Isso contraria o papel do Controller como mediador. Em algumas variações do MVC (como o MVVM), o Model pode notificar a View via data binding, mas no MVC clássico o Controller é o elo obrigatório.
A banca inverte o fluxo de comunicação do MVC. O candidato que decora apenas os nomes das camadas pode achar que o Model "atualiza a View" faz sentido, mas o Controller é quem faz a ponte. Lembre-se: Model não conhece View; Controller conhece ambos.
A afirmação está incorreta porque atribui ao Model um acesso direto à View, o que viola o princípio fundamental do MVC. O Model é a camada de dados e regras de negócio, e deve permanecer desacoplada da interface. A atualização da View é responsabilidade do Controller, que recebe as notificações de mudança do Model e decide como (e se) a View deve ser atualizada.
Se o Model tivesse acesso direto à View, teríamos um acoplamento indesejado: o Model dependeria da interface, dificultando a reutilização da lógica de negócio em diferentes contextos (web, desktop, mobile) e comprometendo a testabilidade. O fluxo correto é: Model → (notifica) → Controller → (atualiza) → View.
Gabarito: E — ERRADO.
Link permanente: /questoes/qg603665