Arquitetura iOS VIPER

Nos estudos acabei achando uma Arquitetura para iOS chamada VIPER.

Onde pude ter a oportunidade de entender, está Arquitetura tem como base a Experiência de construção de LEGO transferida para o design do aplicativo iOS VIPER.

Diferente do padrão MV(X), VIPER faz outra iteração sobre a ideia de separar responsabilidades com cinco camadas.

Interator — contém lógica de negócios relacionada aos dados ( Entidades ) ou rede, como criar novas instâncias de entidades ou buscá-las no servidor. Para esses propósitos, você usará alguns serviços e gerenciadores que não são considerados parte do módulo VIPER, mas sim uma dependência externa. Apresentador — contém a lógica de negócios relacionada à IU (mas independente do UIKit ), invoca métodos no Interator . Entidades — seus objetos de dados simples, não a camada de acesso a dados, porque isso é responsabilidade do Interator . Roteador — responsável pelos trechos entre os módulos VIPER . Basicamente, o módulo VIPER pode ser uma tela ou toda a história do usuário de seu aplicativo — pense na autenticação, que pode ser uma tela ou várias outras relacionadas. Quão pequenos são os seus blocos de “LEGO”? — Você é quem decide.

Se compararmos com o padrão MV(X), veremos algumas diferenças na distribuição de responsabilidades: A lógica do modelo (interação de dados) mudou para o Interator com as Entidades como estruturas de dados burras. Apenas as funções de representação da IU do Controller / Presenter / ViewModel foram movidas para o Presenter, mas não os recursos de alteração de dados.

VIPER é o primeiro padrão que aborda explicitamente a responsabilidade da navegação, que deve ser resolvida pelo Roteador. A maneira adequada de fazer o roteamento é um desafio para os aplicativos iOS, os padrões MV(X) simplesmente não resolvem esse problema.

Distribuição — distribuição de responsabilidades. Testabilidade — sem surpresas aqui, melhor distribuição — melhor testabilidade. Fácil de usar — finalmente, os dois acima têm custo de manutenção, como você já imaginou. Você tem que escrever uma grande quantidade de interface para classes com responsabilidades muito pequenas.

Me parece que adotar o VIPER você tem a liberdade e a percepção de que pode construir um tanque, mas que pode servir para atirar numa mosca. E muito dos padrões do MV(X) consiga nos atender a longo prazo e com um custo menor de manutenção.

Fonte(s): https://edersonmelo.com