Questão de Arquitetura de Software — Padrões de projeto (Design Patterns) — IF-PI 2026
Arquitetura de Software›Padrões de projeto (Design Patterns)
Código
qg709972
Banca
IF-PI
Órgão
IF-PI
Ano
2026
Nível
Superior
Cargo
Professor EBTT - Informática
Sobre o padrão de arquitetura de desenvolvimento de software MVVM (Model-View-ViewModel) usado principalmente no desenvolvimento mobile, assinale a alternativa CORRETA:
AO desacoplamento entre View e ViewModel é comumente implementado através de padrões de observabilidade, onde a View assina fluxos de dados expostos pela ViewModel.
BÉ uma evolução da arquitetura MVC (Model-View-Controller) adaptada para a arquitetura WPF e Silverlight.
CElimina o uso de Activities e Fragments na camada de View tornando a implementação mais simples.
DA camada Model é acoplada à camada View, o que facilita a troca de mensagens entre as duas camadas.
EOs modelos de dados são acessados diretamente pela camada View, sem a necessidade de mediação do ViewModel, de forma semelhante ao que ocorre em arquiteturas como MVC e MVP.
Revelar gabarito e comentário▾
GabaritoA — O desacoplamento entre View e ViewModel é comumente implementado através de padrões de observabilidade, onde a View assina fluxos de dados expostos pela ViewModel.
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”.
MVVM (Model-View-ViewModel)
Gabarito: letra A. No MVVM, o ViewModel expõe dados e comandos por meio de mecanismos de observabilidade (data binding), e a View assina esses fluxos – isso garante o desacoplamento entre View e ViewModel, que é a essência do padrão.
A questão testa o conhecimento fundamental do MVVM, especialmente em contraste com outras arquiteturas (MVC, MVP). O ponto central é que a View nunca acessa o Model diretamente; toda comunicação passa pelo ViewModel, que expõe um estado reativo.
Característica
MVVM (Model-View-ViewModel)
MVC (Model-View-Controller)
MVP (Model-View-Presenter)
Comunicação View → Lógica
A View assina fluxos de dados (observabilidade) expostos pelo ViewModel.
A View delega ações ao Controller, que atualiza o Model.
A View delega ações ao Presenter, que manipula o Model e atualiza a View.
Acoplamento View / Model
Desacoplado (View nunca acessa Model diretamente).
Desacoplado (View não acessa Model diretamente).
Desacoplado (View não acessa Model diretamente).
Mecanismo de atualização da View
Data binding bidirecional / reativo (ex.: LiveData, RxJava).
O Controller atualiza o Model, que notifica a View (ou a View consulta).
O Presenter atualiza a View diretamente (interface).
Papel da View
"Enxuta", apenas exibe dados e encaminha eventos de usuário.
"Enxuta", apenas exibe dados e encaminha eventos ao Controller.
"Passiva", delega toda a lógica de apresentação ao Presenter.
Origem / Contexto principal
Popularizado pela Microsoft (WPF/Silverlight), amplamente usado em mobile (Android/iOS).
Padrão clássico da web (ex.: frameworks Ruby on Rails, Spring MVC).
Padrão comum em interfaces desktop e mobile (ex.: Android com interfaces).
MVVM: View (Assina fluxos do ViewModel, Nunca acessa Model); ViewModel (Expõe dados reativos, Mediação entre View e Model); Model (Desacoplado da View, Desacoplado da ViewModel)
Alternativa A — ✅ Correta ⟵ GABARITO
A descrição está perfeita. No MVVM, a View observa (se inscreve em) fluxos de dados expostos pelo ViewModel, geralmente via bibliotecas de data binding (DataBinding, LiveData, RxJava, etc.). Esse mecanismo de observabilidade é o que promove o baixo acoplamento: a View sabe apenas do ViewModel, não do Model.
Alternativa B — ❌ Incorreta
Afirma que o MVVM é "uma evolução da arquitetura MVC adaptada para WPF e Silverlight". Embora o MVVM tenha sido popularizado pela Microsoft para essas tecnologias, não é uma evolução direta do MVC. O MVVM deriva mais do MVP (Model-View-Presenter), incorporando data binding bidirecional. Além disso, o padrão não se restringe a WPF/Silverlight – é amplamente usado em desenvolvimento mobile (Android, iOS) com outras implementações.
NÃO CAIA NESSA!
A banca explora a confusão histórica entre os padrões. O candidato pode lembrar que MVVM surgiu no ecossistema .NET, mas isso não o torna uma "evolução do MVC". A relação correta é: MVC → MVP → MVVM (com binding).
Alternativa C — ❌ Incorreta
"Elimina o uso de Activities e Fragments na camada de View" – incorreto. No Android, Activities e Fragments são a camada View. O MVVM não os elimina; apenas retira deles a lógica de apresentação, transferindo-a para o ViewModel. A View ainda existe (Activity/Fragment), mas fica “enxuta”, delegando a reatividade ao ViewModel.
Alternativa D — ❌ Incorreta
"A camada Model é acoplada à camada View" – exatamente o oposto do que o MVVM prega. No MVVM, Model e View são totalmente desacoplados: o Model não conhece a View, e a View não conhece o Model. Quem faz a ponte é o ViewModel. Acoplar Model e View quebraria a separação de responsabilidades e dificultaria a manutenção.
Alternativa E — ❌ Incorreta
"Os modelos de dados são acessados diretamente pela camada View, sem mediação do ViewModel" – isso não ocorre no MVVM. A View nunca acessa o Model diretamente. Toda interação passa pelo ViewModel, que transforma os dados do Model em um formato adequado para a View. Em MVC e MVP também há mediação (Controller/Presenter), portanto a afirmação também é falsa para esses padrões.