SAPUI5: JSONModel frente a ODataModel: cuándo utilizar cada uno y por qué

Una guía práctica para elegir el modelo adecuado para el estado de la interfaz de usuario y los datos de negocio.

Cuando empiezas a trabajar con SAPUI5, JSONModel puede parecer la solución más sencilla para casi todas las pantallas. Puedes crear un objeto JavaScript, vincularlo a la vista, actualizar una propiedad y ver cómo la interfaz de usuario reacciona al instante. Esa simplicidad es útil, pero también puede llevar a un error arquitectónico muy común: tratar los datos de negocio procedentes de un servicio OData como si se tratara simplemente de otro objeto JSON local.

JSONModel y ODataModel utilizan conceptos de enlace similares, pero resuelven problemas distintos. La cuestión importante no es qué modelo tiene la sintaxis más sencilla, sino quién es el propietario de los datos y dónde deben realizarse operaciones como el filtrado, la paginación y la persistencia.

Las tres diferencias arquitectónicas

Hay tres diferencias que conviene recordar:

• Propiedad de los datos: JSONModel contiene datos del lado del cliente, mientras que ODataModel representa entidades gestionadas por un servicio OData.
• Ejecución: JSONModel funciona principalmente en la memoria del navegador, mientras que ODataModel puede delegar las consultas y los cambios en los datos al servidor.
• Ciclo de vida: JSONModel es ideal para el estado temporal de la interfaz de usuario, mientras que ODataModel está diseñado para datos empresariales remotos, metadatos de servicios y sincronización.

Una regla útil Es sencillo: si los datos existen gracias a la interfaz de usuario, piensa en JSONModel. Si los datos existen independientemente de la interfaz de usuario y pertenecen al dominio de negocio, piensa en ODataModel.

JSONModel: datos controlados por la interfaz de usuario

JSONModel es ideal para valores como indicadores de ocupado, el modo de edición, pestañas seleccionadas, filtros locales o el estado temporal de un formulario. Toda la estructura reside en el navegador y está totalmente controlada por el frontend.

const oViewModel = new JSONModel({
  busy: false,
  editMode: false,
  selectedCategory: "All"
});
 
this.getView().setModel(oViewModel, "view");

Por qué JSONModel funciona bien para el estado local

Es ligero, fácil de entender y funciona de forma natural con modelos con nombre, como “view” o “state”. No hay motivo para enviar una solicitud al backend cuando un usuario abre un panel o cambia la pestaña seleccionada. El estado local debería, normalmente, permanecer local.

La limitación surge cuando el conjunto de datos es muy grande o debe mantenerse sincronizado con un backend. Un JSONModel no interpreta automáticamente los metadatos de OData, la paginación del lado del servidor ni la semántica CRUD remota.

ODataModel: el backend es la fuente de verdad

ODataModel es la opción más adecuada cuando la pantalla trabaja con entidades de negocio, como productos, pedidos o clientes, expuestas por un servicio OData. En lugar de copiar esas entidades en una estructura local independiente, SAPUI5 puede vincular los controles directamente al modelo del servicio.

De este modo, el backend sigue siendo la fuente de información fiable. El modelo interpreta los metadatos del servicio y puede coordinar las lecturas y las modificaciones de datos sin obligar a la aplicación a crear una segunda copia del mismo estado empresarial.

El filtrado del lado del servidor es la diferencia arquitectónica
La mayor diferencia práctica se hace evidente con conjuntos de datos más grandes. Imagina un servicio con 50 000 productos. Cargarlo todo en un JSONModel y luego filtrarlo en JavaScript implica transferir y almacenar datos que el usuario quizá nunca necesite.
Con ODataModel, los filtros, la ordenación y la paginación pueden traducirse en solicitudes OData, de modo que el backend solo devuelva los registros relevantes. Esto es más que un simple truco para mejorar el rendimiento. Mantiene el procesamiento de datos en la capa que los gestiona y facilita el mantenimiento del frontend.
El mejor enfoque en la práctica: utilizar ambos modelos
En una aplicación SAPUI5 real, la respuesta no suele ser ni JSONModel ni ODataModel. Son ambas, con responsabilidades bien definidas. Utiliza ODataModel para las entidades de negocio y JSONModel para el estado de la interfaz de usuario.
Por ejemplo, una página de “Productos” puede vincular su tabla a /Products del modelo OData predeterminado, mientras que un modelo denominado «view» almacena los campos «busy», «editMode» y «selectedCategory». La vista XML puede utilizar ambos modelos al mismo tiempo. Esta separación permite distinguir de inmediato qué estado pertenece al backend y cuál pertenece únicamente a la pantalla.
El antipatrón: copiar OData en JSONModel
Una práctica habitual consiste en leer /Products desde OData, copiar el resultado en un nuevo JSONModel y vincular la tabla a esa copia. Funciona, pero a menudo elimina la razón por la que se utiliza ODataModel en primer lugar.
Una vez duplicados los datos, debes decidir qué copia es la actual, actualizarla tras cada modificación y reproducir manualmente los comportamientos que ya ofrece ODataModel. Existen excepciones válidas, por ejemplo, cuando es necesario transformar los datos de forma significativa para adaptarlos a una estructura temporal exclusiva del cliente. No obstante, la copia debe ser una decisión deliberada, no la arquitectura por defecto.
// Evita utilizar esto como patrón por defecto
oModel.read("/Products", {
  success: ({ results }) => {
    this.getView().setModel(new JSONModel(results), "products");
  }
});
Las rutas de enlace tienen un aspecto similar, pero su comportamiento no es el mismo
Tanto un enlace JSONModel, como {view>/editMode}, como un enlace ODataModel, como {/Products}, tienen el aspecto de rutas en XML. Esa similitud visual puede ocultar una diferencia importante. Una ruta JSON apunta a datos que ya obran en poder del cliente. Una ruta OData puede representar un conjunto de entidades remotas cuyos datos se cargan, filtran o actualizan a través del servicio.
Al revisar una pantalla de SAPUI5, no juzgues el modelo únicamente por la sintaxis de enlace. Sigue el rastro hasta llegar a su propietario.
Buenas prácticas
Utiliza modelos JSONModels con nombre para el estado específico de la interfaz de usuario, como “view”, “state” o “filters”. Mantén el ODataModel principal centrado en los datos de negocio. Evita cargar grandes colecciones remotas en JSON solo para que el enlace resulte más sencillo. Utiliza el filtrado, la ordenación, la paginación y $select del lado del servidor cuando el servicio los admita. Por último, mantén las responsabilidades del modelo lo suficientemente claras como para que otro desarrollador pueda entender la pantalla sin tener que rastrear cada método del controlador.
Ventajas y desventajas
Área
Resumen
Ventajas de JSONModel
Estado local sencillo, configuración ligera, estructura de JavaScript sencilla, ideal para valores temporales de la interfaz de usuario.
Desventajas de JSONModel
Solo memoria del cliente, sin persistencia remota nativa; no es la opción ideal para grandes conjuntos de datos de servidor.
Ventajas de ODataModel
Enlace OData nativo, consultas al backend, metadatos, paginación y operaciones con datos remotos.
Desventajas de ODataModel
Más conceptos de servicio que hay que comprender y que resultan innecesarios para un estado sencillo de la interfaz de usuario local.
Conclusión
JSONModel y ODataModel no son soluciones competidoras. Son herramientas complementarias para diferentes niveles de estado. JSONModel es excelente cuando el front-end es el propietario de los datos y necesita un estado rápido y temporal. ODataModel es la mejor opción cuando los datos pertenecen a un servicio de back-end y deben consultarse, modificarse o sincronizarse como datos empresariales.
Las aplicaciones SAPUI5 más fáciles de mantener suelen combinar ambas cosas: el estado local de la interfaz de usuario se almacena en un pequeño JSONModel, mientras que las entidades de negocio permanecen conectadas al ODataModel. Una vez que queda clara esa relación, la selección del modelo resulta mucho más sencilla y es más fácil comprender la arquitectura de la aplicación.