< Insights

Conheça as principais arquiteturas para aplicações iOS

  • Desenvolvimento de Software

Quem já atua com o desenvolvimento sabe que existem diversas arquiteturas para aplicações iOS. Mas será que existe alguma que consiga facilitar a implementação de novas funcionalidades ou até mesmo permitir realizar correções de forma menos trabalhosa?

Neste artigo vamos apresentar as características que definem as arquiteturas que estão disponíveis no mercado. Assim, você poderá analisar e escolher qual a melhor para o seu contexto. 

Arquitetura MVC (Model View Controller)

O MVC foi a arquitetura inicialmente adotada pela Apple, com o objetivo de definir as responsabilidades de cada objeto.Vejamos abaixo a definição, vantagens e desvantagens:

Model: A Model tem a responsabilidade de encapsular os dados e definir a lógica que os processa.

View: É um objeto em uma aplicação que pode ser visto pelo usuário, tem conhecimento de como desenhar a si mesmo e também pode responder às ações do usuário. No caso do iOS ela pode ser representada pelos arquivos storyboard, xib e SwiftUI.

Controller: A Controller é definida como um intermediário entre um ou mais objetos da View e um ou mais objetos da Model. No iOS são as classes ViewController, que são responsáveis por ter referenciado em código todos os componentes da View.

 Infográfico sobre a arquitetura MVC

 

Vantagens MVC 

  • Facilidade em delegar responsabilidades aos componentes;
  • Desenvolvimento inicial rápido.

Desvantagens MVC

  • Testes ficam praticamente inviáveis;
  • Manutenção é dificultada conforme o projeto cresce.

Para criação de uma PoC (Proof of Concept), o MVC se torna viável, pois seu desenvolvimento é rápido e a estrutura de arquivos é simples. Em um projeto de maior complexidade, poderá ter sérios problemas de escalonamento. Considerando esses problemas, passamos a ter outras arquiteturas que tentam resolver isso.

Arquitetura MVP (Model View Presenter)

  Na MVP, o componente Model possui a mesma responsabilidade se comparado a arquitetura mencionada anteriormente (MVC), porém, o que conhecíamos como View e Controller, passam a ser um único componente, sendo ele nomeado como a View na arquitetura MVP. Ainda nesta arquitetura, é criado um novo componente denominado Presenter, definida como um intermediário entre um objeto da View e um ou mais objetos da Model.

Infográfico sobre a arquitetura MVP 

Vantagens MVP

  • Como há 3 camadas com responsabilidades distintas, a aplicação se torna facilmente testável;
  • Inicia-se nesta arquitetura o desacoplamento de responsabilidades entre os componentes. Facilitando a manutenção.

Desvantagens MVP

  • Apesar das vantagens acima, se o projeto for de grande complexidade, ele passa a enfrentar os mesmos problemas do MVC, com uma Presenter sobrecarregada.   

Arquitetura MVVM (Model View ViewModel

         Na arquitetura MVVM temos os componentes Model, View e a ViewModel.

  Infográfico sobre a arquitetura MVVM

         Model: Segue com as mesmas responsabilidades das arquiteturas citadas anteriormente (MVC e MVP);

         View: Segue com as mesmas responsabilidades da arquitetura anterior (MVP);

         ViewModel: É definida como um intermediário entre um ou mais objetos da View e um ou mais objetos da Model, diferenciando da relação encontrada na MVP, onde existe uma relação de 1:1 entre os componentes. A ViewModel pode ser instanciada em várias Views distintas, na proporção 1:N, possibilitando maior reaproveitamento de código.

 Vantagens MVVM

  • Possibilidade do reaproveitamento de código, pois a ViewModel pode ser compartilhada entre diversas Views. 

Desvantagens MVVM

  • Para projetos de grande complexidade, a utilização de várias Views com a mesma ViewModel pode sobrecarregá-la.

Embora a MVVM seja uma evolução das arquiteturas anteriores, ela ainda encontra o mesmo problema, um componente (ViewModel) sobrecarregado em projetos de maior escala.

Arquitetura VIPER (View Interactor Presenter Entity Router)

Para tentar solucionar o maior problema das arquiteturas anteriores, tentou-se aplicar a Clean Architecture, uma abordagem bidirecional utilizada foi chamada de VIPER. 

View: Mesmas responsabilidade da arquitetura anterior.

Interactor: Tem a responsabilidade de realizar a comunicação entre os componentes Presenter e Entity. Este componente é completamente independente da View, e se encontra toda a lógica negocial.   

 Presenter: Tem a responsabilidade de realizar a comunicação entre a View e a Interactor, por um meio recebe os dados de entrada vindos da View e reage de acordo com ela, fazendo as requisições dos dados para o Interactor. Em outro modo, recebe as estruturas de dados vindos da Interactor, aplica as lógicas de visualização sobre estes dados para preparar o conteúdo, e finalmente informa a View o que deve ser mostrado.

Entity: Tem a responsabilidade de encapsular diferentes tipos de dados, semelhante a Model nas arquiteturas anteriores.

Router: Tem a responsabilidade de gerenciar a lógica de navegação entre as Views, deste modo tornando esse código testável e fácil de encontrar.

Infográfico da arquitetura VIPER

 Vantagens VIPER

  • Altamente testável e manutenível, pois temos uma maior separação de responsabilidades;
  • Escalável para projetos complexos, grandes e com muitos desenvolvedores.

Desvantagens VIPER

  • A Presenter fere o princípio de responsabilidade única. Podendo em projetos de larga escala ter uma Presenter com muitas responsabilidades, acarretando os mesmos problemas encontrados nas arquiteturas anteriores.

 Arquitetura VIP (View Interactor Presenter)

Considerando a desvantagem apresentada na arquitetura anterior, Raymond Law sugeriu utilizar a Clean Architecture, utilizando outra abordagem para sanar essa desvantagem. Ele defende que abandonemos o caminho bidirecional da arquitetura VIPER, e adotemos um caminho cíclico unidirecional, com isso a Presenter passa a ter uma única responsabilidade.

Infográfico sobre arquitetura VIP

View: Mesmas responsabilidade da arquitetura anterior.

Interactor: Tem a responsabilidade de realizar a comunicação da Presenter com a View. Toda lógica negocial é encontrada neste componente. É sua responsabilidade também a comunicação com o Worker (Componente que se comunica com qualquer fonte de dados, seja ela uma API, persistência local, etc.)

Presenter: Tem a responsabilidade de receber informações da Interactor, processar esses dados com a lógica de tela e informar para a View o que deve ser mostrado.

Com base no comparativo entre todas as arquiteturas mencionadas neste artigo, pode-se concluir que a melhor arquitetura para aplicações iOS com projetos complexos, de larga escala e com vários desenvolvedores, é a VIP. Por se tratar de uma arquitetura em que há a separação de responsabilidades entre os componentes de modo a torná-lo testável, de fácil manutenção e altamente escalável.

Mesmo após este artigo, ainda tem dúvidas sobre arquitetura para aplicações iOS ou desenvolvimento de software? Clique aqui e marque uma conversa com nossos especialistas.

Insights do nosso time

Obtenha insights do nosso time de especialistas sobre metodologias de desenvolvimento de software, linguagens, tecnologia e muito mais para apoiar o seu time na operação e estratégia de negócio.