ANÚNCIO

~/questoes/programacao

Qual é a responsabilidade principal de um Controller no padrão MVC?

Responda, confira o feedback e use o resultado para orientar sua revisão.
Aula de referência Curso de Node JS Aula 10 Refatorar para o MVC Controller e ajustes
Para fixar

Responsabilidade Principal do Controller no Padrão MVC

Conceito central

O Controller é o intermediário entre as requisições HTTP e a lógica de negócio da aplicação. Ele recebe as requisições do cliente, coordena o processamento e prepara a resposta apropriada. No padrão MVC, o Controller não executa toda a lógica sozinho, mas orquestra as operações chamando outras camadas como Model e View.

Por que essa resposta faz sentido

O Controller é responsável por receber as requisições HTTP e coordenar as respostas para os clientes. Ele atua como um intermediário que recebe a requisição, processa ou delega o processamento para outras camadas (como o Model), e então envia a resposta de volta ao cliente.

Armadilhas comuns

  • Confundir o Controller com a View: lembrar que o Controller não renderiza HTML, apenas coordena o processamento
  • Colocar toda a lógica de validação e segurança no Controller quando devem estar em middlewares ou na camada de autenticação
  • Esquecer que o Controller é um intermediário: ele delega responsabilidades para Model e View em vez de fazer tudo sozinho

Entenda as alternativas

A

Correta. O Controller é o ponto de entrada das requisições HTTP. Ele coordena todo o fluxo de resposta, decidindo quais operações executar e como apresentar os dados ao cliente. É o 'maestro' da orquestra MVC.

B

Incorreta. Validação de credenciais é uma responsabilidade de middlewares e camadas de autenticação, não do Controller. O Controller assume que a requisição já foi validada quando chega até ele.

C

Incorreta. Renderizar páginas HTML é responsabilidade da View, não do Controller. O Controller prepara os dados, mas quem transforma esses dados em HTML é a View.

D

Incorreta. Armazenar dados no banco de dados é responsabilidade do Model ou Repository, não do Controller. O Controller pode solicitar que o Model faça isso, mas não faz diretamente.

Dica prática: Quando estiver criando um método no Controller (como index, show, store), pense assim: 'Recebo uma requisição, faço o necessário e envio uma resposta'. Não coloque lógica complexa de banco de dados ou renderização de HTML direto no Controller. Chame o Model para dados e a View para apresentação.

Revise pensando: Se o Controller não valida credenciais, não renderiza HTML e não armazena dados, então qual é exatamente seu papel na arquitetura MVC?