2. The case study
2.1. The Problem
Let’s return to the application we want to build. We are starting with an existing application with the following architecture:
 |
For those who want to learn more about:
- NHibernate: Introduction to ORM, Nhibernate, [http://tahe.developpez.com/dotnet/nhibernate/];
- ASP.NET (WebForms) application with NHibernate and Spring: Building a three-tier web application with ASP.NET, Spring.NET, and NHibernate [http://tahe.developpez.com/dotnet/pam-aspnet/].
We want to transform the previous application into this one:
 |
where EF5 has replaced NHibernate. This application serves as a pretext for studying EF5. Because Spring.NET allows us to easily switch layers without breaking anything, Application 2 will use the same layer, [ASP.NET], as Application 1. Since this document is dedicated to EF5, we will not explain how to write this layer. We will introduce it into Application 2 to verify that it works. We will simply explain the changes to be made in the Spring.NET configuration file.
The case study is as follows. We want to offer doctors an appointment scheduling service that operates on the following principle:
- an administrative service handles RV appointments for a large number of doctors. This service can be staffed by a single person. That person’s salary is shared among all doctors using the RV service;
- the administrative service and all doctors are connected to the Internet;
- RV appointments are recorded in a centralized database, accessible via the Internet by the secretarial office and the doctors;
- RV appointments are normally scheduled by the secretariat. They may also be scheduled by the doctors themselves. This is particularly the case when, at the end of a consultation, the doctor personally schedules a new RV appointment for their patient.
The architecture of the RV assignment service is as follows:
 |
Doctors will be more efficient if they no longer have to deal with RV. If there are enough of them, their contribution to the administrative office’s operating costs will be minimal. We will call the application [RdvMedecins]. Below are screenshots showing how it works.
The application’s home page is as follows:
From this first page, the user (Secretariat, Doctor) will perform a number of actions. We present them below. The left view shows the screen from which the user makes a request; the right view shows the response sent by the server.
 |
 |
 |
 |
 |
2.2. The Database
The database used by the NHibernate application is a MySQL5 database with four tables:
We will use this as a reference for building all our databases.
2.2.1. The [MEDECINS] table
It contains information about the doctors managed by the [RdvMedecins] application.
 |  |
- ID: ID number for the doctor—primary key of the table
- VERSION: ID number for the version of the row in the table. This number is incremented by 1 each time a change is made to the row.
- NOM: the doctor’s last name
- PRENOM: their first name
- TITRE: their title (Ms., Mrs., Mr.)
2.2.2. The [CLIENTS] table
The clients values for the various doctors are stored in the [CLIENTS] table:
 |  |
- ID: customer ID number—primary key of the table
- VERSION: number identifying the version of the row in the table. This number is incremented by 1 each time a change is made to the row.
- NOM: the customer's last name
- PRENOM: their first name
- TITRE: their title (Ms., Mrs., Mr.)
2.2.3. The [CRENEAUX] table
It lists the time slots where RV entries are possible:
 |
 |
- ID: ID number for the time slot—primary key of the table
- VERSION: ID number for the version in the table row. This number is incremented by 1 each time a change is made to the row.
- ID_MEDECIN: ID number for the doctor to whom this time slot belongs – foreign key on column MEDECINS (ID).
- HDEBUT: slot start time
- MDEBUT: slot start minutes
- HFIN: slot end hour
- MFIN: slot end minutes
The second row of table [CRENEAUX] (see [1] above) indicates, for example, that slot No. 2 begins at 8:20 a.m. and ends at 8:40 a.m. and belongs to doctor No. 1 (Ms. Marie PELISSIER).
2.2.4. The table [RV]
lists the RV codes assigned to each doctor:
 |
- ID: ID number uniquely identifying the RV – primary key
- JOUR: day of the RV
- ID_CRENEAU: time slot for RV – foreign key on the [ID] column of the [CRENEAUX] table – determines both the time slot and the doctor in question.
- ID_CLIENT: customer ID for whom the reservation is made – foreign key on the [ID] column of the [CLIENTS] table
This table has a uniqueness constraint on the values of the joined columns (JOUR, ID_CRENEAU):
If a row in table [RV] has the value (JOUR1, ID_CRENEAU1) for the columns (JOUR, ID_CRENEAU), this value cannot appear anywhere else. Otherwise, this would mean that two RV records were captured at the same time for the same doctor. From a Java programming perspective, the JDBC driver in the database triggers a SQLException when this occurs.
The id line equal to 7 (see [1] above) means that a RV was booked for slot #10 and client #2 on 09/10/2006. The table [CRENEAUX] tells us that slot no. 10 corresponds to the time slot 11:00 a.m. – 11:20 a.m. and belongs to doctor no. 1 (Ms. Marie PELISSIER). Table [CLIENTS] tells us that client No. 2 is Ms. Christine GERMAN.
This case study was the subject of a Java article [http://tahe.developpez.com/java/primefaces] in which Hibernate for Java is used.