Qual a melhor arquitetura para aplicações iOS? MVC?
Dentre várias arquiteturas que existem e que estão por vir, existe uma que consiga resolver todos os problemas, certo?!
Tenho ouvido essa pergunta constantemente e em diferentes lugares, porém todas em um mesmo contexto, uma aplicação que tem dado muito trabalho e se tornando algo difícil/trabalhoso de implementar novas funcionalidades e até mesmo realizar correções.
Acredito que todos (desenvolvedores) em algum momento já questionou em nível arquitetural a existência de uma que resolva todos os problemas. Eu já passei por isso e já tem bastante tempo que estou gastando algumas horas do meu dia para estudar cada vez mais arquitetura, não só no contexto iOS, mas buscando compreender as escolhas que as pessoas fazem.
O que define uma boa arquitetura?
Sabemos que existem algumas características a respeito da definição de uma boa arquitetura:
- Fácil de usar.
- Responsabilidades distribuídas.
- Pode ser testada.
Só! Sim, só isso. Não vou inserir outras boas qualidades que podem definir uma arquitetura boa de uma ruim, pois a própria definição pode dar margem a complexidade. Eu vejo isso como um checklist simples, se eu como desenvolvedor conseguir preencher esses 3 pontos, não significa nada, mas se outra pessoa consegue compreender minhas escolhas e trabalhar com o que existe, dando continuidade, então meu caro é muito provável que você esteja no caminho certo. Sim, seguir isso também não significa que você está certo.
MVC
Model-View-Controller ou MVC diferentemente do que a Apple “defende” como design pattern, o MVC é considerado um padrão de arquitetura de software que consiste em três camadas:
Model
A representação dos dados na aplicação, chegando a possuir regras de négocios, funções… O modelo é o centro da aplicação, recebendo os comandos da Controller e enviando para a camada View.
View
Essa é a camada em que os dados da aplicação são apresentados ao usuário.
Controller
Responsável por ser o intermediador entre a camada de visão (view) e o modelo (model). Ele tem como objetivo enviar comandos ao modelo, solicitando atualização, da mesma forma que notifica a camada view para que possa representar o modelo.
Durante bastante tempo foi muito usada em aplicações web, facilitando o reuso dos componentes e os testes isoladamente. Se analisarmos de acordo com os critérios que foram descritos para determinar uma boa arquitetura:
- Fácil de usar. ✓
- Responsabilidades distribuídas. ✓
- Pode ser testada. ✓
Apple MVC
Quando olhamos para o MVC no contexto de desenvolvimento nativo para aplicações iOS utilizando os frameworks da Apple., temos um cenário totalmente diferente do que foi visto anteriormente, onde as camadas Controller e View não são independentes.
Na página da Apple sobre o MVC, ela apresenta em sua documentação que o Cocoa tem como centro o uso do Model-View-Controller, possuindo a seguinte estrutura:
Model
Responsável por encapsular os dados e define a lógica de manipulação e facilmente reutilizável.
View
Continua sendo a camada do usuário e envia as ações do usuário para a controller.
Controller
A camada intermediária entre view e model. Responsável por informar a camada view sobre mudanças no modelo.
Se analisarmos a classe UIViewController, do framework UIKit, utilizado para a construção de telas de uma aplicação iOS, nos deparamos com a seguinte estrutura:
Exemplo
No exemplo criado para o MVC, a camada controller teve o papel de realizar a requisição e "popular" a camada view com as informações da camada model que possui acesso.
Foi utilizado o playground no Xcode 9 para o desenvolvimento desse exemplo.
Para parte de serviço, foi utilizado o site http://httpbin.org usando o serviço headers que retorna um JSON com os headers.
O código abaixo representa a controller do exemplo:
O modelo desse exemplo é bem simples com uma simples lógica de acesso aos dados através do método description.
Quando compilamos o código, temos como resultado a tela abaixo, uma tabela listando em cada célula o header e seu valor:
Observe que a camada view e controller se tornam quase que uma só, tendo somente a model como uma camada independente. O que torna nossa controller grande e por esse motivo, muitos chamam o MVC de Massive Controller.
Fazendo uma análise baseado nos critérios determinados no início do artigo de uma boa arquitetura, temos os seguintes resultados:
- Fácil de usar. ✓
- Responsabilidades distribuídas. ✗
- Pode ser testada. ✗
Em termos de facilidade de uso, sabemos que está ok quando não pensamos em reuso, mas quando analisamos em responsabilidades distribuídas olhando a camada view e controller, não conseguimos identificar de forma clara essa divisão. Da mesma forma quando tratamos do aspecto relacionado a testes, somente a camada modelo consegue ser testado com qualidade.
O código acima é um exemplo simples de uso do MVC, mas se analisarmos aplicações comerciais utilizando essa arquitetura, sabemos que a camada controller será sobrecarregada com requisições e muitas vezes regras de negócios repetidas devido a dificuldade na questão reuso e afetando no quesito de distribuição de responsabilidades.
Conclusão
Se tratando de usarmo MVC como arquitetura para o aplicação iOS, vimos que dependendo do que precisamos resolver, ela pode se tornar um problema no desenvolvimento/manutenção da aplicação, mas não significa que ela não é utilizável, em um contexto de componente UI por exemplo, ela pode ser "perfeita".
Acredito que aplicações simples, até mesmo POCs podem ser usadas com MVC, pois a velocidade de desenvolvimento é maior e normalmente uma POC deve levar poucos dias para sua conclusão.
No próximo artigo, veremos como funciona a arquitetura MVVM…
