¿Cuál es la diferencia entre MVI en comparación con MVC y MVVM?

¿Hay alguna diferencia entre la arquitectura "más reciente" Modelo-Vista-Intento en comparación con las "más antiguas" como MVC y MVVM?

¿Qué problema aborda MVI? ¿Cuáles son las similitudes con MVC / MVVM? ¿Cuáles son las diferencias?

Ya hay preguntas similares en stackoverflow para MVC / MVV / MVP pero ninguna hasta ahora que explica MVI.

¿Cuál es la diferencia entre MVC y MVVM?

¿Qué son MVP y MVC y cuál es la diferencia?

Desde mi experiencia, cada patrón de arquitectura de esos se inventó para resolver un problema específico que el anterior ignoró o aún no se observó.

MVC - Controlador de vista de modelo

En las aplicaciones de interfaz de usuario, la responsabilidad de mostrar los datos en la pantalla o la lógica de negocios y vincularlos al principio no estaba clara. así que MVC llegó a definir esa responsabilidad con tres componentes, cada uno tiene un propósito y la imagen describe la relación entre esos tres componentes.

Ver: es el componente de la interfaz de usuario que tiene todas las propiedades como color, forma, herramientas para escuchar los eventos de clic ... etc.

Modelo: es el componente que define la lógica empresarial que desea que la vista represente y se comporte en consecuencia.

Controlador: es el que cambia el modelo, por lo que si la vista tiene un nombre, por ejemplo, para guardar, Ver, pasarlo al controlador y luego el controlador manipulará el modelo con las acciones correctas.

MVP - Presentador de vista de modelo

El problema con MVC es que hay un gran acoplamiento entre los tres componentes, si desea cambiar las llamadas de vista, requerirá que actualice el controlador y el Modelo. y eso está claro en la imagen de MVC, la relación entre los tres componentes está muy vinculada, no se puede reemplazar uno de esos componentes sin el otro. Entonces, MVP vino a proporcionar una solución más limpia al problema anterior al separar el Modelo y la Vista, mantener las interacciones entre ellos a través del Presentador, el Presentador es el intermediario al que cada vista y el modelo llaman. Entonces, si desea guardar una lista de películas favoritas, vea la acción de escuchar al usuario (*), luego llame a la función de presentador que actualiza el modelo, luego el modelo le dice al presentador si eso tuvo éxito o no, y el presentador le dice a la vista que muestre mensaje correcto

MVVM - Vista de modelo ViewModel

Con el surgimiento del paradigma reactivo, estaba claro que podemos proporcionar preocupaciones más separadas en las aplicaciones de la interfaz de usuario simplemente observando los cambios y comportándonos en él. así, por ejemplo, hay un clic en la vista que necesita llamar a una API para obtener los últimos programas de televisión.

este clic de vista se observará en ViewModel, ViewModel interactuará con el modelo para obtener los datos y, finalmente, ViewModel publicará esos datos en la vista utilizando otro observador.

en resumen, View observe ViewModel para obtener actualizaciones de la interfaz de usuario y ViewModel observe View para llamar a la acción correcta con el Modelo. El patrón de observador ha demostrado su valía en la lógica de desacoplamiento, así que aquí tienes un nuevo patrón.

Entonces, después de hablar sobre los patrones de arquitectura más populares, cada uno ha intentado desacoplar el código de la interfaz de usuario del código comercial. pero los patrones anteriores no limitan la actualización de la interfaz de usuario con diferentes estados al mismo tiempo.

si tuvo un problema relacionado con la carga que aparece con un mensaje de error al mismo tiempo, comprenderá de lo que estoy hablando, por lo que para mantener el estado de la interfaz de usuario, debe hacer un esfuerzo adicional para ver lo que escribió mal y causar tipo de problemas

MVI - Intención de vista de modelo

MVI se basa en una vieja idea llamada máquina de estados finitos , cualquier sistema o componente tiene un conjunto de estados predecible, es una máquina de estados finitos. en MVI, cualquier actualización de la interfaz de usuario está definida por un nuevo estado, puede encontrar que esto es abrumador, pero imagine que tiene una captura de pantalla para cada cambio de interfaz de usuario, ese es el estado. Puede depurar, probar, reproducir los problemas de estado ahora.

cómo lograr esto, ese es el MVI en la práctica. cualquier interacción del usuario con la interfaz de usuario, se define en MVI por un Intento , el Intento es lo que el usuario necesita de esta acción, podría ser protagonizar una película, actualizar la pantalla, incluso podría estar abriendo la pantalla, en ese caso el Intento es Una intención inicial de mostrar la pantalla con todos los datos requeridos.

qué componente hace que esas intenciones actúen de acuerdo con ellas, lo que usted define ... podría usar un presentador o un modelo de vista, no importa, MVI es más una práctica que usar un nuevo componente intermedio.

Continuaré con ViewModel, ViewModel obtendrá esos intentos, decidirá a qué caso usar (Comportamientos del modelo).

todos los casos de uso pasan por la función de verano en ViewModel, que decide qué estado debe reflejarse en la vista, también le proporciona el estado anterior, por lo que tiene el estado anterior y el nuevo para actualizar la pantalla, lo que reduce las actualizaciones de representación y Ver solo obtienen las nuevas sugerencias para actualizarse.

y finalmente MVI es un flujo unidireccional, comienza con la Vista y termina con la Vista.

... Ver -> Ver Modelo / Presentador -> Modelo -> Ver -> ...

MVI es diferente en la forma de administrar el estado, es una combinación de varias ideas para construir una aplicación más estable y comprobable.

Un gran desglose está aquí: https://academy.realm.io/posts/mvc-vs-mvp-vs-mvvm-vs-mvi-mobilization-moskala/ . En esencia, MVI está tomando las ideas de MVVM (estado de la interfaz de usuario sin estado), separando la lógica y los modelos de negocio, y colocando el marco reactivo encima. Hacer que las cosas sean secuencias de eventos en lugar de acciones discretas, hacer que los elementos receptores sean consumidores de secuencias transformadas en lugar de elementos de presentación, y hacer que el estado sea una cosa desechable de solo lectura sobre la que se actúa explícitamente de una manera muy estructurada.

Esto requiere que adopte un enfoque funcional para escribir su aplicación, especialmente la parte UI / View de las cosas. El estado no se modifica, el nuevo estado se calcula a partir de una intención y una serie de casos de uso. Esto se explica bastante bien aquí: https://proandroiddev.com/mvi-a-new-member-of-the-mv-band-6f7f0d23bc8a .

Su objetivo es abordar la creciente complejidad de las aplicaciones de interfaz de usuario modernas, que tienen una cantidad no trivial de estado del lado del cliente que debe administrarse explícitamente. Como saben los programadores más experimentados, las fallas más complejas provienen del estado que se está modificando de manera inesperada. Esta manipulación de estado puede dar como resultado estados "no válidos" que su aplicación no puede manejar, lo cual es efectivamente una aplicación bloqueada. MVI aborda esto haciendo que las transiciones de estado sean explícitas y cuidadosamente estructuradas para que el sistema nunca llegue a un estado no válido, y el estado siempre es comprensible.