As 5 arquiteturas iOS mais utilizadas

Neste artigo você vai ver:

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.

5 arquiteturas iOS mais utilizadas

MVC (Model, ViewController)

Tem poucos componentes, com mais responsabilidades.

Model:

– Modelagem de dados

ViewController:

– Renderização

– Requisições à API

– Processamento de dados

arquiteturas ios
Ações de fluxo de tela

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

mvp arquitetura ios

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:

viper

– 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 no assunto? 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.

5e7cea864b14b95a8821b012_mario-henrique
iOS Developer
iOS Tech Lead e Empreendedor nas horas vagas

Artigos relacionados

Este site utiliza cookies para proporcionar uma experiência de navegação melhor. Consulte nossa Política de Privacidade.