VIPER Vs MVVM, el patrón Arquitectónico lo es todo.
El tema de las Arquitecturas en el desarrollo de aplicaciones móviles siempre ha sido muy importante, aunque a veces les quitemos importancia por el tamaño del proyecto. En artículos anteriores he escrito de VIPER, MVVM, MVC, MVP entre otros.
No obstante, algunos grupos de personas consideran que el patrón MVVM no escala bien los proyectos, mientras que otros comentan que VIPER puede llegar a ser abrumador y un infierno para entender. Pero el caso es que ambos patrones arquitectónicos se parecen y tienen cosas en común, pero claro está cada uno tiene características propias que hace que sea la elección de los desarrolladores sea VIPER o MVVM.
Mientras que VIPER suele tener más éxito en los desarrolladores de iOS, en los últimos años, algunos desarrolladores de software han comenzado a implementar este patrón en Android, ya que, aún presentando cierta complejidad a la hora de darle uso, sigue manteniendo un patrón limpio que ayuda a presentar un código organizado.
Por otro lado MVVM presta mucha atención a las interacciones que suceden en la vista, en otras palabras, a la interacción con el usuario. Da una diferenciación entre capas suficiente que al final significa desarrollar una aplicación móvil sin demasiada complejidad, ya que, se puede trabajar en dichas capas con facilidad, pero vamos a ello y vemos su estructura.
Arquitectura VIPER
Sin embargo VIPER se usa aplicaciones con amplia escalabilidad ya que este patrón Arquitectonico de software respeta los principios SOLID haciendo especial énfasis en el principio de simple responsabilidad.
Pero, ¿Qué es VIPER?
Una arquitectura de software que respeta al máximo el principio de simple responsabilidad de SOLID. Sirva para hacer una aplicación mas modular y fácil de mantener. Esta arquitectura esta totalmente orientada a protocolos que es algo que debemos controlar en swift.
Un módulo de VIPER tiene unos componentes que los forman: View, Presenter, Interactor, Entity, Router. Esta separación del modelo y vista provocan un abstracción que permite que una aplicación de gran volumen sea fácil de mantener, testable y limpia. Comenzaré con un orden de abstracción de mayor a menor que nos permitirá entender más fácil el patrón.
Entity
Este es sin duda el componente mas abstracto de VIPER ya que no debería tener más de las propiedades, claro está sin relación con vistas ni ningún otro componente que no se un entity.
Interactor
El componente del Interactor tiene una responsabilidad básica aunque importante. Obtiene los datos de los servicios o bases de datos, crea los objetos de las entidades y se los proporciona al Presenter. Es importante destacar que esta capa no tiene ninguna relación con la vista, de hecho no debería tener que importar UIKit, con el Foundation debería ser suficiente. Tampoco debe tener ninguna lógica más que la necesaria para transformar las entidades y obtener datos de un proveedor de datos (provider).
Presenter
El presenter es el componente mas importante de VIPER, junto con el interactor ya que actúa como puente entre los módulos de VIPER y contiene la lógica que solicita la vista y éste reacciona a ellos pidiendo los datos necesarios al interactor, algunos desarrolladores consideran esto como la lógica de negocio (que pensáis vosotros ??), en sentido opuesto una vez recibido los datos del interactor, aplica la lógica y prepara el contenido para pasarselo a la vista y que ésta lo muestre.
View
Básicamente es un ViewController que contiene subvistas implementadas ya sea con el uso de Xib’s o programáticamente. La vista tiene como única responsabilidad mostrar en la interfaz la información que llega desde el presenter y recoger los eventos del usuario delegándolos al presentador.
Router
Es el encargado de la navegación y de pasar los datos entre las vistas. Debe implementar un protocolo que incluya todas las posibilidades de navegación entre módulos. Como estamos en iOS para realizar la navegación el router tiene que conocer a la View(ViewController).
¿Cuando usar VIPER?
Debemos usar VIPER cuando nos encontramos con un proyecto que vaya a ser muy escalable. Además la Arquitectura de VIPER ayuda a trabajar a mas de un desarrollador en la misma App. Gracias a la Modularización, podemos realizar UnitTest con mas facilidad y encontrar errores con las eficiencia, añadir nuevas funcionalidades fácilmente, el código estará mas ordenado y limpio, existirán menos conflictos con los demás desarrolladores.
¿Cuando no usar VIPER?
Normalmente en proyectos que no van a tener una gran escalabilidad y tardaríamos mas tiempos en desarrollar la Arquitectura que la propia App.
Arquitectura MVVM
MVVM es para mi gusto el futuro de las arquitecturas de desarrollo de aplicaciones móviles. Llevo ya tiempo usando este tipo de arquitectura como la de VIPER y es bastante más cómoda con el paso del tiempo, que es su principal ventaja sobre VIPER. También respeta los principios SOLID, es fácilmente testable y una de sus muchas ventajas es que se usa tanto en iOS como en Android, ya que VIPER no les llegó a gustar a los desarrolladores de Android por su complejidad.
Model
Este elemento es común en todas las arquitecturas de desarrollo. Se trata de ya se una class o una struct que define las propiedades de un objeto. la definición del modelo básicamente es que debe ser una estructura sencilla, sin funcionalidad, únicamente propiedades. y en caso de tener que añadir algún tipo de funcionalidad las separemos por extensiones dentro del mismo archivo o en archivos separados, soy más partidario de la primera opción, además esta estructura como ventaja podemos hacer uso de las ventajas de swift, podemos implementar el protocolo Codable.
ViewModel
La principal tarea del viewModel es ejecutar la lógica de una pantalla. también tiene la función de realizar las llamadas a los servicios REST y de extraer los datos de las bases de datos. Aunque como recomendación es mejor separar estas consultas en una capa tipo Provider, para centralizar funcionalidaes. El viewModel tiene contacto directo con el Modelo y se comunica con la vista mediante protocolos. También tiene contacto con el router para hacer cambios de pantallas
View
La vista es sencilla, ya que no debe tener lógica. Sólo tiene las funciones de modificar los elementos de la vista según ordene el ViewModel y de pasar las interacciones de la vista al viewModel para que este procese y actúe en consecuencia, creo que es importante que la vista conozca directamente las viewModel y evitar un protocolo intermedio, no obstante es una muy buen práctica usar protocolos para las comunicaciones entre las distintas capas. El problema es que se vuelve pesado el desarrollo y puede llegar a resultar incómodo y no cambia tanto el resultado está claro.
Router
El router tambíen es un elemento común en arquitectiras y se encarga básicamente de la transición entre pantallas, de formar y relacionar a los elementos de la arquitectura y de proporcionar a cada elemento los datos necesarios para formar la pantalla.
En Xcode podemos realizar Templates para crear nuestros proyectos con mayor agilidad y rapidez, ánimo developers a por las arquitecturas.
