Una de las alternativas de uso frecuente para el Modelo Vista Controlador (MVC) es la arquitectura Viper. Su estructura está basada en distintas capas de diferentes responsabilidades. El fin es eliminar la dependencia entre los componentes y probar su funcionamiento en base a las interacciones generadas.
Con el uso del diseño, la industria del software busca que cada código desarrollado sea una pieza identificable y encaje con otros fragmentos de forma lógica. La idea es evitar que un controlador tenga toda la lógica de la aplicación. Cuando el acoplamiento es tan fuerte, el mantenimiento de aplicación es complicado.
Ventajas de usar la arquitectura Viper
Para los equipos de gran tamaño, se ha demostrado que los módulos independientes funcionan adecuadamente y es estable por lo que permite trabajar de manera simultánea sin generar problemas. Al ser extraíble el código, se reutiliza nuevamente y se testea.
Asimismo, la arquitectura divide a los componentes de acuerdo al rol, contribuye a la división de las responsabilidades, se le puede añadir nuevas características fácilmente, proporciona rapidez en la escritura de test automáticos y el código se presenta de manera clara, compacta y reusable.
Otras de sus importantes funciones es que los equipos presentan pocas ocasiones de conflictos, los problemas detectados se reportan vía crash, por principios de responsabilidad única, y además minimiza los inconvenientes mezclados.
Componentes de la arquitectura
A pesar de los patrones sugeridos por iOS, existen nuevas opciones que mejoran el sistema de desarrollo. En el caso de esta arquitectura, está integrada por 5 elementos: Presenter, se refiere a recoger la data de las interacciones de los usuarios, generar un modelo de vista y llevarlo al siguiente nivel View, la vista donde se presentan las acciones generadas.
El Interactor actúa como la columna vertebral de la aplicación, debido a que dispone de la lógica previamente establecida en los casos. Otros de los componentes son Entity, que tiene responsabilidades de la capa modelo de otras arquitecturas y el router que se basa en toda la lógica de navegación y describe lo que la pantalla quiere mostrar y en cuál momento.
¿Cuándo usar?
Al ser una arquitectura para aplicaciones limpias de iOS, se recomienda emplear en proyectos que tengan cierto nivel de complejidad. Para proyectos pequeños, sin intención de escalar, no es conveniente emplearla porque los gastos generados son mayores. El diseño para aplicaciones existentes contribuye a encontrar problemas y la adopción de una metodología.
