Pular para o conteúdo principal

Questão de Arquitetura de Software — Arquitetura em camadas — CONSULPAM 2026

Arquitetura de SoftwareArquitetura em camadas
Código
qg661781
Banca
CONSULPAM
Órgão
Prefeitura de Eusébio - CE
Ano
2026
Nível
Médio
Cargo
Técnico em Tecnologia da Informação
Uma aplicação web de serviços ao cidadão foi construída em MVC. Em um determinado momento, um Técnico de TI começou a inserir validações e regras de cálculo na camada de apresentação para tornar a aplicação eficiente. Com base no enunciado, analise as sentenças a seguir:I- Colocar regras de negócio na camada View tende a reduzir o acoplamento e simplificar a manutenção e testes.PORQUEII- A camada View é voltada à apresentação do sistema, de modo que inserir lógica de negócio aumenta a coesão e auxilia a testabilidade.Analisadas as sentenças, assinale CORRETAMENTE:
  1. AAs duas sentenças são verdadeiras, mas a segunda não é uma justificativa correta da primeira.
  2. BA primeira sentença é verdadeira, e a segunda, falsa.
  3. CA primeira sentença é falsa, e a segunda, verdadeira.
  4. DTanto a primeira quanto a segunda sentença são falsas.
Revelar gabarito e comentário

GabaritoD — Tanto a primeira quanto a segunda sentença são falsas.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

MVC e regras de negócio na View

Gabarito: D. Ambas as sentenças são falsas. A primeira afirma que colocar regras de negócio na View reduz acoplamento e simplifica manutenção – o oposto do que prega o padrão MVC, que separa responsabilidades. A segunda diz que inserir lógica na View aumenta coesão e testabilidade – na verdade, quebra a coesão (a View deve ser coesa apenas para apresentação) e dificulta testes, pois a lógica fica misturada com a interface.

Análise das sentenças

I – Falsa. No MVC, a View é responsável exclusivamente pela apresentação dos dados ao usuário. Colocar regras de negócio (validações, cálculos) na View cria um forte acoplamento entre a lógica e a interface, aumentando a dependência entre camadas. Isso dificulta a manutenção (alterações na regra exigem mexer na View) e os testes (a lógica fica atrelada à interface, difícil de isolar). Portanto, a afirmação de que reduz acoplamento e simplifica manutenção é incorreta.

II – Falsa. Inserir lógica de negócio na View diminui a coesão da camada, pois ela passa a ter responsabilidades distintas (apresentação + regras). Coesão alta significa que cada módulo tem uma única responsabilidade bem definida; misturar funções quebra esse princípio. Além disso, a testabilidade é prejudicada, já que testar regras de negócio exige simular a interface, o que é mais complexo do que testar a lógica isolada no Model. Logo, a segunda sentença também é falsa.

Como ambas são falsas, a alternativa correta é a D: "Tanto a primeira quanto a segunda sentença são falsas."

MVC: Responsabilidades
  • 1Model
    • Regras de negócio
    • Dados
  • 2View
    • Apresentação
    • Regras de negócio (quebra coesão)
  • 3Controller
    • Intermediação
    • Fluxo
  • 4Princípios violados
    • Acoplamento
      • Forte (lógica na View)
    • Coesão
      • Baixa (View com 2 responsabilidades)
    • Testabilidade
      • Difícil (lógica atrelada à interface)
LEVEL · soulevel.com.br
NÃO CAIA NESSA!

Aqui a banca tenta confundir o candidato com o raciocínio de que colocar lógica na View "torna a aplicação eficiente" (frase do enunciado). Lembre-se: a eficiência aparente de curto prazo não se sobrepõe aos benefícios de longo prazo da boa arquitetura (baixo acoplamento, alta coesão, facilidade de manutenção e testes). O MVC foi criado justamente para evitar essa mistura.

Gabarito: letra D.

Link permanente: /questoes/qg661781