MVP vs MVC vs MVVM vs VIPER. O que é melhor para o desenvolvimento iOS?

Da mesma forma que toda casa tem um porão sólido, todo projeto de software tem uma arquitetura de software na qual é construída e cada projeto tem sua própria estrutura de aplicativo. Os tipos de padrões de arquitetura podem variar, mas existem 4 mais comumente usados ​​- aqueles que todo o mundo de TI critica continuamente, mas continua usando ao mesmo tempo: MVC, MVP, MVVM e Viper (o último como padrão de arquitetura iOS principalmente) . A comparação desses padrões e a escolha de um ajuste melhor para cada caso de projeto escrito em Swift serão descobertos mais adiante neste artigo.

Seguindo a ordem cronológica das coisas, uma vez que os primeiros padrões de design de software apareceram, os problemas comuns desses padrões de arquitetura de desenvolvimento ios não demoraram muito para chegar.

Por exemplo, o problema da comunicação servidor-cliente - como um interage com o outro? Ou um diferente - o problema de separar a lógica de negócios do aplicativo da lógica do aplicativo; como este deve se comportar em termos de arquitetura da aplicação? Devido a eles, vários padrões de design para diferentes camadas de arquitetura viram o mundo; os mais conhecidos entre eles são:

- Padrão de design singleton.

Esse padrão permite que uma classe seja aplicada a apenas um objeto e essa opção é útil quando uma quantidade limitada de instâncias (ou apenas uma instância) é aprovada pelo sistema.

- Padrão de design do decorador.

Em contraste com o singleton, este padrão, (alternativamente chamado Wrapper junto com o padrão Adaptador), permite que um comportamento específico seja adicionado a um único objeto (estaticamente ou dinamicamente), e tudo isso sem afetar o comportamento de outros objetos. um compartilha uma classe com.

- Padrão de design da ponte.

Introduzido pela famosa Gang of Four - autores do livro "Design Patterns", este padrão arquitetônico "usa encapsulamento, agregação e pode usar herança para separar responsabilidades em classes diferentes. a programação se torna muito útil porque as alterações no código de um programa podem ser feitas facilmente com o mínimo de conhecimento prévio do programa. [Fonte: Wiki]

Apesar de esses padrões serem bem diferentes, os problemas comuns dos escritores de código ocorreram com cada um deles; por exemplo, com a “massividade” de Singleton. Singleton é muito global, pois as dependências de seu código estão profundamente ocultas em seu aplicativo, em vez de serem expostas nas interfaces. É por isso que, durante o processo de desenvolvimento de software, novos padrões aparecem constantemente.

Os 4 padrões mais comumente usados ​​são MVC, MVP, MVVM e VIPER (para iOS principalmente).

Desenvolvidos na mesma ordem do listado, todos eles têm seus próprios benefícios e falhas, causando inúmeras disputas sobre onde aplicar cada um. Prestar um pouco mais de atenção às práticas recomendadas que eles implementam pode esclarecer um pouco as coisas.

Padrão MVC

O avô de todos os padrões de software, introduzidos pela primeira vez no início dos anos 1970 por um cientista da computação norueguês Trygve Reenskaug, Módulo - Visualização - Controlador, amplamente conhecido como MVC, é uma das primeiras abordagens de padrão da Programação Orientada a Objetos.

A parte View é responsável por mostrar tudo para o usuário do sistema (interfaces de mobile ou web app, etc.). O modelo é geralmente responsável pelos bancos de dados, entidades de negócios e demais dados. Por sua vez, o Controller regula o trabalho do Model, os dados fornecidos ao banco de dados, são exibidos desde o referido banco de dados até a parte View e vice-versa.

Por mais universal que o modelo MVC possa ser, os dois maiores concorrentes - Apple e Google têm seus próprios padrões que representam o sistema Model - View - Controller. O problema do sistema da Apple está na conexão estreita entre as partes do View e do Controller, quase ao ponto de unir o View & Controller e deixar a parte Model separada.

Consequentemente, isso resulta em um processo de teste insatisfatório - apenas o modelo pode ser examinado, V&C (devido à conexão apertada que eles têm) não pode ser testado de forma alguma.

A conexão robusta entre os segmentos Controller e View provou ser verdadeiramente “insalubre” quando se trata de software, portanto, um novo padrão apareceu no mundo em breve.

Padrão MVP.

Muitos de nós já ouvimos esse atalho no contexto de Produto Mínimo Viável, mas em termos de engenharia de software significa algo diferente. O padrão Model View Presenter tem alguns pontos-chave, formando um vasto abismo entre ele e o MVC:

Modelo MVP

• A visualização é mais fracamente acoplada ao modelo. O Apresentador é responsável por vincular o Modelo à Visualização.

• Mais fácil de testar a unidade porque a interação com a visualização é feita por meio de uma interface.

• Normalmente, Exibir para o apresentador = mapear um a um. As visualizações complexas podem ter vários apresentadores.

Padrão MVC

• Os controladores são baseados em comportamentos e podem ser compartilhados entre visualizações

• Pode ser responsável por determinar qual vista exibir
  [Fonte: Infragística]

Nesse arranjo, as funções de Model permanecem as mesmas; O apresentador é responsável pela lógica de negócios respectivamente. A parte V é aquela de particular interesse - uma vez que é dividida em duas partes View e View Controller, que têm autoridade para interação. Quando há uma questão MVVM vs MVC, o sistema deste tipo resolve o problema de um “vício pesado” que os modos View e Controller costumavam ter no padrão MVC.

O obstáculo de teste também é resolvido neste caso, como modelo, visualização com interação do usuário e partes do apresentador - todos eles poderiam ser testados.
A inconveniência ainda existente é da parte do Apresentador - embora muito grande, mas leva em consideração todas as lógicas de negócios existentes. É por isso que o próximo ato entrou em cena, chamado ...

Padrão MVVM

Um padrão de arquitetura de software Model-View-ViewModel foi criado em 2005 por John Gossman, um dos arquitetos da Microsoft. Os três componentes principais do modelo MVVM, respectivamente, são:
Modelo é “uma implementação do modelo de domínio do aplicativo que inclui um modelo de dados junto com a lógica de negócios e validação. Exemplos de objetos de modelo incluem repositórios, objetos de negócios, objetos de transferência de dados (DTOs), Plain Old CLR Objects (POCOs) e entidades geradas e objetos de proxy. ” [Fonte: Microsoft]

Exibir é novamente tudo o que o usuário é capaz de ver - o layout, a estrutura e a aparência de tudo na tela. Basicamente, dentro do aplicativo, seria a página do aplicativo. View obtém e envia atualizações apenas para ViewModel, excluindo toda a comunicação entre esta parte e o próprio Model.

ViewModel deve ser uma “cadeia de interconexão” entre os componentes do sistema View e Model, e sua função principal é lidar com a lógica da View. Normalmente, o modelo de exibição interage com o modelo chamando métodos nas classes do modelo. O modelo de visão então fornece dados do modelo em uma forma que a visão pode usar facilmente, como afirma a Microsoft.

A principal diferença entre o MVC e o iOS MVVM é que o padrão de distribuição do MVVM é melhor do que no MVC listado anteriormente, mas quando comparado ao MVP também está muito sobrecarregado. Testar é um assunto de particular importância aqui, já que ao escrever o código, você não pode garantir que todo o projeto funcionará corretamente - os testes, na nota brilhante, ajudam a garantir que funcionará.

A evolução dos próximos padrões de arquitetura foi lançada recentemente e agora é a abordagem de arquitetura de software mais recente.

Arquitetura iOS VIPER

Em busca da melhor solução arquitetônica para entregar, os desenvolvedores de iOS em todo o mundo se depararam com uma abordagem chamada “Arquitetura Limpa”, apresentada por Uncle Bob nos Clean Coders - uma plataforma bem conhecida que fornece sessões de treinamento para profissionais de software em todo o mundo.

O Clean Architecture divide a estrutura lógica do aplicativo em vários níveis de responsabilidade. Por sua vez, essa “separação” resolve os problemas de dependência rígida e aumenta a disponibilidade de teste de todos os níveis.

VIPER para desenvolvimento ios

VIPER é uma realização da Arquitetura Limpa para aplicativos construídos em iOS. Como regra comum para todos os nomes de padrões, é também um backronym, para View, Interactor, Presenter, Entity e Routing. Cada uma das partes do VIPER é responsável por um determinado elemento, em particular:

1. View é responsável por espelhar as ações do usuário com uma interface

2. As responsabilidades do apresentador dentro do padrão VIPER são bastante limitadas - ele recebe as atualizações da Entidade, mas não envia nenhum dado para ela;

3. Interator é a parte do sistema que realmente corresponde às Entidades. Este esquema funciona na seguinte direção: o Apresentador informa o Interator sobre as mudanças no modelo de Visualização, então o Interator contata a parte Entidade e, com os dados recebidos da Entidade, o Interator retorna ao Apresentador, que comanda a Visualização para espelhá-lo para um usuário. Todos os modelos de dados, todas as entidades e todos os sites estão conectados à parte Interator.

4. Entidade consiste em objetos controlados pelo Interator (títulos, conteúdo etc.). Ela nunca interage diretamente com o Apresentador, apenas via I-part.

5. O roteamento (ou Wireframe, como às vezes é chamado) é responsável pela navegação entre todas as telas e, essencialmente, pelo roteamento. Wireframe controla os objetos de UIWindow, UINavigationController e assim por diante.

Particularmente no sistema de arquitetura iOS, tudo é construído sobre uma estrutura chamada UIkit, que inclui todos os componentes do Apple MVC, mas sem uma conexão rígida que costumava deixar os programadores loucos antes.

O módulo VIPER também é benéfico quando se trata de testes de unidade, pois a grande distribuição do padrão permite que você teste todos os funcionais disponíveis. De muitas maneiras, essa foi a principal dificuldade que os desenvolvedores enfrentaram com os padrões de software MVC, MVP e MVVM anteriores.

Para coroar tudo.

Todos esses 4 padrões de design de software são frequentemente chamados de um dos melhores padrões de arquitetura para desenvolvimento iOS, embora todos eles sejam menos do que ideais e definitivamente não são usados ​​universalmente para cada projeto que você desenvolver. No lado sombrio, aqui está uma pequena lista de problemas que cada padrão tem:

• MVC, MVP, MVVM - todos eles têm esse problema de “conexão rígida”, o que torna a introdução de atualizações para o desenvolvimento e testá-las depois uma tarefa bastante difícil de realizar.

• VIPER vs MVVM, MVC ou MVP , é considerado um caso vencedor; embora, apesar de sua alta flexibilidade e grande testabilidade, também tenha muitas nuances que são difíceis de gerar.

Existe uma solução 100% sólida? Não realmente, mas para cada um de seus projetos, um desses 4 padrões de aplicativos iOS pode ser exatamente o que você precisa. E se não for, então uma mistura de dois seria. Ou talvez três. Diz-se que a fortuna favorece os ousados, então por que você não brinca com os padrões de design de software com ousadia?

Escrito por Max Mashkov e Elina Bessarabova.