2. : caso de estudio

2.1. El problema

Volvamos a la aplicación que queremos desarrollar. Partimos de una aplicación existente con la siguiente arquitectura:

Para quienes quieran saber más sobre:

NHibernate: Introducción a NHibernate;
la aplicación ASP.NET (WebForms) con NHibernate y Spring: Desarrollo de una aplicación web de tres capas con ASP.NET, Spring.NET y NHibernate [http://tahe.developpez.com/dotnet/pam-aspnet/].

Queremos transformar la aplicación anterior en esta:

donde EF5 ha reemplazado a NHibernate. Esta aplicación es un pretexto para estudiar EF5. Dado que Spring.NET nos permite cambiar de capa fácilmente sin que nada se rompa, la aplicación 2 utilizará la misma capa [ASP.NET] que la aplicación 1. Dado que este documento se centra en EF5, no explicaremos cómo se escribe esta capa. La incorporaremos a la aplicación 2 para comprobar que funciona. Simplemente explicaremos los cambios que hay que realizar en el archivo de configuración de Spring.NET.

El caso de estudio es el siguiente. Se desea ofrecer a los médicos un servicio de programación de citas que funcione según el siguiente principio:

un servicio de secretaría se encarga de las citas de RV para un gran número de médicos. Este servicio puede estar a cargo de una sola persona. El salario de esta persona se comparte entre todos los médicos que utilizan el servicio de RV;
el servicio de secretaría y todos los médicos están conectados a Internet;
las citas se registran en una base de datos centralizada, accesible por Internet tanto para la secretaría como para los médicos;
la asignación de citas (RV) normalmente la realiza la secretaría. También pueden hacerlo los propios médicos. Este es el caso, en particular, cuando, al finalizar una consulta, el médico asigna él mismo una nueva cita (RV) a su paciente.

La arquitectura del servicio de asignación de RV es la siguiente:

Los médicos ganan en eficiencia si ya no tienen que manejar el RV. Si son suficientes, su contribución a los gastos de funcionamiento de la secretaría será mínima. Llamaremos a la aplicación [RdvMedecins]. A continuación presentamos capturas de pantalla de su funcionamiento.

La página de inicio de la aplicación es la siguiente:

Desde esta primera página, el usuario (Secretaría, Médico) realizará una serie de acciones. A continuación las presentamos. La vista de la izquierda muestra la pantalla desde la que el usuario realiza una solicitud; la vista de la derecha, la respuesta enviada por el servidor.

2.2. La base de datos

La base de datos utilizada por la aplicación NHibernate es una base de datos MySQL5 con cuatro tablas:

Nos servirá de referencia para construir todas nuestras bases de datos.

2.2.1. La tabla [MEDECINS]

Contiene información sobre los médicos que administra la aplicación [RdvMedecins].

ID: número que identifica al médico —clave primaria de la tabla
VERSION: número que identifica la versión de la fila en la tabla. Este número se incrementa en 1 cada vez que se realiza una modificación en la fila.
NOM: el apellido del médico
PRENOM: su nombre
TITRE: su título (Srta., Sra., Sr.)

2.2.2. La tabla [CLIENTS]

Los clientes de los distintos médicos se registran en la tabla [CLIENTS]:

ID: número que identifica al cliente —clave primaria de la tabla
VERSION: número que identifica la versión de la fila en la tabla. Este número se incrementa en 1 cada vez que se realiza una modificación en la fila.
NOM: el nombre del cliente
PRENOM: su nombre
TITRE: su tratamiento (Srta., Sra., Sr.)

2.2.3. La tabla [CRENEAUX]

Enumera los horarios en los que son posibles los RV:

ID: número que identifica el horario —clave primaria de la tabla
VERSION: número que identifica la versión de la fila en la tabla. Este número se incrementa en 1 cada vez que se realiza una modificación en la fila.
ID_MEDECIN: número que identifica al médico al que pertenece este horario – clave externa en la columna MEDECINS (ID).
HDEBUT: hora de inicio del horario
MDEBUT: minutos de inicio del horario
HFIN: hora de fin de la franja horaria
MFIN: minutos de fin de la franja

La segunda línea de la tabla [CRENEAUX] (véase [1] más arriba) indica, por ejemplo, que el horario n.º 2 comienza a las 8:20 y termina a las 8:40, y pertenece a la doctora n.º 1 (la Sra. Marie PELISSIER).

2.2.4. La tabla [RV]

Enumera los RV asignados a cada médico:

ID: número que identifica de manera única al RV – clave primaria
JOUR: día del RV
ID_CRENEAU: franja horaria del RV —clave externa en la columna [ID] de la tabla [CRENEAUX]—; determina tanto la franja horaria como el médico correspondiente.
ID_CLIENT: número del cliente para quien se realiza la reservación – clave externa en la columna [ID] de la tabla [CLIENTS]

Esta tabla tiene una restricción de unicidad en la e sobre los valores de las columnas unidas (JOUR, ID_CRENEAU):

ALTER TABLE RV ADD CONSTRAINT UNQ1_RV UNIQUE (JOUR, ID_CRENEAU);

Si una fila de la tabla [RV] tiene el valor (JOUR1, ID_CRENEAU1) para las columnas (JOUR, ID_CRENEAU), este valor no puede aparecer en ningún otro lugar. De lo contrario, significaría que se registraron dos RV al mismo tiempo para el mismo médico. Desde el punto de vista de la programación en Java, el controlador JDBC de la base de datos ejecuta un SQLException cuando ocurre este caso.

La línea de id igual a 7 (véase [1] más arriba) significa que se reservó un RV para el horario n.º 10 y el cliente n.º 2 el 10/09/2006. La tabla [CRENEAUX] nos indica que la franja n.º 10 corresponde al horario de 11:00 a 11:20 y pertenece a la doctora n.º 1 (la Sra. Marie PELISSIER). La tabla [CLIENTS] nos indica que el cliente n.º 2 es la Sra. Christine GERMAN.

Este caso de estudio fue objeto de un artículo sobre Java ([http://tahe.developpez.com/java/primefaces]) en el que se utiliza Hibernate para Java (ORM).