MVC sem C: O que mudará o SwiftUI na arquitetura do aplicativo?

O MVC é um padrão de longa data nos padrões de design usados ​​para escrever aplicativos iOS. A estrutura dos aplicativos iOS criados anteriormente foi baseada em um componente básico, presente em todos os lugares, e é chamado de Controlador . O SwiftUI , que não possui esse componente, foi introduzido no WWDC19 .

O problema com os chamados controladores de exibição massivos deve ser resolvido no SwiftUI. Portanto, você precisa encontrar uma nova maneira de decompor corretamente o código. Vamos dar uma olhada no estado atual da plataforma e pensar em quais paradigmas podemos usar ao desenvolver para iOS13 e versões posteriores.

Arquiteturas unidirecionais e bidirecionais

A maioria das soluções arquitetônicas usadas pelas grandes empresas é bidirecional. Isso significa que você pode pensar nelas como camadas acima uma da outra e elas podem se comunicar transferindo dados para cima e para baixo. Padrões como MVC, Model-View-ViewModel e até muitas implementações do padrão MVVM com coordenadores também são arquiteturas bidirecionais.

Um exemplo do fluxo de dados unidirecional atualmente usado na plataforma iOS é o loop VIP (Presentation-Interactive-Presenter) nas arquiteturas Clean Swift ou Viper. Essas arquiteturas não são puramente unidirecionais. Roteador e executáveis ​​se comunicam com o loop VIP nas duas direções.

Outra coisa que podemos observar é que o padrão MVC e outros padrões criados com base em ele são mais baseados e localizados em uma tela. Geralmente, não há uma estrutura clara para escrever serviços, módulos etc. que interagem com várias partes do aplicativo.

Fluxo de dados no SwiftUI

De acordo com a apresentação da WWDC, o elemento que conectava a exibição e o modelo / estado no SwiftUI era uma determinada classe Store, correspondente ao protocolo BindableObject . Só podemos esperar que não tenhamos aplicativos com um armazenamento massivo que contenha toda a lógica do aplicativo com todos os estados sem nenhuma estrutura clara. Acredito que a comunidade iOS seja bastante avançada e possa fazer melhor nesse sentido.

Se colocarmos MVC e SwiftUI com view e store próximos um do outro, podemos ver quase o mesmo padrão, o que pode levar a problemas semelhantes aos que tivemos com o view controller, mas sem nenhum código padrão que VC tem na natureza.


Se você colocar o MVC e armazenar em um gráfico, eles podem se parecer com isso.

À primeira vista, o Combine pode parecer o padrão de arquitetura usado no SwiftUI. Mas Combine é apenas uma ferramenta para processar valores ao longo do tempo. Da mesma forma, o MVVM usando o RxSwift ainda é o MVVM, apenas um link entre as camadas, que é implementado de várias maneiras.

Arquitetura declarativa para interfaces de usuário declarativas

O SwiftUI pode ser resumido em poucas palavras, como uma interface de usuário declarativa . Eu acredito que mais pode ser alcançado se você pensar fora da caixa e se concentrar na palavra " declarativa ". Os exemplos de arquitetura declarativa mais avançados podem ser encontrados no desenvolvimento de aplicativos front-end. Conceitos como ELM, Redux e Flux podem ser facilmente usados ​​com a infraestrutura SwiftUI e Combine. O Swift já teve várias reimplementações , como o ReSwift , mas ainda seria necessário combinar essas implementações no Combine .


Fluxo de dados ligeiramente modificado no SwiftUI de WWDC19

Eu gostaria de jogar com o SwiftUI desde o início, sem nenhuma dependência, e atualmente estou experimentando no Swift uma simples implementação da arquitetura do ELM. Essa arquitetura combina melhor com os diagramas que a Apple mostrou na WWDC.

Podemos descrever a aplicação através destes padrões arquiteturais:

• Ação é um tipo que descreve todos os eventos que podem ocorrer em um aplicativo. (Em um aplicativo simples, isso pode ser um enum com algum valor associado; em um aplicativo em larga escala, você pode usar muitas estruturas que correspondem ao protocolo de ações.)
• Atualizar (ou redutor no Redux) é uma função simples de limpeza que pega o estado atual e a ação enviada e retorna o novo estado alterado. (Esses recursos não criam efeitos colaterais e podem ser facilmente combinados.)
• State é um tipo que descreve o estado de um aplicativo. (Uma lista simples de tarefas pode usar uma matriz.)

Todos esses três elementos são declarativos e cada um deles é uma pequena parte testável e reutilizável do quebra-cabeça, que juntos compõe todo o aplicativo. O estado é armazenado na Loja e uma visualização pode ser calculada a partir dele.


Estado, ações e atualização para um aplicativo Swift simples.

Para operações assíncronas, podemos introduzir algo como um objeto de middleware no Redux ou Commands no ELM.

Conclusão

Podemos usar qualquer arquitetura conhecida por nós e, quando gradualmente adicionarmos o SwiftUI aos aplicativos existentes, essa será uma abordagem confiável e segura. Caso um novo aplicativo seja implementado usando apenas o SwiftUI, você poderá usar uma abordagem mais aberta e tentar outra coisa.

Se você pensa em desenvolver um aplicativo usando o SwiftUI em um futuro próximo, recomendo prestar atenção a alguns pontos:

• A Apple não fornece orientação detalhada sobre arquitetura de aplicativos, o que significa que nós, como comunidade de programadores, temos muitas oportunidades de inovação e implementação de novas abordagens.
• Definitivamente, veremos uma escala muito mais ampla de várias bases de código, pois o orifício deixado após o controlador de exibição deve ser preenchido.
• Mantenha aberto e não tenha medo de começar do zero.

Minhas experiências podem ser encontradas no playground Swift (para comparação, apresenta a implementação e o uso do UIKit e SwiftUI, o mesmo aplicativo).

Próximas etapas

Existem várias maneiras de tirar proveito, mas estou fortemente inclinado a finalmente tentar uma abordagem muito mais funcional para o desenvolvimento de aplicativos. Assim, você pode ver algumas soluções interessantes da comunidade, e ainda temos muito tempo em que podemos usar o SwiftUI em nosso trabalho diário; portanto, ainda há tempo para experimentação e não há pressão sobre nós.

Planejo escrever mais sobre essa implementação de uma arquitetura unidirecional e funcional. Espero que em breve eu possa usar isso em algum pequeno projeto real, para que eu possa lhe dizer mais sobre como essa abordagem é viável e tem problemas de desempenho em projetos de grande escala.