Reflexión: Modelo de datos y clases basadas en estructura de tablas o en aspecto visual.

Ha llegado la hora de migrar otra de las aplicaciones que tengo en producción y desarrollo constante a MVC usando la librería complements en Xailer, por lo que he empezado a estudiar el modelo de datos que necesitaré para la aplicación. Actualmente la aplicación funciona con MySQL y un sistema de clases basado en la estructura de las tablas de la base de datos.

Ahora bien, estoy planteándome si debo reconstruir el modelo de datos basándome en la estructura de las tablas (parece que es lo más correcto según la forma de trabajo tradicional) o bien adaptar el modelo de datos a los aspectos visuales de la aplicación. Intentaré explicar que es esto del aspecto visual de la aplicación.

Tengamos nuestra pantalla de edición de datos de una tabla maestra, la de formas de pago por ejemplo; aquí no hay duda, la estructura de la tabla coincide completamente con  el aspecto visual de la pantalla de edición.

Veamos ahora que ocurre con otra tabla, maestra también, pero que además de sus propios datos, toma datos de otra tabla. Por ejemplo, la tabla de clientes que lleva asociada una forma de pago. Este caso es un poco más complejo, pero está también claro que la clase a usar en el modelo de datos se asemeja mucho al aspecto de la pantalla de edición.

Avanzamos un poco más y tengamos el caso de un maestro/detalle (un albarán, una factura, un pedido…) que lleva mucha más información y que en el diseño de tablas de la base de datos está repartido en varias: cabecera, lineas, vencimientos …. Aquí se nos presenta el problema de crear una clase que en su interior contenga todos los datos que deseamos mostrar en la pantalla de edición, adaptándola a ella de forma que desde un objeto tengamos acceso a toda la información que necesitamos editar. Si en este caso usamos clases basadas en la estructura de tablas, deberemos tener en cuenta muchos aspectos a la hora de realizar mantenimiento (bajas, modificaciones, altas), controlando que todo se corresponda completamente. En cambio, al usar clases basadas en el aspecto visual y tener todo programado en varias capas, con hacer miFactura:update() se actualizarán todos los datos correspondientes (cabeceras, lineas, vencimientos, etc.). Como ejemplo, una clase que contendrá una factura, podría tener en su estructura los siguientes objetos:

  • Objeto cliente. (Necesaria una clase cliente).
  • Objeto forma de pago. (Necesaria una clase forma de pago).
  • Lista de objetos de lineas de detalle. (Necesaria una clase lineaDetalleFactura).
  • Lista de objetos de lineas de vencimientos. (Necesaria una clase lineasVencimiento).

Al realizar la carga de datos desde la base de datos, y dependiendo de como estén creadas nuestras tablas, cargaremos los objetos con los datos almacenados. Así si tenemos los datos del cliente en la tabla de cabecera, cargaremos el objeto cliente con esos datos; igual para las formas de pago, para los artículos, etc.).

Un caso algo más complejo: una agenda de citas de una consulta médica. Parece fácil a primera vista, pero si queremos controlar fácilmente desde nuestro código cada item de la agenda debemos, necesariamente, pensar en adaptar la clase del modelo de datos al aspecto visual de la agenda. Por regla general, mostraremos los items de la agenda dentro de una (o varias) celdas de un browse, en la que será necesario indicar datos como el nombre del paciente, su teléfono, algún comentario, etc. Si lo hacemos usando la estructura de tablas, cada dato puede venir de una tabla distinta, complicando mucho su uso (máxime si queremos permitir arrastrar y soltar items de la agenda entre celdas del browse). Usando una clase que contenga la lista de objetos a presentar en el browse de forma coordinada, conseguiremos que todo se pueda controlar más fácilmente, incluso la edición del item para realizar modificaciones o su eliminación.

Mi decisión, después de pensarlo detenidamente y escribir este artículo, es la de usar un modelo de datos adaptado a los aspectos visuales de la aplicación y así poder controlar cada elemento como una entidad completa compuesta de otros objetos.

Anuncios

6 comentarios

  1. Adelante Jose, estoy muy interesado.

  2. Como siempre, muy buen punto!
    He sentido michas veces ese mismo sentimiento ambiguo de no haber hecho las cosas ‘a la mvc’, aunque el programa iba bien y rapido. El programar usando fraeworks en php me ha ayudado a entender mejor la diferencia.
    Me parece que la conclusión a la que llegas es la más acertada. Tendemos a confundir el modelo con la(s) tabla(s) relacionales que dan soporte a la persistencia, lo que es incorrecto si consideramos que existen objetos que no se pueden almacenar en una única tabla. Que el soporte sea casi siempre relacional nos ha hecho pensar siempre de un modo equivocado respecto de los modelos. Si lo pensamos en términos de objetos, el modelo de entidades complejas, soportadas en varias tablas relacionales, es más evidente. La vista requerirá diferentes formas de ver los datos, y es el modelo el que se tiene que ‘apañar’ y darle a la vista la info ‘mascada’, sin importar de donde viene.

    Un saludo

  3. Hola José Alfonso,

    Me gustan mucho tus artículos sobre modelado de datos.
    Si no he entendido mal, crees que hay que crear objetos en base a lo que se va a visualizar.
    ¿ No crees tu que los modelos de datos de los programas pueden ser tres ?
    1º Las tablas y su relación de la base de datos
    2º La interfaz de usuario (UI)
    3º Las clases que une 2º con 1º (*)

    Por tanto, y si no me equivoco en lo que tu planteas, ¿ no sería mejor tener un tercer nivel (*) independiente de la base de datos y de la interfaz de usuario y así habría mayor abtracción y por tanto mejor comprensión y mantenimiento del programa ?

    Saludos. Un amigo.

    • Hola amigo,

      Gracias por el comentario.

      Lo que busco es, en esencia, eso que dices, y actualmente cuento con las siguientes capas:
      – capa de comunicación con la base de datos
      – capa del modelo de datos con clases para el manejo de datos y clases que crean el objeto que se usará en la capa de visualizacion
      – capa de comunicación del modelo con la capa de vista (controlador)
      – capa de interfaz de usuario (vista)

      No veo la necesidad de crear una capa adicional.

      Saludos.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: