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.

Image

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.