Patrones de arquitectura de Android

Cuando los desarrolladores trabajan en una aplicación móvil real cuya naturaleza es dinámica y ampliará sus funciones según las necesidades del usuario, entonces no es posible escribir la lógica central en actividades o fragmentos. Para estructurar el código del proyecto y darle un diseño modular (partes de código separadas), se aplican patrones de arquitectura para separar las preocupaciones. Las arquitecturas de Android más populares utilizadas por los desarrolladores son las siguientes:

• MVC (Modelo — Vista — Controlador)
• MVP (Modelo — Vista — Presentador)
• MVVM (Modelo — Vista — ViewModel)

La idea principal de todos estos patrones es organizar el proyecto de manera adecuada para que todos los códigos se cubran en las pruebas unitarias. Además, es muy útil en el mantenimiento del software, para agregar y eliminar funciones y los desarrolladores pueden realizar un seguimiento de varias partes lógicas cruciales. 

El patrón modelo-vista-controlador (MVC)

El patrón MVC es la arquitectura de aplicación de Android más antigua que simplemente sugiere separar el código en 3 capas diferentes:

• Modelo: Capa de almacenamiento de datos. Es responsable de manejar la lógica del dominio (reglas comerciales del mundo real) y la comunicación con la base de datos y las capas de red.
• Vista: capa UI (interfaz de usuario). Proporciona la visualización de los datos almacenados en el Modelo.
• Controlador: Capa que contiene la lógica central. Se informa del comportamiento del usuario y actualiza el Modelo según la necesidad.

En el esquema MVC, la vista y el controlador dependen del modelo. El controlador actualiza los datos de la aplicación y View obtiene los datos. En este patrón, el modelo podría probarse independientemente de la interfaz de usuario, ya que está separada. Existen múltiples enfoques posibles para aplicar el patrón MVC. Tanto las actividades como los fragmentos pueden actuar como el controlador donde son responsables del procesamiento de datos y la actualización de las vistas. Otra forma es usar las actividades y los fragmentos como Vistas y el controlador, así como los Modelos, deben ser una clase separada que no extienda ninguna clase de Android. Si las Vistas respetan el principio de responsabilidad única, entonces su función es solo actualizar el Controlador para cada evento de usuario y solo mostrar datos del Modelo, sin implementar ninguna lógica comercial. En este caso,

ventajas:

• El patrón MVC aumenta la capacidad de prueba del código y facilita la implementación de nuevas funciones, ya que admite en gran medida la separación de preocupaciones.
• Es posible realizar pruebas unitarias del modelo y el controlador, ya que no amplían ni utilizan ninguna clase de Android.
• Las funcionalidades de la Vista se pueden verificar a través de pruebas de IU si la Vista respeta el principio de responsabilidad única (actualizar el controlador y mostrar datos del modelo sin implementar la lógica del dominio)

Desventajas:

• Las capas de código dependen unas de otras incluso si MVC se aplica correctamente.
• Ningún parámetro para manejar la lógica de la interfaz de usuario, es decir, cómo mostrar los datos.

El patrón modelo-vista-presentador (MVP)

El patrón MVP es la segunda iteración de la arquitectura de aplicaciones de Android. Este patrón es ampliamente aceptado y aún se recomienda para los futuros desarrolladores. El propósito de cada componente es fácil de aprender:

• Modelo: Capa de almacenamiento de datos. Es responsable de manejar la lógica del dominio (reglas comerciales del mundo real) y la comunicación con la base de datos y las capas de red.
• Vista: capa UI (interfaz de usuario). Proporciona la visualización de los datos y realiza un seguimiento de la acción del usuario para notificar al Presentador.
• Presentador: obtenga los datos del modelo y aplique la lógica de la interfaz de usuario para decidir qué mostrar. Administra el estado de la Vista y realiza acciones de acuerdo con la notificación de entrada del usuario desde la Vista.

En el esquema MVP, View y Presenter están estrechamente relacionados y tienen una referencia entre sí. Para que el código sea legible y más fácil de entender, se utiliza una clase de interfaz de contrato para definir la relación entre el presentador y la vista. La vista se abstrae y tiene una interfaz para habilitar el presentador para pruebas unitarias.

ventajas:

• Sin relación conceptual en los componentes de Android.
• Fácil mantenimiento y prueba del código, ya que el modelo, la vista y la capa del presentador de la aplicación están separados.

Desventajas:

• Si el desarrollador no sigue el principio de responsabilidad única para descifrar el código, entonces la capa de Presentador tiende a expandirse a una gran clase que todo lo sabe.

El patrón Modelo—Vista—ViewModel (MVVM)

La tercera iteración de la arquitectura de Android es el patrón MVVV. Mientras lanzaba los componentes de la arquitectura de Android, el equipo de Android recomendó este patrón de arquitectura. A continuación se muestran las capas de código separadas:

• Modelo: esta capa es responsable de la abstracción de las fuentes de datos. Model y ViewModel trabajan juntos para obtener y guardar los datos.
• Vista: El propósito de esta capa es informar al ViewModel sobre la acción del usuario.
• ViewModel: Expone esos flujos de datos que son relevantes para la Vista.

Los patrones MVVM y MVP son bastante similares porque ambos son eficientes para abstraer el estado y el comportamiento de la capa Vista. En MVVM, Views puede vincularse a los flujos de datos expuestos por ViewModel.

En el esquema MVVM, la Vista informa al ViewModel sobre varias acciones. La Vista tiene una referencia a ViewModel mientras que ViewModel no tiene información sobre la Vista. La relación de muchos a uno que existe entre View y ViewModel y MVVM admite el enlace de datos bidireccional entre ambos.

Comparación del patrón de arquitectura MVC, MVP y MVVM

Patrón	Dependencia de la API de Android	Complejidad XML	Capacidad de prueba de la unidad	Seguir Modulares y sencillos  principio de responsabilidad
MVC	Alto	Bajo	Difícil	No
jugador más valioso	Bajo	Bajo	Bueno	Sí
MVVM	Dependencia baja o nula	Medio a Alto	Mejor	Sí

Ventajas de la Arquitectura

• Los desarrolladores pueden diseñar aplicaciones que puedan aceptar cambios en el futuro.
• Da un diseño modular a la aplicación que asegura una buena calidad de prueba y mantenimiento del código.

Desventajas de la arquitectura

• Escribir todo el código del proyecto en un patrón de arquitectura es un proceso que lleva tiempo.
• Se requiere una disciplina estricta por parte del equipo de desarrolladores, ya que un cambio fuera de lugar puede arruinar la integridad de la arquitectura.