VIPER é uma arquitetura baseada na arquitetura CLEAN criada por Robert Cecil Martin (conhecido na comunidade como Uncle Bob), que vem sendo utilizada nas aplicações Mobile na redspark a aproximadamente 3 anos, e tem como premissa a separação das “responsabilidades” da aplicação em camadas diferentes (Figura 1), facilitando assim o reaproveitamento, a leitura, testes e manutenção do código.
View: Essa camada é responsável pela renderização dos componentes visuais e interação com o usuário, recebe a entrada de dados, como por exemplo o preenchimento de um campo, um clique no botão, etc. Outra responsabilidade dessa camada é dar feedback para o usuário, como uma mensagems de erro ou de sucesso.
Essa camada não processa nenhuma informação, apenas recebe dados do presenter para apresentação e envia os eventos para serem tratados pela presenter.
Presenter: Essa camada é responsável pelas regras de apresentação, e disparar os eventos ocorridos na View para o processamento no Interactor, por exemplo, em casos que é preciso buscar uma informação na nuvem, a Presenter recebe da View um evento que pede o carregamento de uma lista, ela avisa a View para colocar um loader na tela (feedback para o usuário) e repassa o evento para o Interactor que vai processar essa informação (talvez com a ajuda de outras camadas), após ter uma resposta do Interactor, a Presenter informa a View sobre o feedback que precisa ser dado.
Interactor: Nessa camada são processadas as regras de negócio, validações, cálculos e aquisição de dados local ou de dados na nuvem.
Router: A responsabilidade dessa camada é a navegação entre telas (módulos), sempre que for preciso apresentar uma tela nova a Presenter solicita a nova tela para a camada Router do módulo destino. Outra responsabilidade desta camada é a de montar o módulo VIPER para operar, interligando todas as camadas necessárias.
Entity: As entities são a representação de um dado que precisa “circular” entres as camadas e módulos diferentes.
Nós da redspark utilizamos uma camada adicional, a Data Manager, entre a Interactor e as Entities, com essa camada nós transferimos a responsabilidade de aquisição de dados, local ou remoto, da Interactor para ela. Assim ficamos com diagrama da Figura 2.
Vale lembrar que essas estrutura é utilizada para cada módulo (feature) do projeto, que fica com a estrutura na sua hierarquia parecido com a Figura 3.
Agora já temos a teoria base, no próximo post veremos a implementação completa de um módulo VIPER no iOS.