Al desarrollar una aplicación iOS es importante pensar qué arquitectura debemos utilizar.
La mayoría de los desarrolladores usan el patrón sugerido por Apple: la arquitectura denominada MVC (Model-View-Controller). Sin embargo, como muchos otros patrones, el MVC tiene sus fallos:
Por un lado, debido a su simplicidad, lleva incluso a los programadores más
experimentados a poner código que no pertenezca a una vista ni a un modelo en la lógica del controlador, generando otros de gran tamaño y vistas y modelos realmente compactos, o lo que es peor, muchas dependencias.
Por ello, en esta publicación veremos VIPER, una de las alternativas de tendencia a MVC que puede ayudarnos a superar sus limitaciones, así como a mantener nuestro código modular y bien organizado, mejorando el proceso de desarrollo.
¿Qué es VIPER?
VIPER son las siglas de View, Interactor, Presenter, Entity, Router.
Y es básicamente un enfoque que implementa el principio de responsabilidad única para crear una estructura más limpia y para modular un proyecto iOS.
La idea detrás de este patrón es la de aislar las dependencias de la aplicación, equilibrando la delegación de responsabilidades entre las entidades, lo que se logra utilizando la siguiente arquitectura:
En este diagrama se ilustra la arquitectura VIPER, en la que cada bloque corresponde a un objeto con tareas, entradas y salidas específicas.
Pensemos en estos bloques como si fueran trabajadores en una línea de ensamblaje: una vez que el trabajador completa su trabajo con un objeto, este pasa al siguiente empleado y así hasta que se termina el producto.
Las conexiones entre los bloques representan la relación entre los objetos y qué tipo de información se transmiten entre sí. Y la comunicación de una entidad a otra se da a través de protocolos, pero eso lo explicaremos un poco más adelante.
Arquitectura de proyecto iOS
Teniendo en cuenta el verdadero propósito de la arquitectura VIPER, lo importante es comprender primero un poco cómo es cada parte y cuáles son sus responsabilidades.
Para ello, desarrollaremos una aplicación básica que obtiene una lista de artículos de un API REST y los muestra por pantalla.
1. View
La View en una aplicación iOS con VIPER. Se trata de un UIViewController que contiene una subvista que puede implementarse mediante programación o utilizando el Interface Builder.
Su responsabilidad es la de mostrar lo que el Presenter le dice y manejar las interacciones del usuario con la pantalla.
Cuando este activa cualquier evento que requiera procesamiento, la View simplemente lo delega al Presenter y espera una respuesta que le indique qué se debe mostrar a continuación.
Así es como sería la View para nuestra visualización de artículos en Swift:
2. Presenter
El Presenter funciona como un puente entre las partes principales de un módulo VIPER. Por un lado, recibe eventos de entrada provenientes de la View y reacciona a ellos solicitando datos al Interactor.
Por otro lado, recibe las estructuras de datos que provienen del Interactor, aplica la lógica de vista sobre estos datos para preparar el contenido y, finalmente, le dice a la View qué debe mostrar.
Aquí hay un ejemplo de un Presenter para nuestra aplicación de visualización de artículos:
3. Interactor
Podemos pensar en este objeto como una colección de casos de uso dentro de un módulo específico. El Interactor contiene toda la lógica de negocios relacionada con las entidades y debe ser completamente independiente de la interfaz de usuario.
En nuestra aplicación de visualización de artículos, un ejemplo de caso de uso es buscar la lista de artículos del servidor.
Es responsabilidad del Interactor realizar las solicitudes, manejar las respuestas y convertirlas en una Entity (que, en este caso, es un objeto del artículo).
Una vez que el Interactor termina de ejecutar alguna tarea, notifica al Presenter sobre el resultado obtenido. Algo muy importante que se debe tener en cuenta, es que los datos enviados al Presenter no deben implementar ninguna lógica comercial, por lo que deben estar limpios y listos para usar.
En nuestra aplicación de visualización de artículos, el Interactor sería responsable de obtener los artículos de una API:
4. Entity
La Entity es probablemente el elemento más simple dentro de una estructura VIPER. Encapsula diferentes tipos de datos y, por lo general, se trata como una carga útil entre los otros componentes de VIPER.
Una cosa importante a tener en cuenta es que la Entity es diferente de la capa de acceso a datos, que debe ser manejada por el Interactor.
En nuestra aplicación de visualización de artículos, la clase de artículos sería un ejemplo de una entidad:
5. Router
El último y quizás el elemento más peculiar de la arquitectura VIPER es el Router, que es responsable de la lógica de navegación entre los módulos, y cómo deben suceder (por ejemplo, definir una animación para presentar una pantalla o cómo se debe realizar la transición entre dos pantallas). Recibe los comandos de entrada de los Presenter para indicar a cuál de estas debe dirigirse.
Además, debe ser responsable de pasar los datos de una pantalla a la otra. Debe implementar un protocolo que defina todas las posibilidades de navegación para un módulo específico (lo que permite una visión general rápida de todas las rutas que puede tomar una aplicación con solo mirar el protocolo del Router).
Debido a una limitación del marco de trabajo de iOS, solo los ViewControllers pueden realizar una transición entre pantallas, por lo que un Router debe contener una referencia al controlador del
módulo o a cualquiera de sus elementos secundarios.
Así es como se vería nuestro Router en la aplicación de visualización de artículos (hay que tener en cuenta además que al Router se le conoce como Wireframe).
En la próxima publicación seguiremos hablando de VIPER y explicaremos cuándo debemos utilizarla y cuándo no.
secture code 