2. Die -Fallstudie

2.1. Das Problem

Kommen wir zurück zu der Anwendung, die wir erstellen möchten. Wir gehen von einer bestehenden Anwendung mit folgender Architektur aus:

Für alle, die mehr erfahren möchten über:

NHibernate: Einführung in ORM Nhibernate [http://tahe.developpez.com/dotnet/nhibernate/];
ASP.NET-Anwendung (WebForms) mit NHibernate und Spring: Erstellung einer dreischichtigen Webanwendung mit ASP.NET, Spring.NET und NHibernate [http://tahe.developpez.com/dotnet/pam-aspnet/].

Wir möchten die vorherige Anwendung in diese umwandeln:

wobei EF5 anstelle von NHibernate verwendet wird. Diese Anwendung dient als Ausgangspunkt, um EF5 zu untersuchen. Da Spring.NET es uns ermöglicht, die Ebene einfach zu wechseln, ohne dass dabei etwas kaputtgeht, wird Anwendung 2 dieselbe Ebene [ASP.NET] verwenden wie Anwendung 1. Da sich dieses Dokument mit EF5 befasst, werden wir die Erstellung dieser Ebene nicht erläutern. Wir werden sie in Anwendung 2 einbinden, um zu überprüfen, ob sie funktioniert. Wir werden lediglich die Änderungen erläutern, die in der Konfigurationsdatei von Spring.NET vorgenommen werden müssen.

Die Fallstudie lautet wie folgt: Wir möchten Ärzten einen Terminvereinbarungsdienst anbieten, der nach folgendem Prinzip funktioniert:

Ein Sekretariatsdienst übernimmt die Terminvereinbarungen für eine große Anzahl von Ärzten. Dieser Dienst kann auf eine einzige Person reduziert werden. Das Gehalt dieser Person wird von allen Ärzten, die den Dienst nutzen, gemeinsam getragen;
der Sekretariatsdienst und alle Ärzte sind mit dem Internet verbunden;
die RV werden in einer zentralen Datenbank gespeichert, auf die das Sekretariat und die Ärzte über das Internet zugreifen können;
Die Vergabe von RV erfolgt normalerweise durch das Sekretariat. Sie kann aber auch von den Ärzten selbst vorgenommen werden. Dies ist insbesondere dann der Fall, wenn der Arzt am Ende einer Konsultation seinem Patienten selbst einen neuen RV zuweist.

Die Architektur des Dienstes zur Vergabe von RV ist wie folgt:

Ärzte können effizienter arbeiten, wenn sie sich nicht mehr um RV kümmern müssen. Bei einer ausreichenden Anzahl von Ärzten fällt ihr Beitrag zu den Betriebskosten des Sekretariats gering aus. Wir werden die Anwendung [RdvMedecins] nennen. Im Folgenden zeigen wir Screenshots, die ihre Funktionsweise veranschaulichen.

Die Startseite der Anwendung sieht wie folgt aus:

Von dieser ersten Seite aus führt der Benutzer (Sekretariat, Arzt) eine Reihe von Aktionen durch. Diese stellen wir im Folgenden vor. Die Ansicht auf der linken Seite zeigt die Ansicht, von der aus der Benutzer eine Anfrage stellt, die Ansicht auf der rechten Seite die vom Server gesendete Antwort.

2.2. Die Datenbank

Die von der Anwendung NHibernate verwendete Datenbank ist eine MySQL5-Datenbank mit vier Tabellen:

Sie dient uns als Vorlage für den Aufbau all unserer Datenbanken.

2.2.1. Die Tabelle [MEDECINS]

Sie enthält Informationen zu den Ärzten, die von der Anwendung [RdvMedecins] verwaltet werden.

ID: Identifikationsnummer des Arztes – Primärschlüssel der Tabelle
VERSION: Nummer zur Identifizierung der Zeilenversion in der Tabelle. Diese Nummer wird bei jeder Änderung an der Zeile um 1 erhöht.
NOM: Name des Arztes
PRENOM: sein Vorname
TITRE: sein Titel (Fräulein, Frau, Herr)

2.2.2. Die Tabelle [CLIENTS]

Die Patienten der verschiedenen Ärzte sind in der Tabelle [CLIENTS] gespeichert:

ID: Nummer zur Identifizierung des Kunden – Primärschlüssel der Tabelle
VERSION: Nummer zur Identifizierung der Zeilenversion in der Tabelle. Diese Nummer wird bei jeder Änderung an der Zeile um 1 erhöht.
NOM: Name des Kunden
PRENOM: sein Vorname
TITRE: seine Anrede (Fräulein, Frau, Herr)

2.2.3. Die Tabelle [CRENEAUX]

Sie listet die Zeitfenster auf, in denen RV möglich sind:

ID: Nummer zur Identifizierung des Zeitfensters – Primärschlüssel der Tabelle
VERSION: Nummer zur Identifizierung der Version der Zeile in der Tabelle. Diese Nummer wird bei jeder Änderung an der Zeile um 1 erhöht.
ID_MEDECIN: Nummer zur Identifizierung des Arztes, zu dem dieses Zeitfenster gehört – Fremdschlüssel auf die Spalte MEDECINS(ID).
HDEBUT: Startzeit des Zeitfensters
MDEBUT: Minuten des Zeitfensterstarts
HFIN: Endzeit des Zeitfensters
MFIN: Minuten des Zeitfensterschlusses

Die zweite Zeile der Tabelle [CRENEAUX] (siehe [1] oben) gibt beispielsweise an, dass der Termin Nr. 2 um 8:20 Uhr beginnt und um 8:40 Uhr endet und der Ärztin Nr. 1 (Frau Marie PELISSIER).

2.2.4. Die Tabelle [RV]

Sie listet die für jeden Arzt belegten RV auf:

ID: Nummer, die den RV eindeutig identifiziert – Primärschlüssel
JOUR: Tag des RV
ID_CRENEAU: Zeitfenster des Datensatzes RV – Fremdschlüssel auf die Spalte [ID] der Tabelle [CRENEAUX] – legt sowohl das Zeitfenster als auch den betreffenden Arzt fest.
ID_CLIENT: Kundennummer, für die die Reservierung vorgenommen wird – Fremdschlüssel auf die Spalte [ID] der Tabelle [CLIENTS]

Diese Tabelle verfügt über eine Eindeutigkeits für die Werte der verknüpften Spalten (JOUR, ID_CRENEAU):

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

Wenn eine Zeile der Tabelle [RV] den Wert (JOUR1, ID_CRENEAU1) für die Spalten (JOUR, ID_CRENEAU) aufweist, darf dieser Wert an keiner anderen Stelle vorkommen. Andernfalls würde dies bedeuten, dass zwei RV gleichzeitig für denselben Arzt erfasst wurden. Aus Sicht der Java-Programmierung löst der Treiber JDBC der Datenbank in diesem Fall einen SQLException aus.

Die Zeile mit dem Wert 7 für id (siehe [1] oben) bedeutet, dass am 10.09.2006 ein RV für den Terminblock Nr. 10 und den Kunden Nr. 2 gebucht wurde. Aus der Tabelle [CRENEAUX] geht hervor, dass der Termin Nr. 10 dem Zeitfenster 11:00–11:20 Uhr entspricht und der Ärztin Nr. 1 (Frau Marie PELISSIER) zugeordnet ist. Aus der Tabelle [CLIENTS] geht hervor, dass es sich bei Patient Nr. 2 um Frau Christine GERMAN handelt.

Diese Fallstudie war Gegenstand eines Java-Artikels ([http://tahe.developpez.com/java/primefaces]), in dem Hibernate für Java (ORM) verwendet wird.