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 a ORM Nhibernate [http://tahe.developpez.com/dotnet/nhibernate/];
applicazione ASP.NET (WebForms) con NHibernate e Spring: Realizzazione 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 è un pretesto per studiare EF5. Poiché Spring.NET ci permette di cambiare facilmente livello senza compromettere il funzionamento dell’applicazione, l’applicazione 2 utilizzerà lo stesso livello [ASP.NET] dell’applicazione 1. Poiché questo documento è dedicato a EF5, non spiegheremo come scrivere questo livello. Lo inseriremo 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. Si desidera offrire ai medici un servizio di prenotazione appuntamenti che funzioni secondo il seguente principio:

un servizio di segreteria gestisce le prenotazioni per un gran numero di medici. Questo servizio può essere gestito da una sola persona. Il suo stipendio viene ripartito tra tutti i medici che utilizzano il servizio;
il servizio di segreteria e tutti i medici sono collegati a Internet;
gli appuntamenti vengono registrati in una banca dati centralizzata, accessibile via Internet sia dalla segreteria che dai medici;
la registrazione dei RV viene normalmente effettuata dalla segreteria. Può essere effettuata anche dai medici stessi. Ciò avviene in particolare quando, al termine di una visita, il medico assegna personalmente un nuovo RV al proprio paziente.

L’architettura del servizio di registrazione del codice RV è la seguente:

I medici guadagnano in efficienza se non devono più gestire il RV. Se sono in numero sufficiente, il loro contributo alle spese di funzionamento della segreteria sarà modesto. Chiameremo l’applicazione [RdvMedecins]. Di seguito presentiamo alcune schermate che ne illustrano il funzionamento.

La pagina iniziale dell’applicazione è la seguente:

Da questa prima pagina, l’utente (Segreteria, Medico) potrà eseguire una serie di azioni. Le presentiamo di seguito. La schermata a sinistra mostra la pagina da cui l’utente effettua una richiesta, quella a destra la risposta inviata dal server.

2.2. Il database

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

Ci servirà da riferimento per costruire tutti i nostri database.

2.2.1. La tabella [MEDECINS]

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

ID: numero identificativo del medico – 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.
NOM: il cognome del medico
PRENOM: il suo nome
TITRE: il suo titolo (Sig.na, Sig.ra, Sig.)

2.2.2. La tabella [CLIENTS]

I clienti dei diversi medici sono registrati nella tabella [CLIENTS]:

ID: numero identificativo del cliente - 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.
NOM: il nome del cliente
PRENOM: il suo nome
TITRE: il suo titolo (Sig.na, Sig.ra, Sig.)

2.2.3. La tabella [CRENEAUX]

Elenca le fasce orarie in cui sono possibili i RV:

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.
ID_MEDECIN: numero identificativo del medico a cui appartiene questa fascia oraria – chiave esterna sulla colonna MEDECINS(ID).
HDEBUT: ora di inizio della fascia oraria
MDEBUT: minuti di inizio della fascia oraria
HFIN: ora di fine della fascia oraria
MFIN: minuti di fine della fascia oraria

La seconda riga della tabella [CRENEAUX] (cfr. [1] sopra) indica, ad esempio, che la fascia 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 i RV assegnati a ciascun medico:

ID: numero che identifica in modo univoco il RV – chiave primaria
JOUR: giorno del RV
ID_CRENEAU: fascia oraria del RV – chiave esterna sulla colonna [ID] della tabella [CRENEAUX] – determina sia la fascia oraria che il medico interessato.
ID_CLIENT: numero del cliente per il quale è stata effettuata la prenotazione – chiave esterna sulla colonna [ID] della tabella [CLIENTS]

Questa tabella presenta un e vincolo di unicità sui valori delle colonne collegate (JOUR, ID_CRENEAU):

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

Se una riga della tabella [RV] presenta il valore (JOUR1, ID_CRENEAU1) per le colonne (JOUR, ID_CRENEAU), tale valore non può comparire in nessun altro punto. Altrimenti, ciò significherebbe che due RV sono stati registrati contemporaneamente per lo stesso medico. Dal punto di vista della programmazione Java, il driver JDBC del database avvia un SQLException quando si verifica questo caso.

La riga di id pari a 7 (cfr. [1] sopra) indica che un RV è stato prenotato per la fascia oraria n. 10 e il cliente n. 2 il 10/09/2006. La tabella [CRENEAUX] ci indica che la fascia 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 indica che il cliente n. 2 è la sig.ra Christine GERMAN.

Questo caso di studio è stato oggetto di un articolo Java [http://tahe.developpez.com/java/primefaces] in cui si utilizza Hibernate per Java ORM.