Casi todos los que nos hemos dedicado en algún momento al desarrollo de aplicaciones reconocemos la importancia de mantener separados el contenido y la presentación; es decir, independizar qué hace la aplicación de cómo lo muestra al usuario. Yendo un paso más allá, el patrón MVC propone una separación del software en tres partes:

• Modelo (model): la información con la que trabaja la aplicación (“los datos”). Habitualmente esta parte está soportada por un sistema de base de datos.
• Vista (view): cómo interacciona el usuario con la aplicación (“la interfaz”). En una aplicación web suele utilizarse HTML y CSS.
• Controlador (controller): las acciones que realiza la aplicación (“el comportamiento” o “la lógica”).

Muchos frameworks de desarrollo siguen este patrón, ya que las ventajas de esa separación son múltiples: la aplicación resulta más modular, más flexible, facilitando cambios en una de las partes sin necesidad de modificar el resto.

Por ejemplo, una aplicación desarrollada siguiendo ese patrón permitiría fácilmente cambiar el gestor de base de datos (el modelo) sin necesidad de modificar el resto de la aplicación; o desarrollar cada una de las partes de modo independiente; o acceder a la misma aplicación desde diferentes dispositivos como navegadores web o móviles, simplemente creando diferentes vistas.

¿Este patrón no queda del todo claro? ¿Sus ventajas no resultan tan evidentes? Puede que lo comprendamos mejor si establecemos un símil con algo que casi todos conocemos: la estructura de los teléfonos móviles.

Teléfonos móviles y el patrón MVC

¿De qué modo podemos identificar la estructura de un teléfono móvil con el patrón MVC? No me estoy refiriendo únicamente a las aplicaciones que puedan ejecutarse en un dispositivo de ese tipo, sino globalmente a todo el funcionamiento del teléfono. Y lo haríamos así:

• Modelo (“los datos”): los contactos (nombres, números de teléfono, etc.) almacenados en la tarjeta SIM del móvil.
• Vista (“la interfaz”): el diseño visible del móvil; su aspecto externo, las carcasas, los temas disponibles, imágenes de fondo, tonos, botones, etc.
• Controlador (“el comportamiento”): las diferentes funcionalidades del móvil, además de realizar y recibir llamadas; agenda, juegos, conectividad, etc.

Esta estructura, con la que tan familiarizados estamos, permite una flexibilidad importante; por ejemplo:

• Utilizar sin problemas los mismos datos en diferentes dispositivos, con diferentes funcionalidades, simplemente insertando la tarjeta SIM en uno o en otro.
• Utilizar el mismo dispositivo con diferentes datos, insertando diferentes tarjetas SIM.
• Modificar el aspecto del móvil (carcasas, temas, tonos, etc.) sin modificar su funcionalidad o los datos almacenados.

Incluso podemos intuir los problemas que se pueden producir cuando no se respeta esta separación:

La mayoría de móviles incluyen una agenda interna que permite almacenar contactos en la memoria del propio dispositivo, independientemente de la tarjeta SIM. Esto proporciona un mayor espacio disponible y nuevas funcionalidades, pero a costa de violar el modelo al incluir datos propios del modelo (la tarjeta SIM) en el controlador (el móvil); muchos hemos sufrido los problemas de tener contactos duplicados, no saber exactamente dónde están almacenados, o perder números que “se quedan” en un dispositivo viejo al migrar la tarjeta a un nuevo móvil.

En definitiva, una comparación entre el modelo MVC de desarrollo de aplicaciones y la estructura de los teléfonos móviles nos permite apreciar de un modo más claro sus ventajas y los posibles inconvenientes de no respetar esa separación entre datos, interfaz y lógica.