2. O : estudo de caso

2.1. O problema

Voltemos ao aplicativo que queremos construir. Partimos de um aplicativo existente com a seguinte arquitetura:

Para quem quiser saber mais sobre:

NHibernate: Introdução ao NHibernate ORM;
aplicativo ASP.NET (WebForms) com NHibernate e Spring: Criação de um aplicativo web de três camadas com ASP.NET, Spring.NET e NHibernate [http://tahe.developpez.com/dotnet/pam-aspnet/].

Queremos transformar a aplicação anterior nesta:

onde EF5 substituiu NHibernate. Este aplicativo serve como pretexto para estudar o EF5. Como o Spring.NET nos permite mudar facilmente de camada sem causar erros, o aplicativo 2 utilizará a mesma camada [ASP.NET] que o aplicativo 1. Como este documento é dedicado ao EF5, não explicaremos como escrever essa camada. Vamos incorporá-la ao aplicativo 2 para verificar se funciona. Explicaremos apenas as alterações a serem feitas no arquivo de configuração do Spring.NET.

O estudo de caso é o seguinte. Queremos oferecer aos médicos um serviço de agendamento de consultas que funcione com base no seguinte princípio:

um serviço de secretariado cuida do agendamento de consultas para um grande número de médicos. Esse serviço pode ser realizado por uma única pessoa. O salário dessa pessoa é dividido entre todos os médicos que utilizam o serviço;
o serviço de secretariado e todos os médicos estão conectados à Internet;
as consultas são registradas em um banco de dados centralizado, acessível pela Internet, tanto pela secretaria quanto pelos médicos;
o agendamento de RV é normalmente feito pela secretaria. Ele também pode ser feito pelos próprios médicos. Esse é o caso, notadamente, quando, ao final de uma consulta, o próprio médico marca um novo RV para seu paciente.

A arquitetura do serviço de emissão do RV é a seguinte:

Os médicos ganham em eficiência se não precisarem mais lidar com o RV. Se forem em número suficiente, sua contribuição para as despesas operacionais da secretaria será baixa. Chamaremos o aplicativo de [RdvMedecins]. Apresentamos a seguir capturas de tela de seu funcionamento.

A página inicial do aplicativo é a seguinte:

A partir dessa primeira página, o usuário (Secretaria, Médico) realizará uma série de ações. Apresentamos essas ações a seguir. A imagem à esquerda mostra a tela a partir da qual o usuário faz uma solicitação; a imagem à direita, a resposta enviada pelo servidor.

2.2. O banco de dados

O banco de dados utilizado pelo aplicativo NHibernate é um banco de dados MySQL5 com quatro tabelas:

Ela servirá de referência para a construção de todas as nossas bases de dados.

2.2.1. A tabela [MEDECINS]

Ela contém informações sobre os médicos gerenciados pelo aplicativo [RdvMedecins].

ID: número que identifica o médico — chave primária da tabela
VERSION: número que identifica a versão da linha na tabela. Esse número é incrementado em 1 sempre que uma alteração é feita na linha.
NOM: o sobrenome do médico
PRENOM: seu nome
TITRE: seu título (Srta., Sra., Sr.)

2.2.2. A tabela [CLIENTS]

Os clientes dos diferentes médicos estão registrados na tabela [CLIENTS]:

ID: número de identificação do cliente — chave primária da tabela
VERSION: número que identifica a versão da linha na tabela. Esse número é incrementado em 1 sempre que uma modificação é feita na linha.
NOM: o nome do cliente
PRENOM: seu nome
TITRE: seu título (Srta., Sra., Sr.)

2.2.3. A tabela [CRENEAUX]

Ela lista os horários em que os RV são possíveis:

ID: número que identifica o intervalo horário — chave primária da tabela
VERSION: número que identifica a versão da linha na tabela. Esse número é incrementado em 1 sempre que uma modificação é feita na linha.
ID_MEDECIN: número que identifica o médico ao qual esse horário pertence – chave estrangeira na coluna MEDECINS (ID).
HDEBUT: hora de início do horário
MDEBUT: minutos de início do horário
HFIN: hora de término do horário
MFIN: minutos de término do intervalo

A segunda linha da tabela [CRENEAUX] (ver [1] acima) indica, por exemplo, que o horário nº 2 começa às 8h20 e termina às 8h40 e pertence à médica nº 1 (Sra. Marie PELISSIER).

2.2.4. A tabela [RV]

Ela lista os RV atribuídos a cada médico:

ID: número que identifica o RV de forma exclusiva – chave primária
JOUR: dia do RV
ID_CRENEAU: horário do RV – chave estrangeira na coluna [ID] da tabela [CRENEAUX] – define tanto o horário quanto o médico em questão.
ID_CLIENT: número do cliente para o qual a reserva foi feita – chave estrangeira na coluna [ID] da tabela [CLIENTS]

Esta tabela possui uma restrição de unicidade na sobre os valores das colunas associadas (JOUR, ID_CRENEAU):

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

Se uma linha da tabela [RV] tiver o valor (JOUR1, ID_CRENEAU1) para as colunas (JOUR, ID_CRENEAU), esse valor não pode aparecer em nenhum outro lugar. Caso contrário, isso significaria que dois RV foram registrados ao mesmo tempo para o mesmo médico. Do ponto de vista da programação em Java, o driver JDBC do banco de dados aciona um SQLException quando esse caso ocorre.

A linha de id igual a 7 (ver [1] acima) significa que um RV foi agendado para o horário nº 10 e o cliente nº 2 em 10/09/2006. A tabela [CRENEAUX] nos informa que o horário n.º 10 corresponde ao intervalo das 11h às 11h20 e pertence à médica n.º 1 (Sra. Marie PELISSIER). A tabela [CLIENTS] nos informa que o cliente nº 2 é a Sra. Christine GERMAN.

Este estudo de caso foi tema de um artigo Java [http://tahe.developpez.com/java/primefaces], no qual se utiliza o Hibernate para Java ORM.