top of page

Arch War I: MVVM x VIP

MVVM

Definição


MVVM é uma arquitetura de design que visa separar a lógica de negócios e a

apresentação da interface do usuário, sendo composta por três principais componentes:

  • Model: Representa a camada de dados, que inclui estruturas de dados, serviços de rede e gerenciamento de dados.

  • View: É responsável pela exibição da interface do usuário. Ela interage com o ViewModel para obter e exibir os dados necessários.

  • ViewModel: Atua como intermediário entre a View e o Model. Ele contém a lógica de apresentação, transforma os dados do Model em formatos adequados para a View e responde a ações da View.


Vantagens

  • Separação clara de responsabilidades, facilitando a manutenção e testes.

  • Facilita a reutilização de ViewModels em diferentes Views.

  • Permite a criação de testes unitários para ViewModel de forma isolada.

Desafios

  • Pode aumentar a complexidade do projeto com a adição de mais camadas.

  • Requer um gerenciamento cuidadoso de comunicações entre View e ViewModel.


Fluxo


Imagine uma loja de roupas online. A página de produtos é a View (vitrine), onde as

roupas são exibidas. O assistente de vendas (ViewModel) mostra detalhes sobre cada

roupa quando o cliente clica nelas. O estoque (Model) contém todas as informações sobre

as roupas, como tamanhos, cores e preços. Ou seja, cada elemento do MVVM assume um

papel no nosso cenário:


View (Vitrine): exibe os produtos (dados) para os clientes (usuários). Ela não entende muito sobre os detalhes dos produtos, apenas os exibe visualmente.


ViewModel (Assistente de Vendas): ajuda os clientes a entenderem os produtos. Ele pode

fornecer descrições detalhadas, recomendações e até mesmo realizar cálculos de

desconto. Ele conhece os produtos (dados) e os prepara de maneira atraente para a

exibição na vitrine.


Model (Estoque): representa o local onde os produtos (dados) são mantidos. Ele pode

conter informações sobre produtos, preços, disponibilidade, etc. O ViewModel acessa o

estoque para obter as informações necessárias.


VIP (Clean Swift)

Definição


VIP é uma arquitetura inspirada no Clean Architecture e VIPER. Ela também visa

separar preocupações e manter o código organizado. Sendo composta por quatro camadas:

  • View: Lida com a apresentação da interface do usuário, mas sem conter lógica de negócios.

  • Interactor: Contém a lógica de negócios e regras de negócios. Ele recebe solicitações da View e retorna os resultados ao Presenter

  • Presenter: Transforma os dados do Interactor em formatos prontos para exibição na View. Também lida com a formatação de dados e ações da View.

  • Entity: Representa as estruturas de dados principais do aplicativo, independentes da plataforma.


Vantagens

  • Separação clara de responsabilidades e baixo acoplamento.

  • Facilita a escrita de testes unitários para Interactor e Presenter.

Desafios

  • Pode parecer mais complexa em projetos menores.

  • Exige a criação de várias classes e protocolos.


Fluxo


No VIP, a comunicação entre as camadas é como uma conversa em uma equipe de projeto, onde diferentes membros têm funções específicas para alcançar um objetivo comum.


View (Membro da Equipe): recebe as informações do projeto e compartilha suas opiniões e necessidades. Ela não precisa saber todos os detalhes técnicos, mas entende a visão geral.


Presenter (Gerente de Projeto): recebe informações da equipe e as organiza para tomar decisões. Ele pode dividir tarefas entre os membros e manter a comunicação fluindo.


Interactor (Analista de Negócios): trabalha para entender as necessidades do projeto. Ele traduz as necessidades em tarefas específicas para a equipe.


Entity (Recursos e Dados): A Entity é como a fonte de recursos e dados que a equipe precisa para concluir as tarefas. Ela contém os recursos necessários para atingir os objetivos do projeto.


Padrões de projeto

Algumas estruturas como Repository e Service são amplamente usadas no desenvolvimento de software, porém não fazem parte de nenhuma arquitetura específica, o que não significa que eles não podem ser usados em conjunto com alguma arquitetura para exercer seus respectivos papéis.

O uso de Repository e Service é comum em muitos projetos iOS para gerenciar a obtenção de dados de diferentes fontes (banco de dados, APIs web, cache, etc.) e para lidar com a comunicação de rede de maneira modular e reutilizável.

Vamos incluí-los em nosso fluxo de responsabilidades.


MVVM x VIP


Imagine um cenário onde temos um restaurante, vamos tentar aplicar os fluxos de MVVM e VIP para o funcionamento do mesmo.


MVVM

View (Garçom):

  • Representa a interface com o cliente. O garçom (View) interage com o cliente (usuário) e coleta os pedidos, mas não prepara a comida ou manipula o estoque diretamente.


ViewModel (Cozinheiro):

  • O cozinheiro (ViewModel) recebe os pedidos do garçom (View) e prepara os pratos (dados) para o cliente. Ele pode ter uma compreensão mais abstrata do pedido (dados) em relação ao cardápio (Model), mas não sabe todos os detalhes do estoque (Repository).


Model (Pedido/Comanda):

  • Contém todas as informações detalhadas do pedido, instruções, pratos escolhidos, etc.


Repository (Cozinha):

  • A cozinha (Repository) gerencia os ingredientes (dados) e a preparação dos pratos (dados). Ela é responsável por fornecer os pratos ao cozinheiro (ViewModel) quando solicitado, mas a interação direta com os clientes (View) é feita pelo garçom (View).


Service (Estoque):

  • O estoque (Service) lida com os ingredientes, preparações especiais, verificações de disponibilidade, validação de pedidos e outras operações internas que não são visíveis para os clientes (View) nem para o cozinheiro (ViewModel)



VIP


View (Cliente):

  • Continua representando a interface com o usuário, onde o cliente interage.

Interactor (Garçom):

  • Atua como intermediário entre a View (Cliente) e o resto do sistema, coletando e encaminhando os pedidos.

Presenter (Cumin e Cozinheiro):

  • Prepara as informações para serem apresentadas na View (Cliente). No VIP, o Presenter costuma estar mais relacionado com a formatação e organização dos dados a serem mostrados.

Entity (Pedido/Comanda):

  • Armazena os detalhes específicos do pedido, como pratos, instruções, etc.

Repository (Cozinha):

  • Gerencia a lógica de negócios relacionada à obtenção dos dados (no caso, os pratos) e a preparação dos pedidos.

Service (Estoque):

  • Lidaria com as operações internas, validações e disponibilidade dos ingredientes, de forma similar ao seu papel no MVVM.


Conclusão

A abordagem VIP contém mais papéis e com isso as responsabilidades ficam melhores definidas e organizadas, porém como é possível perceber no exemplo do restaurante, pode ser um tanto custoso aplicar essa abordagem em projetos pequenos e simples, além de gerar uma certa curva de aprendizado, os custos e esforços acabam sendo mais elevados.

Em contrapartida para projetos maiores, a abordagem do MVVM pode passar a ideia de desorganização, uma vez que um mesmo elemento estaria exercendo diversas responsabilidades, o que pode gerar gargalos e atrasos no desenvolvimento dos processos.

A escolha entre MVVM e VIP deve levar em consideração a natureza do projeto, a equipe, os requisitos e os recursos disponíveis. Ambas as arquiteturas têm seu lugar e podem ser eficazes dependendo das circunstâncias específicas do desenvolvimento iOS.



DevPoli - \devTazzy


125 visualizações2 comentários

Posts recentes

Ver tudo

2 Comments


Kleiton  Mendes
Kleiton Mendes
Sep 11, 2023

O Entity não seria usado no VIPER?

Like
Daniel Cangianelli
Daniel Cangianelli
Sep 12, 2023
Replying to

Olá Kleiton, é interessante você levantar esse questionamento! A nomenclatura do componente reponsável por representar os objetos de negócio em uma aplicação pode variar de acordo com o desenvolvedor/equipe de desenvolvimento, é muito comum acharmos na literatura o termo "Model" cumprindo o mesmo papel que o termo "Entity", então a escolha normalmente fica vinculada a alguma convenção adotada pela equipe de desenvolvimento, costumo utilizar a palavra "Entity", talvez por herança do VIPER, entretanto "Model" pode ser usado e encontrado em artigos e livros tanto quanto o primeiro.

Like
bottom of page