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.