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