MVP vs MVC vs MVVM vs VIPER. ¿Qué es mejor para el desarrollo de iOS?

Al igual que cada casa tiene un sótano sólido, cada proyecto de software tiene una arquitectura de software sobre la que se basa y cada proyecto tiene su propia estructura de aplicación. Los tipos de patrones arquitectónicos pueden variar, pero hay 4 de los más utilizados: los que todo el mundo de TI critica continuamente pero sigue usando al mismo tiempo: MVC, MVP, MVVM y Viper (el último como patrón de arquitectura iOS principalmente) . La comparación de estos patrones y la elección de un ajuste mejor para el caso de cada proyecto escrito por Swift se descubrirá más adelante en este artículo.

Siguiendo el orden cronológico de las cosas, una vez que aparecieron los primeros patrones de diseño de software, los problemas comunes de esos patrones de arquitectura de desarrollo de iOS no tardaron en llegar.

Por ejemplo, el problema de la comunicación servidor-cliente: ¿cómo interactúa uno con otro? O uno diferente: el problema de separar la lógica empresarial de la aplicación de la lógica de la aplicación; ¿Cómo debería funcionar este en términos de arquitectura de la aplicación? Debido a ellos, varios patrones de diseño para diferentes capas de arquitectura han visto el mundo; los más conocidos entre ellos son:

- Patrón de diseño singleton.

Este patrón permite aplicar una clase a un solo objeto, y esta opción es útil cuando el sistema aprueba una cantidad limitada de instancias (o solo una instancia).

- Patrón de diseño de decorador.

A diferencia de singleton, este patrón, (alternativamente llamado Wrapper junto con el patrón Adapter), permite agregar un comportamiento específico a un solo objeto (ya sea de forma estática o dinámica), y todo esto sin afectar el comportamiento de otros objetos este uno comparte una clase con.

- Patrón de diseño de puente.

Introducido por primera vez por la notoria Gang of Four, autores del libro "Design Patterns", este patrón arquitectónico "usa encapsulación, agregación y puede usar la herencia para separar responsabilidades en diferentes clases. la programación se vuelve muy útil porque los cambios en el código de un programa se pueden hacer fácilmente con un conocimiento previo mínimo del programa. [Fuente: Wiki]

A pesar de que esos patrones son bastante diferentes, los problemas comunes de los escritores de código han ocurrido con cada uno de ellos; por ejemplo, con la “masividad” de Singleton. Singleton es demasiado global, ya que las dependencias de su código están ocultas profundamente dentro de su aplicación, en lugar de estar expuestas en las interfaces. Es por eso que durante el proceso de desarrollo de software aparecen constantemente nuevos patrones.

Los 4 patrones más utilizados son MVC, MVP, MVVM y VIPER (principalmente para iOS).

Desarrollados en el mismo orden en que se enumeran, todos tienen sus propios beneficios y defectos, lo que genera numerosas disputas sobre dónde aplicar cada uno. Prestar un poco más de atención a las mejores prácticas que implementan podría aclarar un poco las cosas.

Patrón MVC

El abuelo de todos los patrones de software, introducido por primera vez a principios de la década de 1970 por un informático noruego Trygve Reenskaug, Module - View - Controller, ampliamente conocido como MVC, es uno de los primeros enfoques de patrones de la programación orientada a objetos.

La parte Ver es responsable de mostrar todo para el usuario del sistema (interfaces de aplicación móvil o web, etc.). El modelo es generalmente responsable de las bases de datos, entidades comerciales y resto de datos. A su vez, Controller regula el trabajo del Modelo, los datos aportados a la base de datos, la visualización desde la base de datos mencionada a la parte Vista y viceversa.

Por universal que sea el modelo MVC, los dos mayores competidores, Apple y Google, tienen sus propios patrones que representan el sistema Modelo - Vista - Controlador. El problema que tiene el sistema de Apple radica en la estrecha conexión entre las partes View y Controller, casi hasta el punto de haber unido View & Controller, y dejando la parte Model separada.

En consecuencia, da como resultado un proceso de prueba deficiente: solo se pudo examinar el modelo, V&C (debido a la estrecha conexión que tienen) no se puede probar en absoluto.

La sólida conexión entre los segmentos Controller y View demostró ser realmente "insalubre" en lo que respecta al software, por lo que pronto apareció un nuevo patrón.

Patrón MVP.

Muchos de nosotros hemos escuchado este atajo en el contexto del producto mínimo viable, pero en términos de ingeniería de software significa algo diferente. El patrón Model View Presenter tiene algunos puntos clave, formando un gran abismo entre él y MVC:

Modelo MVP

• La vista está acoplada de forma más flexible al modelo. El presentador es responsable de vincular el modelo a la vista.

• Es más fácil realizar pruebas unitarias porque la interacción con la vista se realiza a través de una interfaz.

• Por lo general, Ver al presentador = mapa uno a uno. Las vistas complejas pueden tener varios presentadores.

Patrón MVC

• Los controladores se basan en comportamientos y se pueden compartir entre vistas

• Puede ser responsable de determinar qué vista mostrar
  [Fuente: Infragistics]

En esta disposición, las funciones de Model permanecen iguales; El presentador es responsable de la lógica empresarial respectivamente. La parte V es de particular interés, ya que está dividida en dos partes View y View Controller, que tienen autoridad para la interacción. Cuando hay una pregunta MVVM vs MVC, el sistema de este tipo resuelve el problema de una “adicción pesada” que solían tener los modos Ver y Controlador en el patrón MVC.

El obstáculo de la prueba también se resuelve en este caso, como las partes Modelo, Vista con interacción del usuario y Presentador; todas ellas podrían probarse.
El inconveniente aún existente está en la parte de Presenter, aunque es demasiado masivo, pero tiene en cuenta todas las lógicas comerciales existentes. Por eso entró en juego el siguiente acto, llamado ...

Patrón MVVM

En 2005, John Gossman, uno de los arquitectos de Microsoft, creó un patrón arquitectónico de software Model-View-ViewModel . Los tres componentes centrales del modelo MVVM respectivamente son:
El modelo es “una implementación del modelo de dominio de la aplicación que incluye un modelo de datos junto con la lógica empresarial y de validación. Los ejemplos de objetos modelo incluyen repositorios, objetos comerciales, objetos de transferencia de datos (DTO), Objetos CLR antiguos simples (POCO) y objetos de entidad y proxy generados ". [Fuente: Microsoft]

Ver es nuevamente todo lo que el usuario es capaz de ver: el diseño, la estructura y la apariencia de todo en la pantalla. Básicamente, dentro de la aplicación sería la página de la aplicación. View obtiene y envía actualizaciones solo a ViewModel, excluyendo toda la comunicación entre esta parte y el modelo en sí.

Se supone que ViewModel es una "cadena de interconexión" entre los componentes del sistema View y Model, y su función principal es manejar la lógica de View. Normalmente, el modelo de vista interactúa con el modelo invocando métodos en las clases del modelo. El modelo de vista luego proporciona datos del modelo en una forma que la vista puede usar fácilmente, como afirma Microsoft.

La principal diferencia entre MVC y MVVM de iOS es que el patrón de distribución de MVVM es mejor que en el MVC mencionado anteriormente, pero en comparación con MVP también está sobrecargado enormemente. Las pruebas son un asunto de particular importancia aquí, ya que mientras se escribe claramente el código, no puede garantizar que todo el proyecto funcione correctamente; las pruebas, en la nota brillante, ayudan a garantizar que así sea.

La siguiente evolución de los patrones arquitectónicos se ha lanzado recientemente y ahora es el enfoque arquitectónico de software más reciente.

Arquitectura de iOS VIPER

Buscando la mejor solución arquitectónica para ofrecer, los desarrolladores de iOS de todo el mundo se toparon con un enfoque llamado "Arquitectura limpia", presentado por el tío Bob en Clean Coders, una conocida plataforma que ofrece sesiones de formación para los profesionales del software en todo el mundo.

Clean Architecture divide la estructura lógica de la aplicación en varios niveles de responsabilidad. A su vez, esta "separación" resuelve los problemas de dependencia y aumenta la disponibilidad de pruebas de todos los niveles.

VIPER para el desarrollo de ios

VIPER es una realización de Clean Architecture para aplicaciones creadas en iOS. Como regla común para todos los nombres de los patrones, también es un backronym, para View, Interactor, Presenter, Entity y Routing. Cada una de las partes del VIPER es responsable de un determinado elemento, en particular:

1. View es responsable de reflejar las acciones que realiza el usuario con una interfaz

2. Las responsabilidades del presentador dentro del patrón VIPER son bastante limitadas: recibe las actualizaciones de la entidad, pero no le envía ningún dato;

3. Interactor es la parte del sistema que realmente se corresponde con las Entidades. Este esquema funciona en la siguiente dirección: Presenter informa a Interactor sobre los cambios en el modelo de Vista, luego Interactor se pone en contacto con la parte de Entidad y, con los datos recibidos de Entity Interactor, vuelve a Presenter, que ordena a View que lo refleje para un usuario. Todos los modelos de datos, todas las entidades y todos los sitios web están conectados a la parte Interactor.

4. La entidad está formada por objetos controlados por Interactor (títulos, contenido, etc.). Nunca interactúa directamente con Presenter, solo a través de I-part.

5. El enrutamiento (o Wireframe, como se le llama a veces) es responsable de la navegación entre todas las pantallas y, esencialmente, del enrutamiento. Wireframe controla los objetos de UIWindow, UINavigationController, etc.

Particularmente dentro del sistema arquitectónico iOS, todo se basa en un marco llamado UIkit, que incluye todos los componentes de Apple MVC, pero sin una conexión estrecha que solía volver locos a los programadores.

El módulo VIPER también es beneficioso cuando se trata de pruebas unitarias, ya que la gran distribución del patrón le permite probar todas las funciones disponibles. En muchos sentidos, esta fue la principal dificultad que enfrentaron los desarrolladores con los patrones de software MVC, MVP y MVVM anteriores.

Para coronarlo todo.

Todos estos 4 patrones de diseño de software a menudo se denominan uno de los mejores patrones de arquitectura para el desarrollo de iOS, aunque todos ellos son menos que ideales y definitivamente no se usan universalmente para todos y cada uno de los proyectos que desarrolle. En el lado sombrío, aquí hay una breve lista de problemas que tiene cada patrón:

• MVC, MVP, MVVM : todos ellos tienen este problema de "conexión estrecha", lo que hace que la introducción de actualizaciones al desarrollo y su posterior prueba sea una tarea bastante difícil de lograr.

• Se cree que VIPER vs MVVM, MVC o MVP es un caso ganador; aunque a pesar de su alta flexibilidad y gran testabilidad también tiene muchos matices que son difíciles de generar.

¿Existe una solución 100% sólida? En realidad, no, pero para cada uno de sus proyectos, uno de estos 4 patrones de aplicaciones de iOS puede ser justo lo que necesita. Y si no lo es, entonces sería una mezcla de dos. O incluso quizás tres. Se dice que la fortuna favorece a los audaces, así que ¿por qué no juegas con los patrones de diseño de software audazmente?

Escrito por Max Mashkov y Elina Bessarabova.