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.

Solucionado problemas de lentitud en ConsultaClinica

Después de darle muchas vueltas al programa he encontrado el problema de lentitud cuando se añadía una nueva Sesión a una Patología con muchas Sesiones en la História Clínica.

El cambio es tan sorprendente que de llegar a tardar casi un minuto en algunos casos, ahora es instantáneo.

El problema era un pequeño error en el dominio de datos de la História Clínica, donde el método de carga de datos se traía todos las filas (incluídos el blob) en vez de sólo el que interesaba a la hora de refrescar los datos después de haber grabado y actualizado el treeview.

Videos demostrativos del programa Consulta Clinica

Pueden visitar los videos en mi canal de youtube.

o acceder directamente a cada video desde aqui:

Demostración Consulta Clinica, video 1 de 2.

Demostración Consulta Clinica, video 2 de 2.

Generador de informes en las aplicaciones

Estoy trabajando en la implementación de un sistema de Creación de Informes apoyándome en el Generador de Reportes FastReport. Este sistema será común a todas las aplicaciones y contará con asistentes para la creación de informes por parte del usuario.

La implementación de un sistema de generación de informes ofrece a los usuarios un amplio abanico de posibilidades al tener la posibilidad de crear sus propios informes sin dependender del programador accediendo así a todas la información contenida en la base de datos.