
Cuando hablamos del término "arquitectura" de inmediato pensamos en la construcción de edificios, planos, cascos blancos y temas más de ingeniería dura. Sin embargo, en el ámbito de la informática, la arquitectura tiene un lugar especial.
Arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema" (David Garlan y Mary Shaw, "An introduction to Software Architecture").
Por lo tanto, al hablar de arquitectura estamos en terrenos de la organización y el control de las aplicaciones de todo tipo. Pero, ¿qué pasa con nuestros queridas aplicaciones móviles? ¿requieren de su propia arquitectura?
Pues en ese sentido, las aplicaciones móviles, particularmente las de tipo Android, deben contener patrones arquitectónicos que permitan una buena coordinación entre las Activity, los Layouts y el resto de las clases que se requieren para crear el funcionamiento que resuelve la problemática de los usuarios.
El Patrón Modelo-Vista-Controlador (MVC)
Uno de los patrones arquitectónicos más conocidos en las nuevas generaciones de aplicaciones es el famoso MVC (Model-View-Controller). Este patrón permite organizar los componentes de software de cualquier aplicación en 3 capas que se comunican entre sí de acuerdo a la responsabilidad para la cual fueron diseñadas:

Modelo (Model): es la capa responsable de dar acceso a las fuentes de datos como bases de datos, servicios web u otros medios de almacenamiento de datos.
Vista (View): es la capa que contiene todos los elementos que son visuales organizados de manera de que para el usuario tengan sentido. Aquí es importante considerar que todo lo que se presenta debe estar en esta capa.
Controlador (Controller): es la capa que controla todas las transacciones y operaciones de negocio de la aplicación. También funciona como puente entre los procesos que requieren datos para acceder a la capa Modelo, así como para entregarle resultados a la capa Vista al momento de ser presentados al usuario final.
Rápidamente, si hacemos el paralelo con las aplicaciones Android, encontramos una similitud con lo que originalmente se usaba, donde todos los archivos XML y sus recursos asociados eran las vistas, los controladores eran las Activities o Fragments de la aplicación, y por supuesto, la capa de abstracción de datos era parte del modelo.
Uno de los grandes problemas de esta aproximación es que se rompe el principio sobre Single Responsability de SOLID (https://www.baeldung.com/java-single-responsibility-principle).
El Patrón Modelo-Vista-Presentador (MVP)
Derivado del MVC, el MVP (Model-View-Presenter) es un patrón arquitectónico en donde se reúne la responsabilidad de manejar la vista en la misma capa, para incorporar el concepto de presentador, quién está a cargo de generar todos los procesos de negocio que permitan construir la vista a partir del uso del modelo:

Modelo: Al igual que en MVC, el Modelo está a cargo del acceso a los datos a través de las diferentes fuentes de datos que existan.
Vista: Aquí se encuentran todos los componentes asociados a la visualización pasiva y que permiten mostrar los datos que el presentador se encargue de proveer.
Presentador: Es el responsable de mediar entre el modelo y la vista. Recupera datos de los repositorios (el modelo), y los formatea para mostrarlos en la vista.
Si comparamos con el desarrollo en Android, es fácil ver que tanto Activities como Fragments pasan a la capa de vista, mientras que el presentador tendrá todas aquellas clases que incorporen flujos de proceso para obtener y procesar los datos. Esto hace que las clases de interfaces (antes los controladores de interfaz) pasen a ser solo "pintores" de interfaces.
El Patrón Modelo-Vista-Modelo de Vista (MVVM)
El patrón arquitectónico MVVM (Model-View-ViewModel) es una arquitectura de software cuyo objetivo central es desacoplar al máximo las capas que la conforman. Nace a partir del proyecto Windows Presentation Foundation como una variante del MVC a dicho proyecto, de la mano de John Gossman el año 2005. En este patrón, cada capa queda relacionada con las siguientes responsabilidades:

Modelo: Al igual que MVC y MVP, representa la capa que accede a las fuentes de datos para abstraer los datos de ellas.
Vista: Esta capa es la responsable de la presentación como tal de las aplicaciones. Las vistas en MVVM son activas, contienen comportamientos, eventos y enlaces a datos que, en cierta manera, necesitan tener conocimiento del modelo subyacente.
Modelo de Vista: Es el responsable de intermediar entre el modelo y la vista apoyando al proceso de preparación de los datos a ser presentados. También proporciona enlaces a la vista para manejar eventos al modelo.
De la misma manera, podemos observar que la aplicación de esta arquitectura en Android es posible, ya que la vista contiene todo lo que corresponde al procesamiento de la parte visual, incluyendo Activities y Fragments. Sin embargo cuando llegamos al modelo nos encontramos que la manera tradicional no es la más adecuada, por lo cual se debe hacer "data binding" para que los componentes de la vista se puedan asociar directamente a los datos (https://developer.android.com/topic/libraries/data-binding?hl=es-419).
Conclusión
Elegir una arquitectura no es una tarea de un momento, sino que se debe tener muy en cuenta algunos factores que permitirán el éxito del desarrollo. Estos factores son:
La arquitectura seleccionada debe ser respetada. Si vamos a seleccionar una arquitectura como MVP o MVVM, debemos procurar que toda la aplicación respete los patrones asociados a ella.
Hay que tener conocimiento de cómo se aplica el patrón arquitectónico. Uno de los errores más comunes es querer aplicar un patrón pero son el conocimiento de cómo hacerlo, ya que no es tan fácil como ver un tutorial o preguntar en StackOverflow.
Se debe ser consciente del objetivo del patrón seleccionado. Al igual que cualquier aplicación (no solo móvil), los patrones de arquitectura tienen un objetivo secundario: desarrollo en base a pruebas, desacoplar los objetos, etc. Si conocemos los principios, entonces lograremos obtener un resultado robusto.
Y si no sabemos qué hacer, KISS. Siempre debemos ir a la lógica Keep It Simple, Stupid!, en donde la idea no es que compliquemos las cosas. Si no tenemos experiencia o entendemos poco lo que es un MVP o un MVVM, apliquemos MVC y punto.
Lo importante de todo es que es todo para hacer mejor nuestros desarrollos.
Cambio y fuera.
コメント