O ponto mais importante quando falamos sobre arquitetura é entender quais componentes existem para executar uma determinada responsabilidade. Portanto, o objetivo desse artigo é falar sobre responsabilidades primeiro e, em seguida, os componentes de cada arquitetura iOS.
Responsabilidades
Renderização
É a responsabilidade de mostrar na tela o código escrito especificamente sobre os componentes visuais: rótulos, botões, campos de texto, imagens, etc.
Geralmente, estão representados no código por um .xib e uma classe do tipo ViewController.
Processamento de dados
É a responsabilidade de processar as informações no formato apropriado para serem enviadas para renderização.
Um exemplo: dada uma lista de países com descrição e sigla do país, se eu quiser exibir apenas a lista de países sem sigla, precisaria fazer o tratamento da lista, para enviar ao ViewController uma lista contendo apenas as descrição dos países.
Normalmente, temos uma classe para essa responsabilidade, que pode ter vários nomes, como ViewModel ou Presenter.
Modelagem de dados
É a responsabilidade de definir os tipos de dados para um determinado objeto. Em uma lista de países com descrição e sigla, teríamos um objeto País com duas variáveis: a descrição e a sigla, conhecido como Modelo.
Ações de fluxo de tela
É a responsabilidade de alterar o fluxo do aplicativo para outra tela, apresentar um alerta, retornar, etc, de acordo com as ações do usuário. São implementados em Coordinators ou Routers (também conhecidos como Wireframes).
Requisições à API
Aqui, estamos falando sobre a responsabilidade de fazer solicitações HTTP para APIs Rest e retornar a resposta externa ao aplicativo. Na maioria das vezes é implementado na classe API ou Interactor.
Existem outras responsabilidades? Sim, mas as responsabilidades acima são as mais comuns.
Por exemplo, alguns aplicativos têm a responsabilidade de taguear o fluxo em um sistema de analytics. Outros têm a responsabilidade de fazer tratamentos de conversão de dados da API para outros modelos de dados. Essas responsabilidades podem ser assumidas em componentes específicos ou em qualquer um dos componentes da arquitetura do seu projeto.
Arquitetura iOS: As mais utilizadas
MVC (Model, ViewController)
Tem poucos componentes, com mais responsabilidades.
Model:
– Modelagem de dados
ViewController:
– Renderização
– Requisições à API
– Processamento de dados
MVP (Model, ViewController, Presenter)
O Presenter compartilha responsabilidades com o ViewController.
Model:
– Modelagem de dados
ViewController:
– Renderização
Presenter:
– Requisições à API
– Processamento de dados
MVVM (Model, ViewController, ViewModel)
É o mesmo que MVP, mas o Presenter tem outro nome: ViewModel.
Model:
– Modelagem de dados
ViewController:
– Renderização
ViewModel:
– Requisições à API
– Processamento de dados
– Ações de fluxo de tela
VIPER (ViewController, Interactor, Presenter, Entity, Router)
Com nomes diferentes, semelhantes ao MVVM, com um pouco mais de divisão de responsabilidades.
Entity:
– Modelagem de dados
ViewController:
– Renderização
Interactor:
– Requisições à API
Presenter:
– Processamento de dados
Router (também conhecido como Wireframe):
– Ações de fluxo de tela
MVVM-C (Model, ViewController, ViewModel, Coordinator)
O Coordinator é um componente amplamente utilizado em algumas arquiteturas. Ele vem para complementar arquiteturas como o MVVM, por exemplo, assumindo a responsabilidade pelas ações de fluxo entre telas, tornando a ViewModel mais limpa.
Nesse caso, seria, uma arquitetura MVVM-C. É possível usar o Coordinator em outras arquiteturas: MVC-C, MVP-C, etc.
Deve funcionar assim:
Imagine esse fluxo de telas: A → B → C; o coordenador deve implementar pelo menos 3 protocolos com 1 método interno para enviar cada ViewController para a fila. Em seguida, no ViewModel, basta delegar essa responsabilidade ao coordenador e chamar o método de protocolo quando o usuário interagir, por exemplo, tocando em um botão.
Onde devo implementar as regras de negócios?
Importante lembrar que as regras devem ser implementadas no Back-end.
Seu aplicativo deve se limitar a fazer solicitações a uma API, coletar dados, fazer tratamentos simples e exibi-los na tela à medida que eles chegam.
Se uma determinada tela tiver três layouts possíveis, dependendo do cenário do usuário, as informações que definem em qual dos três cenários estamos devem vir do Back-end.
Ok, mas por que deveria vir do Backend? Simples: é melhor implementar a regra apenas uma vez no Back-end, do que nas várias plataformas de Front-end (iOS, Android, Web), e se a regra de negócios mudar, o tempo de deploy dos sistemas de Backend será muito menor, pois não precisa ser enviado à App Store ou ao Google Play para publicação.
Ainda ficou com alguma dúvida sobre arquitetura IOS? Conta pra gente nos comentários.
Newsletter de desenvolvimento
Quer receber em primeira mão conteúdos como esse por e-mail? Assine aqui nossa newsletter semanal.
