Haciendo apps-episodio-14-sobre-arquitecturas-de-software

Hoy hablaremos sobre arquitecturas de software en movilidad.

Ooooh que palabra más bonito: arquitecturas.

En realidad de lo que vamos a hablar es de la estructura que vamos a dar a nuestro proyecto.

Verás hay diferentes arquitecturas de software, en concreto, en movilidad, existen las siguientes:

  • MVC
  • MVP
  • MVVM
  • VIPER

No son los únicos, porque esto de los patrones va un poco por modas, si estás escuchando este episodio dentro de 5 años, lo mismo han sacado otra arquitecturas de software que lo esté pegando en ese momento.

MVC – MODELO-VISTA-CONTROLADOR

Cuando se empieza a desarrollar Apps, lo más normal es empezar con el MVC.

Modelo vista controlador es la arquitectura de software más básica, pero no por ello deja de tener su complejidad.

Una de las cosas que más tenemos que enfocarnos cuando construimos software es tener lo más desacoplado posible todas sus capas.

¿A qué me refiero? Pues que si por ejemplo tenemos un controlador de vista, dentro de este controlador de vista no haya código que podríamos haberlo extraído y colocarlo en una clase aparte.

Por ejemplo, imagina que tienes una aplicación que geo-localiza al usuario o usuaria, es muy común crear esta geo-localización en el propio controlador de vista.

Pero imagina que además tu App hace tal o cual cosa, al final el ViewController, o controlador de vista, se acaba convirtiendo en un chorizo muy difícil de gestionar y mantener.

En el caso de la geo-localización por ejemplo, podemos crear una clase que haga toda la tarea de geolocalizar, y luego pasarle los datos de esta geo-localización a nuestro controlador de vista, de esta forma estaríamos aplicando correctamente el patrón modelo vista controlador, dónde por un lado tendríamos el controlador, por otro lado tendrías tu modelo, y por último la vista que mostraría los datos.

Aplicar el patrón modelo vista controlador aunque pueda parecerlo, no es del todo sencillo.

MVP y MVVM

Por otra parte tenemos otras arquitecturas de software como MVP, o MVVM, estás arquitecturas están más orientadas quizá más la última, a una programación reactiva, programación funcional incluso, dónde por ejemplo en ModelView view Model, necesitamos de mecanismos externos para comunicar entre si a los diferentes actores, en el caso de iOS se suele usar RXSwift o ReactiveCocoa.

La arquitectura MVP aunque existe en ambas plataformas iOS y Android, es más usada en Android. MVP es la evolución del MVC, pero en este caso, en la arquitectura MVP, la vista está mas desacoplada del modelo, es decir la vista no sabe de la existencia del modelo y viceversa.

VIPER

Por último déjame hablarte de VIPER.

Viper es la arquitectura estrella en estos momentos, se trata de una arquitectura que desacopla en su grado máximo los diferentes elementos de una aplicación.

Si bien es cierto que, te digan lo que te digan, no es aconsejable para según que tipo de proyectos, cada vez se está empezando a usar de forma masiva.

VIPER es el acronimo de:

  • View
  • Interactor
  • Presenter
  • Entity
  • Router

 

VIEW

Es un ViewController que contiene sub-vistas creadas por código o bien con archivos .XIB. Tiene 2 responsabilidades: mostrar los datos que recibe del Presenter, y recoger los eventos del usuario/a para pasárselos al Presenter.

Aquí se añaden los targets o gestos a las vistas.

INTERACTOR

Obtiene los datos de la capa de conexión o base de datos, y crea los objetos con las Entity y se los proporciona al Presenter. No debería ni siquiera importar UIKit, con Foundation debería ser suficiente. La única lógica que debe tener es la necesaria para obtener los datos y formar las entidades que pasará al Presenter.

Generalmente tendrá un protocolo para gestionar la comunicación con el Presenter (pasar al Presenter información).

Generalmente tendrá una propiedad del protocolo del Presenter. ¡Declarar con referencia débil para evitar ciclos de retención de memoria!

El interactor le pasa los datos al Presenter a través de delegación. Por medio de la función del protocolo de entrada del Presenter.

PRESENTER

Es el componente más importante de VIPER.  Contiene la lógica de negocio, los casos de uso. Recibe la interacción del usuario/a y gestiona los mismos comunicándose con el Interactor. También recibe del Interactor los datos, aplica la lógica y prepara el contenido para pasárselo a la vista.

Generalmente tendrá un protocolo para gestionar la comunicación con con la Vista (recibir la interacción del usuario/a, es decir, actualizaciones de la vista, y pasárselas al Interactor)

Generalmente tendrá un protocolo para gestionar la comunicación con el Interactor(recibir información del Interactor y actualizar la vista).

Generalmente tiene una propiedad de la vista. ¡Declarar con referencia débil para evitar ciclos de retención de memoria!

Generalmente tendrá una propiedad del protocolo del Interactor.

Generalmente tendrá una propiedad del Router.

ENTITY

Es el modelo, una clase con sus propiedades.

ROUTER

Es el encargado de la navegación y de gestionar los datos entre vistas. El Router tiene que conocer a la vista (ViewController).

Generalmente implementa un protocolo que incluye todas las funciones de navegación entre diferentes módulos.

Generalmente tendrá una propiedad de la vista. ¡Declarar con referencia débil para evitar ciclos de retención de memoria!

Generalmente tendrá propiedades de otros Router (Wireframe) de otros módulos.

No hay que obsesionarse

Por último, no hay que obsesionarse con esto, si bien es cierto que es algo imprescindible pensar y ejecutar cuando desarrollas software, la arquitectura debería ser flexible, y ojo, que esto es una opinión mía.

Lo que quiero decir, es que por ejemplo llevo meses estudiando VIPER, y te puedo decir que la literatura es ambigua, en el sentido de que no he encontrado dos proyectos con arquitectura VIPER creados de la misma forma, uno usa WireFrame par refererirse al Router, otro tiene una clase llamada Assembly que construye los objetos, que sería como una capa extra al Router, ¿que significa esto?

Bueno, pues que cuando uno empieza con esto de los patrones de arquitectura, cree que esto está grabado en mármol, que debes seguirlo y hacerlo exactamente como te cuentan, la experiencia te dice que no es necesario, porque cada proyecto es un mundo, y no pasa nada por no seguir al 100% ciertos diseños de ese patrón de arquitectura en cuestión.

Cómo digo, esto último es mi humilde opinión.

Página de CFE Apps en Linkedin

He creado la pagina de CFE Apps en Linkedin, por favor sígueme allí, y si has realizado alguna de mis formaciones, podrás ser alumni y beneficiarte de descuentos, promociones, y contenido extra.

CLIC AQUÍ PARA SEGUIRME EN LINKEDIN

Por mi parte es todo.

Si te ha gustado este post y el podcast, déjame un comentario contándomelo ?

Nos vemos, en la próxima clase, hasta luego!

About The Author
iOS Developer & Instructor at CFE Apps. Enseño a crear aplicaciones iOS a todo el que quiera aprender.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.