Qual é a diferença entre o MVI comparado ao MVC e MVVM

Existe uma diferença entre a arquitetura "mais nova" da Model-View-Intent em comparação com as "mais antigas" como MVC e MVVM?

Qual é o problema do MVI? Quais são as semelhanças com o MVC / MVVM? Quais são as diferenças?

Já existem perguntas semelhantes no stackoverflow para MVC / MVV / MVP, mas nenhuma até agora explica o MVI.

Qual é a diferença entre MVC e MVVM?

O que são MVP e MVC e qual é a diferença?

da minha experiência, cada padrão de arquitetura foi inventado para resolver um problema específico que o anterior ignorou ou ainda não foi observado.

MVC - Model View Controller

em aplicativos de interface do usuário, a responsabilidade de renderizar os dados na tela ou a lógica de negócios e uni-los no início não era clara. então o MVC passou a definir essas responsabilidades para três componentes, cada um com um objetivo, e a figura descreve a relação entre esses três componentes.

Ver - é o componente da interface do usuário que possui todas as propriedades, como cor, forma, ferramentas para ouvir os eventos de clique. Etc.

Modelo - é o componente que define a lógica de negócios que você deseja que a visualização renderize e se comporte de acordo.

Controller - é quem altera o modelo; portanto, se a view tiver um nome, por exemplo, para salvar, View passará para o controller e o controller manipulará o modelo com as ações corretas.

MVP - apresentador de visualização de modelo

o problema com o MVC de que há um ótimo acoplamento entre os três componentes; se você quiser alterar as chamadas de exibição, será necessário atualizar o controlador e o modelo. e isso fica claro pela imagem do MVC, a relação entre os três componentes está muito ligada, você não pode substituir um desses componentes sem o outro. Portanto, o MVP veio para fornecer uma solução mais limpa para o problema anterior, separando o Modelo e a Visualização, mantendo as interações entre eles através do Presenter, o Presenter é o intermediário que cada visualização e o modelo chamam. Portanto, se você deseja salvar uma lista de filmes favoritos, o View ouve a ação do usuário (*), chame a função do apresentador que atualiza o modelo e, em seguida, o modelo informa ao apresentador se foi bem-sucedido ou não e o Presenter diz ao View para mostrar o mensagem certa.

MVVM - Model View ViewModel

com o surgimento do paradigma reativo, ficou claro que podemos fornecer preocupações mais separadas nos aplicativos de interface do usuário apenas observando as mudanças e nos comportando. por exemplo, há um clique na visualização que precisa chamar uma API para obter os programas de TV mais recentes.

esse clique na visualização será observado no ViewModel, o ViewModel interage com o modelo para obter os dados e, finalmente, o ViewModel publica esses dados na visualização usando outro observador.

Em resumo, o View observe o ViewModel para obter atualizações da interface do usuário e o ViewModel observa o View para chamar a ação correta com o Model. O padrão observador provou ser digno em desacoplar a lógica, então aqui está um novo padrão.

Então, depois de falar sobre os padrões de arquitetura mais populares, cada um tentou separar o código da interface do usuário do código comercial. mas os padrões anteriores não vinculam a atualização da interface do usuário com estados diferentes ao mesmo tempo.

se um problema relacionado ao carregamento aparecer com uma mensagem de erro exibida ao mesmo tempo, você entenderá o que estou falando; portanto, para manter o estado da interface do usuário, você deve fazer um esforço extra olhando o que escreveu errado causando esses tipo de problemas.

MVI - Intenção de visualização do modelo

O MVI é baseado em uma idéia antiga chamada máquina de estados finitos , qualquer sistema ou componente tem previsível, conjunto de estados é uma máquina de estados finitos. no MVI, qualquer atualização na interface do usuário é definida por um novo estado; você pode achar isso impressionante, mas imagine que você tenha uma captura de tela para cada vez que a interface do usuário for alterada, esse é o estado. você pode depurar, testar, reproduzir os problemas de estado agora.

como conseguir isso, esse é o MVI na prática. qualquer interação do usuário com a interface do usuário é definida no MVI por um Intent , Intent é o que o usuário precisa dessa ação, pode estrelar um filme, atualizar a tela, até abrir a tela; nesse caso, o Intent é uma intenção inicial de mostrar a tela com todos os dados necessários.

qual componente faz com que os Intents ajam de acordo com eles, que o que você define ... você pode usar um Presenter ou um ViewModel, não importa, o MVI é mais uma prática do que usar um novo componente intermediário.

Continuarei com o ViewModel, o ViewModel obterá essas intenções e decidirá qual o caso a ser chamado (comportamentos de modelo).

todos os casos passam pela função summer no ViewModel, que decide qual estado deve ser refletido no View, também fornece o estado anterior, assim você tem o estado anterior e o novo para atualizar a tela, o que reduz as atualizações de renderização , e View recebem apenas as novas dicas para se atualizarem.

e, finalmente, o MVI é um fluxo direcional uni, começa com a visualização e termina com a visualização.

... View -> ViewModel / Presenter -> Model -> View -> ...

O MVI é diferente na maneira de gerenciar o estado, é uma combinação de várias idéias para criar aplicativos mais estáveis ​​e testáveis.

Uma grande quebra está aqui: https://academy.realm.io/posts/mvc-vs-mvp-vs-mvvm-vs-mvi-mobilization-moskala/ . Na essência, o MVI está pegando as idéias do MVVM (estado da UI sem estado), separando modelos e lógica de negócios e colocando a estrutura reativa em cima dele. Tornar as coisas fluxos de eventos em vez de ações discretas, tornar os elementos receptores consumidores de fluxos transformados em vez de elementos de apresentação e tornar o estado uma coisa descartável e de somente leitura, com ação explícita de maneira muito estruturada.

Isso requer que você adote uma abordagem funcional para escrever seu aplicativo, especialmente a parte UI / View das coisas. O estado não é modificado, o novo estado é calculado a partir de uma intenção e uma série de casos de uso. Isso é bastante bem explicado aqui: https://proandroiddev.com/mvi-a-new-member-of-the-mv-band-6f7f0d23bc8a .

Destina-se a abordar a crescente complexidade dos aplicativos de interface do usuário modernos, que possuem uma quantidade não trivial de estado do lado do cliente que precisa ser gerenciado explicitamente. Como muitos programadores experientes sabem, as falhas mais complexas vêm do estado que está sendo modificado de maneira inesperada. Essa manipulação de estado pode resultar em estados "inválidos" que seu aplicativo não pode manipular, o que é efetivamente um aplicativo com falha. O MVI resolve isso, tornando as transições de estado explícitas e cuidadosamente estruturadas para que o sistema nunca chegue a um estado inválido, e o estado é sempre compreensível.