2. L' : un caso di studio

2.1. Il problema

Torniamo all'applicazione che vogliamo realizzare. Partiamo da un'applicazione esistente con la seguente architettura:

Per chi volesse saperne di più su:

NHibernate: Introduzione all'ORM NHibernate [http://tahe.developpez.com/dotnet/nhibernate/];
Applicazione ASP.NET (WebForms) con NHibernate e Spring: Creazione di un'applicazione web a tre livelli con ASP.NET, Spring.NET e NHibernate [http://tahe.developpez.com/dotnet/pam-aspnet/].

Vogliamo trasformare l'applicazione precedente in questa:

dove EF5 ha sostituito NHibernate. Questa applicazione funge da punto di partenza per esplorare EF5. Poiché Spring.NET ci permette di cambiare facilmente i livelli senza compromettere il funzionamento del sistema, l'Applicazione 2 utilizzerà lo stesso livello [ASP.NET] dell'Applicazione 1. Poiché questo documento si concentra su EF5, non spiegheremo come implementare questo livello. Lo integreremo nell'Applicazione 2 per verificare che funzioni. Spiegheremo semplicemente le modifiche da apportare al file di configurazione di Spring.NET.

Il caso di studio è il seguente. Vogliamo offrire ai medici un servizio di prenotazione appuntamenti che funzioni secondo il seguente principio:

un servizio amministrativo gestisce la prenotazione degli appuntamenti per un gran numero di medici. Questo servizio può consistere in una sola persona. Lo stipendio di quella persona viene condiviso tra tutti i medici che utilizzano il servizio di prenotazione;
l'ufficio amministrativo e tutti i medici sono connessi a Internet;
gli appuntamenti vengono registrati in un database centralizzato, accessibile via Internet dall'ufficio amministrativo e dai medici;
Gli appuntamenti vengono normalmente fissati dal personale amministrativo. Possono essere fissati anche dai medici stessi. Ciò avviene in particolare quando, al termine di una visita, il medico fissa un nuovo appuntamento per il paziente.

L'architettura del servizio di prenotazione degli appuntamenti è la seguente:

I medici diventano più efficienti se non devono più gestire gli appuntamenti. Se ce ne sono abbastanza, il loro contributo ai costi operativi dell'ufficio amministrativo sarà minimo. Chiameremo l'applicazione [RdvMedecins]. Di seguito sono riportati alcuni screenshot che illustrano il suo funzionamento.

La pagina iniziale dell’applicazione è la seguente:

Da questa prima pagina, l'utente (segretaria, medico) potrà eseguire una serie di azioni. Le presentiamo di seguito. La vista a sinistra mostra la schermata da cui l'utente effettua una richiesta; la vista a destra mostra la risposta inviata dal server.

2.2. Il database

Il database utilizzato dall'applicazione NHibernate è un database MySQL5 con quattro tabelle:

Lo useremo come riferimento per creare tutti i nostri database.

2.2.1. La tabella [DOCTORS]

Contiene informazioni sui medici gestiti dall'applicazione [RdvMedecins].

ID: il numero ID del medico — la chiave primaria della tabella
VERSION: un numero che identifica la versione della riga nella tabella. Questo numero viene incrementato di 1 ogni volta che viene apportata una modifica alla riga.
LAST_NAME: il cognome del medico
FIRST_NAME: il nome del medico
TITLE: il titolo (Sig.ra, Sig.ra, Sig.)

2.2.2. La tabella [CLIENTI]

I clienti dei vari medici sono memorizzati nella tabella [CLIENTS]:

ID: il numero ID del cliente — la chiave primaria della tabella
VERSION: numero che identifica la versione della riga nella tabella. Questo numero viene incrementato di 1 ogni volta che viene apportata una modifica alla riga.
LAST_NAME: il cognome del cliente
NOME: il nome del cliente
TITOLO: il titolo (Sig.ra, Sig.ra, Sig.)

2.2.3. La tabella [SLOTS]

Elenca le fasce orarie in cui sono disponibili gli appuntamenti:

ID: numero identificativo della fascia oraria - chiave primaria della tabella
VERSION: numero che identifica la versione della riga nella tabella. Questo numero viene incrementato di 1 ogni volta che viene apportata una modifica alla riga.
DOCTOR_ID: numero ID che identifica il medico a cui appartiene questa fascia oraria – chiave esterna sulla colonna DOCTORS(ID).
START_TIME: ora di inizio della fascia oraria
MSTART: minuto di inizio della fascia oraria
HFIN: ora di fine della fascia oraria
MFIN: minuti di fine della fascia oraria

La seconda riga della tabella [SLOTS] (vedi [1] sopra) indica, ad esempio, che la fascia oraria n. 2 inizia alle 8:20 e termina alle 8:40 e appartiene al medico n. 1 (dott.ssa Marie PELISSIER).

2.2.4. La tabella [RV]

Elenca gli appuntamenti prenotati per ciascun medico:

ID: identificatore univoco dell'appuntamento – chiave primaria
GIORNO: giorno dell'appuntamento
SLOT_ID: fascia oraria dell'appuntamento – chiave esterna sulla colonna [ID] della tabella [SLOTS] – determina sia la fascia oraria che il medico coinvolto.
CLIENT_ID: ID del cliente per il quale è stata effettuata la prenotazione – chiave esterna sulla colonna [ID] della tabella [CLIENTS]

Questa tabella ha un vincolo di unicità sui valori delle colonne unite (GIORNO, SLOT_ID):

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

Se una riga nella tabella [RV] ha il valore (DAY1, SLOT_ID1) per le colonne (DAY, SLOT_ID), questo valore non può comparire in nessun altro punto. In caso contrario, ciò significherebbe che sono stati prenotati due appuntamenti contemporaneamente per lo stesso medico. Dal punto di vista della programmazione Java, il driver JDBC del database genera un'eccezione SQLException quando ciò si verifica.

La riga con ID pari a 7 (vedi [1] sopra) indica che è stato prenotato un appuntamento per lo slot n. 10 e il cliente n. 2 il 10/09/2006. La tabella [SLOTS] ci dice che lo slot n. 10 corrisponde alla fascia oraria dalle 11:00 alle 11:20 e appartiene al medico n. 1 (la sig.ra Marie PELISSIER). La tabella [CLIENTS] ci dice che il cliente n. 2 è la sig.ra Christine GERMAN.

Questo caso di studio è stato oggetto di un articolo su Java [http://tahe.developpez.com/java/primefaces] in cui viene utilizzato l'ORM Hibernate per Java.