2. O : Um Estudo de Caso

2.1. O Problema

Voltemos à aplicação que queremos criar. Vamos partir de uma aplicação já existente com a seguinte arquitetura:

Para quem quiser saber mais sobre:

NHibernate: Introdução ao ORM NHibernate [http://tahe.developpez.com/dotnet/nhibernate/];
Aplicação ASP.NET (WebForms) com NHibernate e Spring: Construir uma aplicação 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 o EF5 substituiu o NHibernate. Esta aplicação serve como ponto de partida para explorar o EF5. Uma vez que o Spring.NET nos permite alternar facilmente entre camadas sem causar erros, a Aplicação 2 utilizará a mesma camada [ASP.NET] que a Aplicação 1. Como este documento se centra no EF5, não explicaremos como implementar esta camada. Iremos integrá-la na Aplicação 2 para verificar se funciona. Iremos simplesmente explicar as alterações a efetuar no ficheiro de configuração do Spring.NET.

O estudo de caso é o seguinte. Pretendemos oferecer aos médicos um serviço de agendamento de consultas que funcione segundo o seguinte princípio:

um serviço administrativo gere a marcação de consultas para um grande número de médicos. Este serviço pode consistir numa única pessoa. O salário dessa pessoa é partilhado entre todos os médicos que utilizam o serviço de marcação de consultas;
o escritório administrativo e todos os médicos estão ligados à Internet;
As consultas são registadas numa base de dados centralizada, acessível através da Internet pelo escritório administrativo e pelos médicos;
As consultas são normalmente agendadas pelo pessoal administrativo. Também podem ser agendadas pelos próprios médicos. Isto acontece particularmente quando, no final de uma consulta, o médico marca uma nova consulta para o paciente.

A arquitetura do serviço de agendamento de consultas é a seguinte:

Os médicos tornam-se mais eficientes se deixarem de ter de gerir as consultas. Se houver um número suficiente deles, a sua contribuição para os custos operacionais do serviço administrativo será mínima. Chamaremos à aplicação [RdvMedecins]. Abaixo encontram-se capturas de ecrã que mostram como funciona.

A página inicial da aplicação é a seguinte:

A partir desta primeira página, o utilizador (secretário, médico) realizará uma série de ações. Apresentamo-las abaixo. A vista à esquerda mostra o ecrã a partir do qual o utilizador faz um pedido; a vista à direita mostra a resposta enviada pelo servidor.

2.2. A base de dados

A base de dados utilizada pela aplicação NHibernate é uma base de dados MySQL5 com quatro tabelas:

Iremos utilizar isto como referência para construir todas as nossas bases de dados.

2.2.1. A tabela [DOCTORS]

Contém informações sobre os médicos geridos pela aplicação [RdvMedecins].

ID: o número de identificação do médico — a chave primária da tabela
VERSION: um número que identifica a versão da linha na tabela. Este número é incrementado em 1 cada vez que é feita uma alteração na linha.
LAST_NAME: o apelido do médico
FIRST_NAME: o nome próprio do médico
TITLE: o seu título (Sra., Sra., Sr.)

2.2.2. A tabela [CLIENTS]

Os clientes dos vários médicos estão armazenados na tabela [CLIENTS]:

ID: o número de identificação do cliente — a chave primária da tabela
VERSION: número que identifica a versão da linha na tabela. Este número é incrementado em 1 cada vez que é feita uma alteração na linha.
LAST_NAME: o apelido do cliente
NOME: o nome do cliente
TÍTULO: o seu título (Sra., Sra., Sr.)

2.2.3. A tabela [SLOTS]

Apresenta os horários disponíveis para marcação de consultas:

ID: Número de identificação do intervalo de tempo - chave primária da tabela
VERSION: número que identifica a versão da linha na tabela. Este número é incrementado em 1 cada vez que é feita uma alteração na linha.
DOCTOR_ID: número de identificação do médico a quem este intervalo de tempo pertence – chave estrangeira na coluna DOCTORS(ID).
START_TIME: hora de início do intervalo de tempo
MSTART: Minuto de início do intervalo de tempo
HFIN: hora de fim do intervalo
MFIN: minutos de fim do intervalo

A segunda linha da tabela [SLOTS] (ver [1] acima) indica, por exemplo, que o intervalo 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]

Apresenta a lista de consultas marcadas para cada médico:

ID: identificador único da consulta – chave primária
DAY: dia da consulta
SLOT_ID: intervalo horário da consulta – chave estrangeira na coluna [ID] da tabela [SLOTS] – determina tanto o intervalo horário como o médico envolvido.
CLIENT_ID: ID do cliente para quem a reserva é feita – chave estrangeira na coluna [ID] da tabela [CLIENTS]

Esta tabela tem uma restrição de unicidade nos valores das colunas associadas (DAY, SLOT_ID):

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

Se uma linha na tabela [RV] tiver o valor (DAY1, SLOT_ID1) para as colunas (DAY, SLOT_ID), este valor não pode aparecer em mais nenhum outro local. Caso contrário, isso significaria que foram marcadas duas consultas ao mesmo tempo para o mesmo médico. Do ponto de vista da programação Java, o controlador JDBC da base de dados lança uma SQLException quando isto ocorre.

A linha com ID igual a 7 (ver [1] acima) significa que foi marcada uma consulta para o horário n.º 10 e o cliente n.º 2 em 10/09/2006. A tabela [SLOTS] indica-nos que o horário n.º 10 corresponde ao intervalo horário das 11h00 às 11h20 e pertence ao médico n.º 1 (Sra. Marie PELISSIER). A tabela [CLIENTS] indica-nos que o cliente n.º 2 é a Sra. Christine GERMAN.

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