Arquitetura VIPER

Introdução

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.

Figura 1

Responsabilidades de cada camada

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.

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.

Figura 3

Agora já temos a teoria base, no próximo post veremos a implementação completa de um módulo VIPER no iOS.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>