Mas programadores Java EE não tão nem aí. O HttpSession é tão acessível e tão simples de usar que o programador não pensa duas vezes antes utilizá-lo. E talvez aí seja a fonte dos problemas: usa-se demais! As pessoas não se dão conta de que é difícil escalar aplicações web que usam muito Session; e que também pode ir contra a uma boa experiência de usuário, como o voltar ou o favoritar que deixa de funcionar. Acredito que existam alternativas tão melhores que o HttpSession que este só seria raramente lembrado. Veja as seguintes situações e suas alternativas.

Preciso fazer cache de entidades

Veja, o cache é sobre entidades obtidas através de classes da camada de persistência; mas a HttpSession é uma classe de arquitetura que somente a camada de apresentação depende. Entretanto, ao guardar e obter objetos na sessão de usuário, a camada de apresentação está ido além de seu escopo, que é simplesmente mostrar a tela para o usuário; é uma solução ruim.

Uma solução boa é usar bibliotecas de cache de verdade como Memcached ou JBoss Cache. Pois você pode colocá-las na camada de persistência, e ainda assim, não se amarrar à tecnologia Web. Sem falar que o cache, com essas ferramentas, é único por todo o sistema (e não único por usuário, como na Session), o que lhe garante maior controle sobre os dados não-atualizados.

Minha dica é, se não houver uma configuração de cache automatizado, como no Hibernate, ponha-os em classes que funcionam como decorator de DAOs, mas isso eu já falei antes.

O framework web guarda dados em sessão

Algumas vendors gostam de fazer ferramentas que sejam jumento-proof, com o intuito de convencer gerentes de que é possível contratar programadores a preço de banana. Muitos frameworks web já saem com essa mentalidade na sua concepção, e é tão jumento-proof que a ferramenta faz uso constante da HttpSession internamente sem o programador perceber.

Pra não usar sessão nesses casos, só há um jeito: troque de framework web, para um que nunca faça uso implícito de sessão. Porém, se você está no meio de um projeto, ainda é possível criar novas páginas com um novo framework, mas mantendo as antigas, só fazendo a transição quando estas precisarem de alterações. Ah, e se onde você está exigem o uso de uma “arquitetura padrão”? Então troque de emprego, porque ninguém merece, né?

O objeto que eu estou armazenando vai ser usado na próxima tela

São duas situações bastante comuns:

1. existe uma tela onde aparece uma lista de um domínio qualquer; dado o clique de um elemento, uma nova página com os detalhes aparecerão;
2. existe uma página com campos “somente-leitura”, onde o clique de um link muda para uma página com campos editáveis.

Nos dois casos, um desenvolvedor comum percebe logo que, como a segunda página irá requisitar os mesmos dados que a primeira, coloca os dados da primeira requisição na sessão para ser consultado depois. Não faça isso! Você pode estar achando que está economizando no banco, mas está negligenciando outros fatores. Exemplos: é mais fácil escalar um banco de dados quando há muita leitura (topologia mestre-escravo, por exemplo), do que escalar sessão de servidor web. E, às vezes, o usuário gostaria de entrar pela segunda página diretamente.

Prefira realizar a consulta de novo quando ocorrer a segunda requisição, e controle o estado pela URL, colocando a chave primária do domínio como parâmetro. Isso te livra de um monte de inconveniências, como no caso de o usuário apertar o botão voltar ou consultar a URL no histórico.
“Ah, mas toda vez que faço uma consulta, um porquinho-da-índia morre.” Então o problema pode ser resolvido pelo primeiro ítem acima: cache.

A lógica de negócio exige várias telas para sua conclusão

Existem casos onde a conclusão de um objetivo depende do envio de vários formulários, mas isso não é tão comum de acontecer. Mesmo assim, muitos consideram que escrever cada formulário no banco não compensa, porque o usuário pode desistir no meio do caminho. A solução mais comum é ficar guardando dados intermediários na sessão até chegar a última tela do processo, quando tudo é persistido.

Bom, pode ser um raro caso onde seja interessante armazenar na sessão. Porém, faça a coisa direito! Não espalhe por todo o código o armazenamento e a obtenção de objetos na Sessão. Se você tiver usando EJB, use um Stateful Session Bean para armazenar todos os objetos obtidos do usuário antes de persistir. Se tiver usando Spring ou outro contêiner de injeção de dependência, use uma classe de escopo de sessão para armazenar todos os objetos. Use o mínimo de classes de infraestrutura para evitar dependências desnecessárias.

Vou implementar um “carrinho de compras”

Todo mundo aprendeu HttpSession usando um exemplo de carrinho de compras. O problema é gente acreditar que, pra esse caso, só existe uma única solução possível, a única que lhe ensinaram, o armazenamento na sessão de usuário! Porém, isso pode não ser verdade num mundo real. Imagine que alguém tenha colocado um produto no carrinho virtual, mas desistido de comprar. Talvez essa informação de compra não-efetuada possa ser interessante para a loja, pois ela pode gerar alguma newsletter. Portanto, manter esses dados na Session está fora de cogitação!

Não quero dizer que um carrinho deve ser feito sempre em banco, mas determinadas regras de negócio podem ser implementados de jeitos diferentes dependendo do contexto. Os exemplos e templates de livros e apostilas só servem pra aprendizagem, não leve-os tão a sério!

A mais recente invenção dos caras é a GO, uma linguagem de programação de sistemas, compilável, com coletor de lixo e primitivas para concorrência. Em poucos dias, causou vários comentários que, obviamente, se arrefeceram uma semana depois. Mas não vamos deixar essa ausência de comentários abalar este post onde, com apenas meus poucos dias de estudo, mostrarei meus pitacos com relações a aspectos da linguagem que mais se destacam dos demais. (Não mostrarei como montar o ambiente, nem como fazer compilação. Isso você encontra no Google.)

Sintaxe

A sintaxe é ligeiramente igual às famílias da linguagem C (como Java, C++ ou C#), com a diferença que os tipos vem depois do nome da variável ou da função. Um exemplo:

package main
 
import "fmt";
 
// constante, tipo é implícito
const Pi = 3.1415
 
/* 
Métodos começam com "func", seguido do nome,
dos parâmetros e depois o retorno.
No parâmetro, tipo "int" vem depois no nome "v"
*/
func doubleIt(v int) int {
	return v * 2;
}
 
// o começo de um programa é o método main do pacote main
func main() {
	// variáveis começam com var, seguido de nome e tipo
	var number1 int = 8;
	// mas também pode ser assim
	var number2 = 10;
	// ou assim
	number3 := 12;
 
	fmt.Printf("Number1: %d\n", doubleIt(number1));
	fmt.Printf("Number2: %d\n", doubleIt(number2));
	fmt.Printf("Number3: %d\n", doubleIt(number3));
}

Pode parecer muito revolucionário, mas não é! Dê uma olhada em Haskell ou Erlang e depois a gente conversa.

Sem herança nem sobrecarga, e muito diferente

Em Go, existe a noção de objetos, mas não do jeito tradicional, como visto por aí. Se bobear, alguns nem a chamem de orientado a objetos, afinal.

Primeiro, que não existe herança: todos os objetos não fazem parte de uma classe pai e nem há a possibilidade de classes filhas. Como consequência, a composição de objetos é a única forma possível de se trabalhar. E o mais interessante é que, sem heranças, uma grande Caixa de Pandora desaparece, porque:

• os métodos e atributos protected vão embora: só existe visibilidade pública e privada ao pacote, e seu discernimento é feito da seguinte forma: quando um atributo ou método começa em letra maiúscula, é visível a todo mundo; quando minúscula, é protegido (mais sobre isso daqui a pouco).
• Nada de atributo virtual que tanto enche quem programa em C# ou C++. Nada de depender do “worst-case” de outras linguagens que assumem que todo dispatch de métodos é dinâmico. Em Go, por objetos não terem filhos, todo dispatch de métodos é estático, a menos que você esteja usando uma referência à interface (mais sobre isso depois).

Além do mais, diferente de Java e mais parecido com Python, o atributo this não é implícito. E não, não fica no primeiro parâmetro do método, mas num lugar especial, antes do nome do método. Também não há a noção de um escopo de classe onde todos os métodos ficam dentro. Em Go, primeiro é criada uma struct, e fora dela, os métodos – lembra um pouco Javascript.

Pra não ficarem boiando, um exemplo de uma classe Time simplificada, que exibe horas e minutos:

package mytime
 
import "fmt"
 
// os atributos de uma classe ficam numa struct
type Time struct {
	hour uint;
	minute uint;
}
 
// método "solto" que cria um Time.
// repare que, por iniciar em letra minúscula,
// só codigos sobre o pacote mytime podem acessá-lo
func newTime(hour uint, minute uint) *Time {
	// um jeito de iniciar uma struct
	t := Time {0, 0};
	// minutos - overflow em hora
	t.minute = minute % 60;
	t.hour = minute / 60;
	// horas - ignora overflow
	t.hour += hour % 24;
 
	return &t;
}
 
// método de fábrica
// não existe construtor de objetos
// letra maiúscula indica que é método público
func Create(hour uint, minute uint) *Time {
	return newTime(hour, minute);
}
 
// aqui é que fica interessante
// este método torna-se membro de Time ao declará-lo como receptor
// (declaração antes do nome do método)
func (t *Time) AddMinute(min uint) {
	totalMin := t.minute + min;
	t.minute = totalMin % 60;
 
	t.AddHour(totalMin / 60);
}
 
func (t *Time) AddHour(hour uint) {
	totalHour := t.hour + hour;
	t.hour = totalHour % 24;		
}
 
func (t * Time) Increment() {
	t.AddMinute(1);
}
 
// os métodos de print chamam esse método
func (time *Time) String() string {
	return fmt.Sprintf("%02d:%02d", time.hour, time.minute);
}

Ah, ia me esquecendo! As interfaces! Um exemplo que eu precisei fazer é criar um tipo standardInput que lê do File Descriptor 0 (zero) (em Unix, 0 é sdtin, 1 é stdout e 2 é stderr), porque não existe um método scanf, como em C.

// tipo necessário para o reader do bufio,
// que aceita qualquer classe com interface io.Reader		
type standardInput struct {
 
}
 
func (si *standardInput) Read(p []uint8) (n int, err os.Error) {
	r, e := syscall.Read(0, p);
	if e != 0 {
		err = os.Errno(e);
	}
	return int(r), err;		
}

Não tem nada de implements aí, mas o tipo já implementa a interface io.Reader, apenas porque aquele realiza o mesmo método deste. Isso tanto é verdade que quando é usado como parâmetro para bufio.NewReader, não ocorre problemas.

Com paralelismo mais fácil, o design muda

Goroutines é o jeito da linguagem implementar paralelismo. Não chega a ser tão “na unha” quanto a Thread em Java ou a pthread em C/Posix, mas não é tão alto nível quanto o modelo de atores implementado em Erlang ou Scala.

Uma goroutine é um método que roda em background, e que não avisa ninguém quando termina a execução. Não existe uma comunicação entre o chamador e o chamado, a não ser com o uso de channels: uma estrutura síncrona e bidirecional para troca de mensagens. Como comparação, parece igual ao C, onde é possível dar um fork no processo (criar goroutine), e depois fazer comunicação entre si através de pipes (channels). Porém, com Go é muito mais fácil e flexível.

Goroutine lembra apenas vagamente o modelo de coroutines em Python (com seu yield, next e send), ou o modelo de Fibers do Ruby 1.9. Nesses, a diferença é que não existem channels, porque os métodos de envio e recebimentos de mensagens fazem parte da referência da coroutine.

Acredito que, apesar de goroutine estar associado à otimização de aplicativos que rodam em múltiplos cores, a grande vantagem pode ser uma melhor modularização das aplicações. Já vi idéias de se usar uma corrotina para separar códigos com estados mutáveis dos não-mutáveis, mas isso eu discutiria num outro post. Por hora, resolvi fazer uma aplicação interativa que pergunta ao usuário como manipular a hora (classe definida anteriormente). Resolvi fazer uma goroutine que isola o input-output do restante da aplicação. Sim, com certeza, não vai melhorar a execução paralela, mas modulariza melhor. Primeiro, a parte do input-output no código abaixo:

package iocontrol
 
import (
	"bufio";
	"syscall";
	"fmt";
	"os";
	"strings";
	"strconv";
)
 
 
type Query struct {
	What string;
	HowMany uint;
}
 
// tipo necessário para o reader do bufio,
// que aceita qualquer classe com interface io.Reader		
type standardInput struct {
 
}
 
func (si *standardInput) Read(p []uint8) (n int, err os.Error) {
	r, e := syscall.Read(0, p);
	if e != 0 {
		err = os.Errno(e);
	}
	return int(r), err;		
}
 
// converte uma string para o tipo Query
func ToQuery(line string) *Query {
 
	// separando a linha em dois valores
	arr := strings.Split(line, ":", 2);
 
	var what string = "";
	if (len(arr) >= 1) {
		// o primeiro é uma string sem espaços em volta
		what = strings.TrimSpace(arr[0]);
	}
 
	// não havendo uma string com dois pontos no meio,
	// o array tem tamanho 1
	var howMany uint = 0;
	if (len(arr) == 2) {
		// o segundo é um número
		var err os.Error;
		howMany, err = strconv.Atoui(
			strings.TrimSpace(arr[1]));
 
		if (err != nil) {
			fmt.Println(err);
		}
	}
	// criando a estrutura Query
	return &Query{what, howMany};
}
 
func IOControl(channel chan string) {
	for {
		// obtendo do channel a resposta a ser exibida
		// na tela
		output := <-channel;
 
		fmt.Println(output);
 
		// lendo a linha de comando
		reader := bufio.NewReader(&standardInput{});
		line, err := reader.ReadString('\n');
		if err == nil {
			channel <- line;
		} else {
			channel <- "error:0";
		}
	}
}

O código que vai virar uma goroutine é o último aí em cima, o IOControl. No código principal abaixo, será criado o channel e a goroutine para execução.

package main
 
import (
	"fmt";
	"./mytime";
	"./iocontrol";
)
 
func main() {
 
	// criando um channel
	var io = make(chan string);
	// e criando uma goroutine
	go iocontrol.IOControl(io);
 
	time := mytime.Create(0, 0);
 
	fmt.Println("Possible commands:\n"
		"hour : n\n"
		"minute : n\n"
		"tick\n"
		"exit\n");
	// mandando o time em String para o channel "io"
	io <- time.String();
 
	loop: for {
		// obtendo do channel uma string do próximo pedido
		query := iocontrol.ToQuery(<-io);
 
		// "switch" em Go não requer "break"
		switch query.What {
		case "hour":
			time.AddHour(query.HowMany);
		case "minute":
			time.AddMinute(query.HowMany);
		case "tick":
			time.Increment();
		case "error":
			fmt.Println("an error occurred");
		case "exit":
			break loop;
		}
 
		io <- time.String();
	}
}

Executando-o, será perguntado como e quanto a acrescentar na hora atual, até que você digite exit.

Preciso dizer também que não é difícil cometer erros na programação paralela. Eu por exemplo, esqueci de por o conteúdo de IOControl dentro de um laço infinito. E aí, com a thread morta após a primeira rodada de resposta e pergunta, o channel foi bloqueado na escrita sem ninguém pra ler. Com isso, a aplicação em entrou em deadlock, havendo a interrupção do programa com o erro na tela. Ou seja, não é tão desgraçado quanto Thread, mas fique atento.

Sem exceção, literalmente

Talvez isso decepcione alguns, mas a linguagem Go não tem exceptions. Ainda não digeri bem essa notícia, mas existem coisas que fazem com que essa linguagem não caia na armadilha do C.

Uma é que o “finally” pode ser substituído pelo defer, que indica o comando que precisa ser invocado incondicionalmente antes da saída do método. Outra, é que, como em Go é possível haver múltiplos retornos, criam-se métodos com dois retornos, o primeiro sendo o conteúdo normal e o segundo o código de erro (se houver). Assim:

 
package main
 
import (
	"os";
	"io";
	"flag";
	"fmt";
)
 
func data(name string) (string, os.Error) {
	var content string = "";
 
	f, err := os.Open(name, os.O_RDONLY, 0);
	if (err == nil) {
		defer f.Close();
		var rawContent []byte = nil;
		rawContent, err = io.ReadAll(f);
		content = fmt.Sprintf("%s", rawContent);
	}
	return content, err;
}
 
func main() {
	flag.Parse();
 
	filename := flag.Arg(0);
 
	content, err := data(filename);
 
	if (err == nil) {
		fmt.Println(content);
	} else {
		fmt.Println(err);
	}
}

O compilador impede que método com dois retornos seja associada a apenas uma variável (mesmo com tipo implícito). Então, supõe-se que o programador não tenha como esquecer de tratar os erros.

Conclusão

Go não é uma linguagem inovadora, mas pode ser um refresco para quem precisa de uma linguagem que tenha um contato próximo à máquina, e não quer depender de C ou C++. Nitidamente, é uma linguagem muito crua, e muitos anos de desenvolvimento precisam acontecer. Mas tem potencial.

P.S.: “Go With the Flow” é um rock do Queens of the Stone Age.

Outros usam também a conhecida citação “programar é difícil” para demonstrar que aprender novas linguagens não vale a pena, já que é contra-senso encarar coisas difíceis todo ano. Discordo, uma coisa é aprender a programar, outra é aprender uma nova linguagem. Programar é um conceito abstrato: transformar uma idéia em solução computacional. Linguagem é concreto: a ferramenta utilizada para por a solução computacional em prática. Confundir programação com linguagem é típico de quem nunca aprendeu mais de uma linguagem.

Aprender uma nova linguagem é útil. Principalmente quando você sai de uma “visão de mundo”, que é apregoada pela comunidade da linguagem, e entra numa outra, completamente diferente. Isso é tão libertador quanto aqueles sortudos viajantes, que andam de país em país; onde, em cada uma, percebe como as pessoas são diferentes e que existe um mundo muito maior do que eles próprios supunham imaginar.

Tudo isso para sugerir duas linguagens da cauda longa: uma é Haskell, linguagem funcional que gera código nativo (com desempenho comparável a C), a outra é Erlang, linguagem também funcional com foco em concorrência e que roda em uma máquina virtual especial para sistemas que não podem cair.

Eu estou aprendendo Haskell e comecei pelo ótimo tutorial Learn You a Haskell for Great Good, escrito pelo esloveno Miran Lipovača. Já Erlang (que eu havia começado a aprender há dois anos atrás, mas parei no meio), pretendo comecar no ano que vem, e irei seguir um tutorial que ainda não li, mas é cria do anterior: Learn You Some Erlang for Great Good, escrito pelo franco-canadense Frederic Trottier-Hebert.

Se você já está de saco cheio da mediocriade dos usuários de Java, vale a tentativa.

O autor defende que horas e pessoas não são intercambiáveis, ou seja, não dá para aumentar a equipe e esperar que o produto seja entregue mais rápido. Com mais pessoas, pode ser que seja mais rápido, pode ser que seja a mesma coisa, ou ainda pode ser mais lento que se mantivesse a equipe menor. E foi ainda mais enfático: adicionar pessoas num projeto atrasado, deixa-o mais atrasado.

A razão para esse fenômeno, para muitos ainda contraintuituvo, é que determinadas tarefas são difíceis de serem feitas em paralelo, e quanto mais pessoas, maior o tempo gasto em comunicação entre os membros, em detrimento do trabalho “útil”.

Uma outra coisa que o livro fala é que a diferença de produtividade entre um excelente programador e um mau programador é de 10 para 1. O que significa que nem sempre compensa contratar os piores programadores porque não compensa pelo custo-benefício.

Mas chega a desanimar se comparar o livro com a realidade brasileira. Não se fala na área man-month, man-day, homens-mês ou homens-dia; fala-se simplesmente hora (do tipo: “essa alteração leva tantas horas”), como se a pessoa encarregada em construir o programa simplemente ficasse fora da equação, e o projeto ficasse pronto pela simples passagem do tempo.

Pra piorar: o valor percebido de um software está em quanto satisfez as expectativas do cliente, não em quantas horas foram gastas na construção. Entre uma feature que traz grande satisfação, mas poucas horas, e outra que traz pouca satisfação, mas muitas horas; a última seria economicamente vantajosa pra quem vende horas. (Percebe porque está cheio de consultoria pereba?)

E a razão 10:1 para a produtividade entre o melhor e o pior pode até indicar pra uma empresa de software que vale a pena contratar o melhor. Mas como são raras as empresas sensíveis a esse ponto, essa razão significa simplesmente uma coisa: quem faz muito ganha relativamente pouco e quem faz pouco ganha relativamente muito. Implica que não é vantagem para nenhum programador melhorar seu próprio nível educacional, pois uma eventual reciclarem teria pouco reconhecimento.

E isso é verdade! Acredito que tenha muitos profissionais que não sabem como é um bom projeto de software, seja porque nunca trabalhou num, seja porque nunca se qualificou para tal.

Dá até tristeza ler “The Mythical Man-Month”.

Incrivelmente, os caras da nossa área sentem-se como alquimistas, na busca pela tranformação do ferro em ouro. Rails, por exemplo, é ainda visto pelos noobs como um framework que iria trazer incríveis ganhos de produtividade em relação ao Java. Mas quando o cara começa a “pegar mais” nos estudos, percebe uma coisa incômoda: o framework não traz tanto ganho assim! Só-que não traz mesmo! Software é complexo de se fazer, porque você ainda terá de lidar com espectativas de usuários, com facilidade de uso e com facilidade de manutenção, independentemente de qual linguagem utilizada. (Se bobear, talvez seja esse o motivo da adoção de Rails ser fraca: não é produtivo o bastante.)

Mas ignorar Rails por não ser bala de prata é imbecil demais! É a opção, esquisita, das pessoas que só irão sair da zona de conforto quando a verdadeira bala de prata for apresentada diante de seus olhos. Porém, a solução mágica não existe, né? Meu, Rails é mais produtivo, um pouquinho só, e não é em todas as determinadas situações. Ainda assim, vale a pena aprender, pois a proporção entre legais/idiotas é alto entre os “railers”, ao contŕario dos javeiros. E sua cultura de testes é de invejar qualquer um.

Se ainda não conhece, vai atrás e aprenda. Não deixe o conforto pela espera da solução mágica tomar conta de você.

P. O que é MVC?
R. Háááá! Ainda bem que perguntou, acredita que tem gente que faz cara de conteúdo ao ouvir essas três letras? Enfim, deixa pra lá. MVC é um pattern usado, geralmente, para apresentações visuais de uma aplicação. Por ser pattern, implica que MVC também é uma descrição de uma solução para um problema recorrente; e que também não é uma receita de bolo para ser seguido de olhos vendados. O nome segue a sigla das três “coisas” que a aplicação vai ser dividida:

Model: é como o seu programa seria se o usuário fosse um “über-geek” e pudesse manipular o sistema fazendo simples classes com main() invocando as funções desejadas. Ou seja, é o domínio do seu sistema.
View: é o que o Homer Simpson do seu usuário vê: uma representação visual do domínio realizado pelo model.
Controller: é o que fica entre o model e a view. Entre várias coisas, ele faz o que o model não deve fazer: manipular a view.

Implicação: o Controller conhece a View e o Model, a View conhece o Model, e o Model não conhece ninguém.

P. Model, View e Controller são camadas, certo?
R. Não, na realidade, nunca vi ninguém por nome nesses “troços”. Sério! Às vezes, ouvi dizer que eram componentes, outros que eram camadas. Não acho nenhum dos dois nomes apropriados. Componentes remetem ao modismo do início da década de 00 de se usar “componentes reusáveis” por “operários” em “fábricas de softwares” (eca!). Ou então a um outro modismo de componentes distribuídos como COM+ ou EJB (daqueles antigão). Nenhuma das duas coisas deram certo, e o MVC não tem nada a ver com isso. E camadas refere-se a um estilo de design para dividir um domínio grande, que pode ser feito num software com ou sem interface visual.

A real é que, na dúvida, o pessoal dá um jeito não dizer em que Model, View e Controller são classificados.

P. Mas perái! M, V e C são camadas sim! Model é a de persistência, View, a de apresentação e Controller, de negócio!
R. Nããããão, tá loco! Ponha uma coisa na sua cabeça: os objetivos tanto da divisão em camadas, quanto do MVC são distintas: a primeira tem o objetivo de controlar dependências, a segunda, de representar um domínio visualmente. Não são a mesma coisa, e nem dá para unificá-las em um modelo único. Algumas classes suas serão uma coisa do ponto de vista do MVC e serão outra coisa do ponto de vista das camadas.

P. O Controller serve para controlar o sistema?
R. Não, o nome controller é que é confuso, e remete a alguns programadores o “objeto deus” (God Object) ou o “objeto bolha-assassina” (Blob Object). Porém, objetos deuses são anti-patterns, ou seja, soluções aparentemente ideiais para problemas recorrentes que causam mais problemas ainda. Quando vier à sua cabeça “Controller”, pense-o como “Input Controller” (controlador de entrada), e este “coiso” deve fazer, estritamente, as seguintes atividades:
- ouve eventos;
- obtém os parâmetros de entrada desejados da View;
- obtém do Model um domínio (invariavelmente, este está num meio persistente);
- chama um método do domínio;
- escolhe a view a ser renderizada, fazendo “bind” de algum domínio do Model.

Não raro, programadores pouco experientes colocam, no “Controller”, lógicas de negócio ou tranformações de objeto para a view. Não é isso, remova esses códigos e ponham nos seus devidos lugares.

P. Ouvi falar de um tal de Model 2, ele é diferente do MVC?
R. Model 2 é uma adaptação do MVC, usando tecnologias padrão do J2EE como era conhecido no início da década de 00 (ou seja: Struts ou Servlet e JSP). O nome é puramente mercadológico, servia para diferenciar do “Model 1″, que era a utilização exclusiva de JSP para construção da aplicação web (assim como era o ASPão e o PHP). Por ser intimamente relacionado com tecnologias ultrapassadas, toda a burocracia da época está no Model 2, como Form Beans e XMLs, manipulação direta de mapas de escopos; sem falar de domínios fracos, normalmente misturados no meio da view ou das queries do banco. Minha recomendação: esqueça Model 2, porque você pode aprender MVC por outros meios.

P. O MVC da Web é diferente do MVC do Desktop?
R. Sim, existem duas diferenças: 1) um Controller de Desktop recebe eventos de clique do mouse, de teclado, de botões e outros componentes; um Controller de Web recebe exclusivamente eventos de submissão. Consequência: aplicações Desktop são orientadas a eventos, enquanto aplicações Web, orientadas a fluxos. Tudo que uma aplicação web entende é uma “stringona” com os dados de um suposto formulário (não dá pra saber se o cliente é humano ou que viu a interface gráfica) e que precisa devolver uma nova “stringona” para o cliente que, supostamente, renderiza para algum desenho gráfico. A aplicação Desktop sabe exatamente os eventos recebidos e pode agir diferentemente para cada um deles. 2) A View de Desktop mantém sincronia constante do Model (através do pattern Observer), qualquer alteração que o usuário fizer no model através de um painel, será refletida imediatamente em outros painéis que, porventura, estejam visualizando o mesmo Model. Na Web, não existe nada disso, a partir do momento em que o usuário está diante de uma tela, essa representação do Model estará desconectada do Model real e o usuário não saberá quanto (e se) o Model mudou. O único momento de mudança é quando o usuário aperta F5, mas isso implica num evento consciente do usuário, não numa coisa automática, como as aplicações Desktop de qualidade fazem.

P. Estava pensando em fazer um MVC distribuído, penso que o Model ficaria no Server e a View, no Client; só não sei onde ficaria o Controller, tem alguma sugestão?
R. Antes de mais nada, não existe MVC distribuído. O erro da sua pergunta baseia-se numa premissa equivocada, a de que é possível esconder a distribuição na aplicação. Não pode, e pra piorar, muitas “vendors” no passado (e ainda no presente) vendem soluções onde você poderia chamar um objeto remoto como se fosse local. Mas na real, chamadas locais e remotas somente são iguais quando ocorre sucesso, não quando ocorrem falhas, como queda na rede, versões incompatíveis ou falhas de autenticação/autorização.

Se você realmente precisar de uma aplicação distribuída (ex.: uma aplicação Desktop em C# conversando remotamente com um servidor Tomcat) você terá um MVC para o Client (o Model são Active Records que se comunicam com o Server, a View é o módulo onde se instancia componentes e o Controller, os métodos que entende os eventos) e um outro MVC para o Server (o Model são entidades, com seus services e mapeamento objeto-relacional, a View é XML, JSON, um formato binário ou outro qualquer e o Controller é o que entende requisições remotas).

P. Tenho uma aplicação Web, gostaria de reaproveitar o Controller se precisasse mudar minha aplicação para Desktop, como fazer isso?
R. Não faz. O controller é intimamente ligado à view, ou seja, nova view, novo controller. A origem do seu problema pode ser Controllers agindo como God Objects (ver aqui), e a solução seria um refactoring, não um Controller multi-uso.

P. O que o framework MVC faz? Age como Controller?
R. Quase. Lembra da lista citada acima sobre o que um Controller faz? Veremos o que um framework faz sozinho e outros que depende da ajuda manual do programador:
- ouve eventos (framework);
- obtém os parâmetros de entrada desejados da View (framework, obtidos via DI);
- obtém do Model um domínio (manualmente);
- chama um método do domínio (manualmente);
- escolhe a view a ser renderizada, fazendo “bind” de algum domínio do Model (parcialmente pelo framework, a escolha da view pode ser sobreescrita manualmente).

Há tentativas de algumas comunidades para criarem um framework onde o Controller deixa de existir, mas acredito que não funciona em todos os casos e dependem de models fixados a um padrão imposto ao framework.

Frameworks vão além, é claro, pois proveem funcionalidades adicionais como helpers para views e outras coisas.

São essas as perguntas que eu consegui imaginar. E você? Tem alguma dúvida sobre MVC além dessas daqui?

public class MinhaClasse {
 
    private static MinhaClasse instance;
 
    public static MinhaClasse getInstance() {
 
    	if (instance == null) {
    		instance = new MinhaClasse();
    	}
 
        return instance;
    }
 
    // outras coisas
}

Esse é um jeito de fazer cache. Apenas deve-se tomar cuidado para que o objeto a ser retornado não seja mutável. Afinal, todos os interessados estão com a mesma instância, e se um dos clientes puderem mudar uma propriedade desse único objeto, todos terão o efeito indesejável de ter um objeto com comportamento diferente sem saber. Detalhe: a implementação de singleton dessa maneira é ingênua, evite-a.

Um outro jeito, comumente usado, de fazer cache é usar session. Pra quem tem uma aplicação web, parece mágico: joga-se uma entidade da persistência na sessão passando uma chave. Ao precisar do mesmo objeto de novo, ao invés de acessar o banco, pega-se o objeto da sessão com a mesma chave usada na escrita. Esse é a estratégia mais comum que eu já vi por aí. Mas existem vários problemas : já vi aplicações com mais código pra cache em sessão do que pro próprio negócio! Além do mais, sessions são únicas para cada usuário no browser, enquanto que a entidade a ser cacheada é, não raro, visível a vários usuários. Significa duas coisas: 1) Não vai ter uma cacheamento efetivo, se 20 usuários se logarem e todos acessarem a mesma entidade duas vezes, haverá vinte cópias do objeto, que será escrita e lida uma vez cada; 2) Ninguém sabe o que um outro usuário pode fazer, se um alterar a entidade, todos os dezenove usuários restantes não terão como saber disso e manterão cópias desatualizadas. Session não foi feita pra cache, e existe até um problema de design: apesar do mapa de sessão pertencer à camada de apresentação, o cache lida com problemas de objetos que surgem na camada de persistência. Dizer que um pode ser usado para implementação do outro resulta em confusões de conceitos.

Uma solução melhor é usar bibliotecas de cache. No Java, um bastante comum é o EHCache — usado principalmente para o cache de segundo nível de Hibernate — que fica na mesma JVM da sua aplicação. Não que seja ruim (tem até uns javeiros roxos que acham que esta é a melhor solução do mundo), mas quando se quer usar um cluster de aplicações web, por exemplo, passa-se a ter vários caches para cada instância de servidor, que é não o desejável. Uma das opções de cache, que fica fora da JVM de sua aplicação, é o Memcached.

A seguir, apresentarei as vantagens do Memcached, seu mecanismo básico junto com uma API do Java, e no final, o uso integrado com o Hibernate.

Características do Memcached

Memcached permite a chamada escalabilidade horizontal, ou seja, é possível usar várias instâncias de memcached em paralelo como se fosse uma única unidade, onde cada processo possui somente parte dos registros. Parece idiota, mas não é. Não é toda infraestrutura que lhe permite isso; bancos de dados tradicionais, sistemas operacionais e máquinas virtuais possuem uma dificuldade tremenda de configurações para que isso seja possível.

Porém, ser fácil de se escalar horizontalmente trouxe certos custos na sua implementação. Exemplo: Não existe replicação de dados automática, se quiser duas instâncias com dados iguais, terá que fazer seu script. Não existe transação e nem lock, pois isso gera contenção. Não existem busca por todos os registros ou por wildcards, pois pode causar demora nos resultados. E não há garantia de durabilidade de objetos armazenados em casos de crash.

E ainda duas características peculiares, uma é que o tempo de expiração no cache não é zerado com consultas (como é tradicional nas sessions de containeres web), ou seja, se você definir como tempo de expiração dois minutos, esse será o tempo que ficará armazenado, independente se houve consulta do registro nesse meio-tempo ou não. Portanto, sempre coloque no memcached objetos que já estejam persistidos em outro lugar. A segunda característica é que o tempo de expiração é definido por segundos que devem ser armazenados, ou seja, uma hora é 3600. Mas apenas se o tempo de permanência for menor que trinta dias, se for maior, o Memcached assume que é o tempo UNIX absoluto, ou seja, 1240699927 significa que o registro deve permanecer em cache até em 25 de abril de 2009 às 22h52min07 em UTC.

Como usar

Se você estiver usando alguma distribuição Linux, com certeza o Memcached pode ser baixado diretamente de seu repositório. Caso você seja um usuário Windows, existem portes do cache para esse Sistema Operacional aqui e aqui. Como só tenho o Fedora, não testei pra ver se funciona, então o Google será melhor pra resolver problemas de instalação no Windows do que eu.

Além disso, é necessário um cliente Memcached, que existem para várias linguagens. No Java, a melhor biblioteca que encontrei é a Spy Memcached, disponível na versão 2.3.1. Baixe o arquivo e coloque no classpath de sua aplicação.

Incialize o Memcached no seu shell dessa maneira:

memcached -p 18000 -vv

A opção -p indica a porta da conexão TCP por onde será “ouvida” (não é necessário, se não informar será assumido o padrão 11211), e o -vv é a opção verbose.

Na sua aplicação Java, você abre um cliente Memcached dessa maneira:

MemcachedClient mem = new MemcachedClient(new InetSocketAddress("localhost", 18000));

Ou seja, passando um endereço de rede ao construtor do MemcachedClient. Caso você queira um cluster de aplicações Memcached, é possível também passar uma lista de endereços de redes, assim:

MemcachedClient mem = new MemcachedClient(new InetSocketAddress[] {
				new InetSocketAddress("localhost", 18000),
				new InetSocketAddress("localhost", 18001),
			});

Obviamente, é necessário duas instâncias de Memcached disponíveis nesses endereços.

As operações que o Memcached suporta são simples, exemplos:

set

A operação set insere um valor para uma dada chave, independente se esta já possuía um valor anterior ou não:

     String marca = "Ford";
     int expira = (int) (System.currentTimeMillis() + 60 * 60 * 1000) / 1000; // uma hora pra expirar
 
     Future<Boolean> valido = mem.set("marca", expira, marca);

Lembre-se também do comportamento dos trinta dias, as duas formas abaixo setam o mesmo período de expiração:

     Future<Boolean> valido = mem.set("marca", 24 * 60 * 60, marca); // um dia para expirar
     Future<Boolean> valido = mem.set("marca", (int) (System.currentTimeMillis() + 24 * 60 * 60 * 1000) / 1000, marca); // também um dia

É possível setar qualquer coisa, inclusive objetos Java que sejam seriálizáveis. Porém, qualquer coisa diferente de um tipo simples não é identificável para programas em outras linguagens que se conectarem a esse mesmo Memcached.

add

A operação add, apesar do nome, insere um valor para uma dada chave, deste que esta não esteja com um elemento previamente armazenado:

     Pessoa pessoa1 = new Pessoa();
     pessoa1.setId(28L);
     pessoa1.setName("Leonardo");
 
     Future<Boolean> valido1 = mem.add("pessoa", 60 * 60, pessoa1); // valido1 é true
 
     Pessoa pessoa2 = new Pessoa();
     pessoa2.setId(41L);
     pessoa2.setName("Vinicius");
 
     Future<Boolean> valido2 = mem.add("pessoa", 60 * 60, pessoa2); // valido2 é false

replace

A operação replace, ao contrário do add, insere um valor para uma dada chave apenas se esta já estiver anteriormente armazenado:

     int anoLancamento = 2010;
     Future<Boolean> valido1 = mem.replace("anoLancamento", 60 * 60, anoLancamento); // valido1 é false
 
     Future<Boolean> ok = mem.set("anoLancamento", 60 * 60, anoLancamento); // set armazena de qualquer jeito
     ok.get(); // bloqueia até a conclusão
 
     int novoAnoLancamento = 2011;
     Future<Boolean> valido2 = mem.replace("anoLancamento", 60 * 60, novoAnoLancamento); // valido2 é true

get

A operação get busca um registro armazenado anteriormete, dada uma chave:

     String marca = (String) mem.get("marca"); // "Ford", ou null se demorou demais ou expirou

delete

A operação delete apaga um valor no Memcached dada a chave. O valor armazenado não é retornado:

     Future<Boolean> valido1 = mem.delete("anoLancamento"); // true
 
     Future<Boolean> valido2 = mem.delete("anoLancamento"); // false

incr

A operação incr incrementa um valor previamente armazenado. Válido somente para números:

     long valor1 = mem.incr("contador", 9, 5); /* o segundo parâmetro é valor a ser incrementado */
                                               /* o terceiro parâmetro (opcional) é o valor inicial caso não haja nenhum par armazenado */
                                               /* valor1 = 5 */
 
     long valor2 = mem.incr("contador", 7); /* se não informasse o valor inicial e esta fosse a primeira chamada, o retorno seria -1 */
                                            /* valor2 = 12 */

decr

A operação decr decrementa um valor previamente armazenado. Válido somente para números:

     long valor1 = mem.decr("contador", 12, 20); /* valor1 = 20 */
     long valor2 = mem.decr("contador", 9);      /* valor2 = 11 */

Lembre-se: os números são só positivos. Se o valor armazenado é 4 e você decrementar 6, o valor final é 0 (zero).

Exemplo de cache para banco de dados

Vamos a uma situação prática. Imagine um banco de consulta de preços de um supermercado. Alguns preços são consultados com bastante frequência e seus preços são raramente alterados. Idealmente, seria interessante cachear esses valores retornados para aliviar a carga do banco. Meu objeto de domínio é um só:

public class ProductDescription implements Serializable {
 
	private long barCode;
 
	private String description;
 
	private BigDecimal price;
 
	private String type;
 
	// getters e setters omitidos
}

Meu acesso aos dados obedece a essa interface:

package br.com.objectzilla.testeDaoMemcached;
 
public interface ProductDescriptionRepository {
 
	ProductDescription getByBarCode(long barCode);
 
	void refreshProductInformation(ProductDescription product);
}

Ou seja, existe um método para retornar um pedido por código de barras (getByBarCode()) e outro que atualiza ou insere um produto (refreshProductInformation()).Também tenho uma classe, implementando essa interface, que executa comandos SQL no banco via JDBC (ProductDescriptionDAO, não mostrado).

O pulo do gato é uma classe, que fica como um Decorator, que realiza o cache, veja:

package br.com.objectzilla.testeDaoMemcached;
 
import net.spy.memcached.MemcachedClient;
 
public class ProductDescriptionCacheDecorator implements ProductDescriptionRepository {
 
	private MemcachedClient memcachedClient;
	private int expiration;
	private ProductDescriptionRepository other;
 
	public ProductDescription getByBarCode(long barCode) {
 
		ProductDescription product = (ProductDescription) memcachedClient.get("product_descr/" + barCode);
		if (product == null) {
			product = other.getByBarCode(barCode);
 
			memcachedClient.add("product_descr/" + barCode, expiration, product);
		}
		return product;
	}
 
	public void refreshProductInformation(ProductDescription product) {
		other.refreshProductInformation(product);
 
		memcachedClient.delete("product_descr/" + product.getBarCode());
	}
 
	public void setMemcachedClient(MemcachedClient memcachedClient) {
		this.memcachedClient = memcachedClient;
	}
 
	public void setExpiration(int expiration) {
		this.expiration = expiration;
	}
 
	public void setOther(ProductDescriptionRepository other) {
		this.other = other;
	}
}

Primeiro, a variável other refere-se a uma outra classe que implementa também ProductDescriptionRepository, como a classe acima é um decorator, natural que essa referência seja de um objeto que realmente faz acesso ao banco. Tem-se também a instância de um MemcachedClient e a instância de um período de expiração, para ser usado para a manipulação de dados do Memcached.

Veja, primeiro, o método getByBarCode, a primeira coisa que se faz é buscar um registro no memcached usando uma chave formada do nome abreviado do objeto seguido do código de barras do produto (o id). Havendo esse registro, retorna-o, e aí a consulta ao banco não é realizada e fim de papo. Se esse registro não estiver no Memcached, aí este é buscado no banco (através de other) e, em sequência, realizada a inserção do objeto no cache, para que as próximas chamadas desse método não façam busca no banco de novo. Lembre-se que o cache expira, e não é apropriado assumir que o objeto está sempre no cache, portanto é sempre necessário ter essa verificação de registro vazio em todas as suas consultas.

Ao inserir ou alterar um registro, o dado no cache fica desatualizado. Por isso, existe uma chamada para remover o ítem após a inserção bem sucedida no método refreshProductInformation(). Poderia haver uma inserção no memcache nesse ponto, mas preferi não fazer, porque de qualquer forma, isso será feito no método de busca.

A aplicação que exercita esse cache está disponível nesse zip, caso queiram estudá-lo com mais detalhes.

Usando como cache de segundo nível do Hibernate

O Hibernate possui suporte a cache de segundo nível, e a implementação mais comum é o EHCache, que vem junto com o framework de persistência. Por ter um cache quase automático (pois você precisa habilitá-lo para cada entidade mapeada), é meio desvantajoso fazer cacheamento manualmente como fiz anteriormente. Incrivelmente, na minha busca por Memcached no Google, me deparei com o plugin hibernate-memcached que usa o Memcached como cache de segundo nível.

Se a opção for essa, as coisas facilitam bastante. Primeiro, anotaremos a entidade ProductDescription, assim:

@Entity
@Table(name="product_description")
@Cache(usage=CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public class ProductDescription implements Serializable {
 
	@Id
	@Column(name="bar_code")
	private long barCode;
 
	private String description;
 
	private BigDecimal price;
 
	private String type;
 
	// getters e setters
}

Existem as anotações triviais do JPA, como @Entity, @Table, @Id e @Column. Mas existe também a anotação específica do Hibernate, que é o @Cache. Na estratégia de concorrência, estou dizendo que é possível haver escrita e leitura, mas que a escrita não bloqueia leituras. Sem esta anotação, o cache não funciona pra essa entidade. (Por isso, se você um dia colocou o cache de segundo nível que você queria nas configurações, mas nunca colocou a anotação @Cache nas entidades, é a mesma coisa que não ter cache de segundo nível.)

O Dao faz acessos ao Hibernate normalmente (estou usando o template do Spring):

package br.com.objectzilla.hibernateMemcached;
 
import org.hibernate.SessionFactory;
import org.springframework.orm.hibernate3.HibernateTemplate;
import org.springframework.transaction.annotation.Transactional;
 
@Transactional
public class ProductDescriptionDAO implements ProductDescriptionRepository {
 
	private HibernateTemplate hibernateTemplate;
 
	public ProductDescription getByBarCode(long barCode) {
		return (ProductDescription) hibernateTemplate.get(ProductDescription.class, barCode);
	}
 
	public void refreshProductInformation(ProductDescription product) {
		product = (ProductDescription) hibernateTemplate.merge(product);
		hibernateTemplate.saveOrUpdate(product);
	}
 
	public void setSessionFactory(SessionFactory sessionFactory) {
		hibernateTemplate = new HibernateTemplate(sessionFactory);
	}
}

E pra configurar, basta adicionar essas propriedades no hibernate.cfg.xml:

<property name="hibernate.cache.provider_class">com.googlecode.hibernate.memcached.MemcachedCacheProvider</property>
<property name="hibernate.cache.use_query_cache">true</property>
<property name="hibernate.memcached.servers">localhost:14001</property>

Onde eu indico o provedor do cache, a opção de se fazer cache de queries, e o servidor do Memcached. Não são as únicas opções, mas as outras possuem opção default, que você encontra aqui.

É só isso, agora é só adiconar o hibernate-memcached e o spy-memcached no seu classpath e rodar a aplicação. Também disponibilizei um zip para esse exemplo, caso vocês queiram dar uma olhada.

Conclusão

Usar cache, seja o Memcached ou qualquer outro, é uma boa opção para evitar acesso a recursos custosos, como o banco de dados. Mas, numa aplicação dividida em camadas não é sempre necessário que a responsabilidade de cachear fique no lado cliente (camada de apresentação). Se deixar que o lado servidor (camada de persistência) tenha essa responsabilidade, você pode deixar que os clientes acessem a camada de persistência na hora e do jeito que bem entenderem e, ainda assim, de maneira transparente, estará sendo feito acesso eficiente de recursos.

Eu havia feito uma medição bem informal de quanto o Memcached economizaria o tempo de busca. Levei à conclusão de que por causa de warm-up e tudo mais, eu não sei fazer benchmarks. O mais importante do cache não costuma nem ser o tempo de acesso mais rápido, mas o fato de não deixar “engargalar” o banco com muitos acessos.

Como faríamos isso? Bom, primeiro haveria a classe Consulta, que só existirá a partir do relacionamento entre Paciente e Medico.

Mas antes vou subdividir as minhas classes atuais em pacotes, assim:

.
|-- aplicacao
|   |-- AgendaFormServlet.java
|   |-- Agendamento.java
|   |-- AgendamentoServlet.java
|   `-- ConsultaServlet.java
|-- dominio
|   |-- AgendamentoImpl.java
|   |-- Medico.java
|   |-- MedicoNaoEncontradoException.java
|   |-- MedicoRepositorio.java
|   |-- Paciente.java
|   |-- PacienteNaoEncontradoException.java
|   `-- PacienteRepositorio.java
`-- persistencia
    |-- MedicoDAO.java
    `-- PacienteDAO.java

Se desse jeito é uma boa idéia ou não, eu não sei. Mas sei que a famosa subdivisão por patterns que se encontra por aí não tem o menor sentido. Pacotes deveriam ser divididos sobre a regra: “alta coesão e baixo acoplamento”, assim como é com classes, arquivos e métodos. A subdivisão por patterns parece ser o contrário disso: tem baixa coesão porque um determinado domínio está espalhado entre os pacotes to, dto, entity, sessionbean etc.; e tem alto acoplamento porque sob o mesmo pacote está uma classe sobre Veiculo e outra sobre Arvore. Tudo bem que é importante a subdivisão por camadas, mas não vai achar que os TOs estão em uma camada própria!

Dando prosseguimento, vamos criar uma nova classe de teste para a criação da classe Consulta. Sabemos que essa classe não existe sem Paciente e Medico, portanto iremos colocar essas classes no construtor. Não só isso, Consulta não existe sem um horário inicial e a duração dela, e portanto também estará no construtor.

Mas vamos definir uma regra clara: só é possível marcar consulta em horário disponível. Nesse primeiro teste, como não foi setado um horário, então deve dar erro sempre que marcar uma consulta.

@Test
public void consultaNaoDisponivel() {
 
	Paciente p = new Paciente();
	p.setNome("Leonardo");
 
	Medico m = new Medico();
	m.setNome("Dr. Meredith Grey");
 
	// não informo o período de consulta 
 
	Calendar c = Calendar.getInstance();
	c.set(2009, Calendar.MARCH, 01, 15, 00, 00);
 
	try {
		new Consulta(p, m, c.getTime(), 60);
 
		Assert.fail("Esperava-se o lançamento de exceçao");
	} catch (ConsultaNaoDisponivel e) {
 
	}
	Assert.fail();
}

Gere o construtor e a classe de exceção (eu herdei de IllegalStateException) para o compilador não reclamar. Após rodar o teste, vai acusar um erro. Faça o teste rodar adicionando a seguinte instrução no construtor:

public Consulta(Paciente paciente, Medico medico, Date inicio, int duracaoMinutos) {
		throw new ConsultaNaoDisponivel();
	}

Não é o que se espera, mas faz, por enquanto, o teste rodar.

Agora, qual seria um caso onde realmente a consulta aconteceria com sucesso? Seria quando o consulta estivesse dentro de um horário disponível pelo médico. Minha idéia é que médico teria seus horários disponíves (classe HorarioDisponivel) com dia da semana, horário inicial e horário final. A consulta só ocorreria quando a consulta batesse com pelo menos um desses intervalos.

@Test
	public void consultaDisponivel() {
 
		Paciente p = new Paciente();
		p.setNome("Leonardo");
 
		Medico m = new Medico();
		m.setNome("Dr. Meredith Grey");
 
		m.adicioneDisponibilidade(new HorarioDisponivel(DiaSemana.SEGUNDA, 13, 00, 19, 00));
 
		// não informo o período de consulta 
 
		Calendar c = Calendar.getInstance();
		c.set(2009, Calendar.MARCH, 02, 15, 00, 00);
 
 
		Consulta consulta = new Consulta(p, m, c.getTime(), 60);
		SimpleDateFormat sdf = new SimpleDateFormat("ddMMyyyyhhmmss");
 
		Assert.assertEquals(p, consulta.getPaciente());
		Assert.assertEquals(m, consulta.getMedico());
		Assert.assertEquals("02032009150000", sdf.format(consulta.getInicio()));
		Assert.assertEquals("02032009160000", sdf.format(consulta.getFim()));
	}

Depois de acertar os problemas de compilação, rode o teste. O construtor de consulta irá lançar exceção, falhando o teste. Claro, agora é hora de acertarmos este construtor para que não lance a exceção nesse segundo caso de teste.

A nova classe de consulta ficou assim:

public class Consulta implements Serializable {
 
	public Consulta(Paciente paciente, Medico medico, Date inicio, int duracaoMinutos) {
		Set<HorarioDisponivel> disponibilidades = medico.getDisponibilidades();
 
		Calendar inicioConsulta = Calendar.getInstance();
		inicioConsulta.setTime(inicio);
 
		Calendar finalConsulta = Calendar.getInstance();
		finalConsulta.setTime(inicio);
		finalConsulta.add(Calendar.MINUTE, duracaoMinutos);
 
		boolean disponivel = false;
 
		for (HorarioDisponivel disponibilidade : disponibilidades) {
 
			if (inicioConsulta.get(Calendar.DAY_OF_WEEK) == disponibilidade.diaSemana.ordinal() + 1) {
				Calendar limiteInicial = Calendar.getInstance();
				// o dia seria igual à data marcada, apenas para não complicar
				limiteInicial.setTime(inicio);
 
				limiteInicial.set(Calendar.HOUR_OF_DAY, disponibilidade.horaInicial);
				limiteInicial.set(Calendar.MINUTE, disponibilidade.minutoInicial);
				limiteInicial.set(Calendar.SECOND, 0);
 
				Calendar limiteFinal = Calendar.getInstance();
				// o dia seria igual à data marcada, apenas para não complicar
				limiteFinal.setTime(inicio);
				// se hora final é menor que hora inicial, assumimos que a hora
				// final refere-se ao dia seguinte. Exemplo: inicial: 22 e
				// final: 04 significa um período que começa às 10 da noite de
				// um dia e vai até às 4 da manhã do dia seguinte
				if (disponibilidade.horaFinal < disponibilidade.horaInicial) {
					limiteFinal.add(Calendar.DAY_OF_MONTH, 1);
				}
 
				limiteFinal.set(Calendar.HOUR_OF_DAY, disponibilidade.horaFinal);
				limiteFinal.set(Calendar.MINUTE, disponibilidade.minutoFinal);
				limiteFinal.set(Calendar.SECOND, 0);
 
				// verifica se a data está no intervalo
				if (inicioConsulta.compareTo(limiteInicial) >= 0 && finalConsulta.compareTo(limiteFinal) <= 0) {
					disponivel = true;
					break;
				}
			}
		}
 
		if (disponivel) {
			this.paciente = paciente;
			this.medico = medico;
			this.inicio = inicioConsulta.getTime();
			this.fim = finalConsulta.getTime();
		} else {
			throw new ConsultaNaoDisponivel();
		}
	}
 
  // getters omitidos
 
	private Paciente paciente;
	private Medico medico;
	private Date inicio;
	private Date fim;
 
}

E ainda precisei alterar a classe do médico para adicionar os seguintes métodos e atributos:

public class Medico implements Serializable {
 
  // ...	
	public void adicioneDisponibilidade(HorarioDisponivel horarioDisponivel) {
		disponibilidades.add(horarioDisponivel);	
	}
 
	public Set<HorarioDisponivel> getDisponibilidades() {
		return Collections.unmodifiableSet(disponibilidades);
	}
 
  //...	
	private Set<HorarioDisponivel> disponibilidades = new HashSet<HorarioDisponivel>();
}

Com isso, a classe HorarioDisponivel ficou assim:

public class HorarioDisponivel {
	public enum DiaSemana {DOMINGO, SEGUNDA, TERCA, QUARTA, QUINTA, SEXTA, SABADO}
 
	public HorarioDisponivel(DiaSemana diaSemana, int horaInicial, int minutoInicial,
			int horaFinal, int minutoFinal) {
		this.diaSemana = diaSemana;
		this.horaInicial = horaInicial;
		this.minutoInicial = minutoInicial;
		this.horaFinal = horaFinal;
		this.minutoFinal = minutoFinal;
	}
 
	DiaSemana diaSemana;
	int horaInicial;
	int minutoInicial;
	int horaFinal;
	int minutoFinal;
}

Hora de refatorar, três problemas à vista: um é o fato do construtor da Consulta estar acessando demais as propriedades de HorarioDisponivel, indício que boa parte dessa lógica poderia estar nessa classe; outro é o fato do médico ter duas formas de realizar consulta, a antiga através dos métodos consulta(Calendar) e consulta(Paciente, Calendar) e a nova que foi feita agora, ou seja, o antigo precisa ser removido; por último é o fato da aplicação ainda salvar o objeto Médico na hora de criar uma consulta.

Ao primeiro problema, criei um método isDentroHorario() dentro de HorarioDisponivel, contendo o “miolo” do laço for. Assim, o construtor de Consulta foi reduzido a:

Set<HorarioDisponivel> disponibilidades = medico.getDisponibilidades();
 
		Calendar inicioConsulta = Calendar.getInstance();
		inicioConsulta.setTime(inicio);
 
		Calendar finalConsulta = Calendar.getInstance();
		finalConsulta.setTime(inicio);
		finalConsulta.add(Calendar.MINUTE, duracaoMinutos);
 
		boolean disponivel = false;
 
		for (HorarioDisponivel disponibilidade : disponibilidades) {
 
			if (disponibilidade.isDentroHorario(inicioConsulta, finalConsulta)) {
				disponivel = true;
				break;
			}
		}
 
		if (disponivel) {
			this.paciente = paciente;
			this.medico = medico;
			this.inicio = inicioConsulta.getTime();
			this.fim = finalConsulta.getTime();
		} else {
			throw new ConsultaNaoDisponivel();
		}

O teste rodou com sucesso.

Ao segundo problema, retirei os dois métodos consulta() e adicionei o novo método marcaConsulta(), assim:

public void marcaConsulta(Paciente paciente, Date horario) {
		Consulta novaConsulta = new Consulta(paciente, this, horario, 60);
		if (getConsultas() == null) {
			setConsultas(new HashSet<Consulta>());
		}
		getConsultas().add(novaConsulta);
	}

É claro que isso teve impacto em alguns casos de testes. Mas o código final não será mostrado aqui.

Ao terceiro problema, movi o método

public interface MedicoRepositorio {
	// ...
	void salvaConsultaMedico(Medico medico);
}

para a nova classe ConsultaRepositorio, agora com novo nome:

public interface ConsultaRepositorio {
 
	void marca(Consulta consulta);
}

Resolvi problemas de compilação. O método marcaConsulta de AgendamentoImpl ficou assim (não mostrei, mas foi adicionado mais um bean do EJB):

	public void marcaConsulta(long medicoId, long pacienteId, Date horario)
			throws PacienteNaoEncontradoException, MedicoNaoEncontradoException {
 
		Paciente paciente = pacienteRepositorio.getPaciente(pacienteId);
		Medico medico = medicoRepositorio.getMedico(medicoId);
 
		consultaRepositorio.marca(new Consulta(paciente, medico, horario, 60));
	}

Resolvi outros problemas de compilação também; e criei também um “DAO”, à semelhança dos outros, que também é um Singleton:

@Singleton
public class ConsultaDAO implements ConsultaRepositorio {
 
	private List<Consulta> consultas = new ArrayList<Consulta>();
 
	@Override
	public void marca(Consulta consulta) {
		consultas.add(consulta);
 
	}
}

Descobri também que ninguém chama o método marcaConsulta() de Medico. Vou apagá-lo. Vou rodar o teste e… opa! Deu erro! No método pacienteMarcaHoraComMedico(), é feita a verificação de consulta através da propriedade “lista de consultas” de médico. Porém, por não estar persistido de verdade, essa relação acaba não existindo.

try {
			agendamento.marcaConsulta(medicoId, pacienteId, horario.getTime());
 
			// verifica se os métodos definidos no mock foram realmente chamados
			context.assertIsSatisfied();
 
			// agora, médico tem consulta com paciente marcada às 5
			Assert.assertEquals(1, medicoRetornado.getConsultas().size());
			Consulta consulta = medicoRetornado.getConsultas().iterator().next(); // <-- ocorre erro aqui
			Assert.assertEquals(pacienteRetornado.getNome(), consulta.getPaciente().getNome());
 
		} catch (PacienteNaoEncontradoException e) {
			Assert.fail();
		} catch (MedicoNaoEncontradoException e) {
			Assert.fail();
		}

Vamos mudar um pouco e retornar o registro obtido através do DAO de Consulta. Assim: lá em cima, eu criei uma classe falsa (tá, o nome correto é classe interna anônima) de ConsultaRepositorio:

final List<Consulta> consultaRetornada = new LinkedList<Consulta>();
 
		// ajustando o repositório de médico
		final MedicoRepositorio medicoRep = context.mock(MedicoRepositorio.class);
		final ConsultaRepositorio consultaRep = new ConsultaRepositorio() {
			@Override
			public void marca(Consulta consulta) {
				consultaRetornada.add(consulta);
			}
		};

e o código com problemas fica assim:

try {
			agendamento.marcaConsulta(medicoId, pacienteId, horario.getTime());
 
			// verifica se os métodos definidos no mock foram realmente chamados
			context.assertIsSatisfied();
 
			// agora, médico tem consulta com paciente marcada às 5
			Consulta consulta = consultaRetornada.get(0);
			Assert.assertEquals(pacienteRetornado.getNome(), consulta.getPaciente().getNome());
 
		} catch (PacienteNaoEncontradoException e) {
			Assert.fail();
		} catch (MedicoNaoEncontradoException e) {
			Assert.fail();
		}

Sucesso.

Ufa! Vamos continuar com o problema do agendamento. O que acontece quando são marcadas duas consultas ao mesmo tempo? Deveria dar erro, certo? Mas, se rodarmos esse novo teste:

Vai dar erro. Pois o sistema atual não restringe duas consultas.
Para resolver isso, precisamos que, ao marcar uma nova consulta, verifica-se primeiro a existência de um registro no mesmo horário antes de começar. Porém, não acho prudente fazer isso no construtor da entidade, delegarei isso para o repositório.

public interface ConsultaRepositorio {
 
	void marca(Consulta consulta);
 
	boolean existeConsultaPara(Medico medico, Date horario, int duracaoMinutos);
}

Mas também, não dá pra contar que esse método sempre será chamado ao criar uma consulta. Imaginei uma factory de objetos que retornaria a Consulta e que também chamaria esse método do DAO antes de devolver o objeto. Qualquer um faria esse objeto como Singleton ou algo parecido, farei ele como um Session Bean, mas (pra ficar diferente) farei sem interface, coisa que agora será possível, assim:

package br.com.objectzilla.agendamedica.dominio;
 
import java.util.Date;
 
import javax.ejb.EJB;
import javax.ejb.Stateless;
 
@Stateless
public class ConsultaFactory {
 
	public Consulta novaConsulta(Paciente paciente, Medico medico, Date inicio, int duracaoMinutos) {
		boolean agendado = consultaRepositorio.existeConsultaPara(medico, inicio, duracaoMinutos);
		if (agendado) {
			throw new ConsultaNaoDisponivel();
		}
 
		return new Consulta(paciente, medico, inicio, duracaoMinutos);
	}
 
	@EJB
	public void setConsultaRepositorio(ConsultaRepositorio consultaRepositorio) {
		this.consultaRepositorio = consultaRepositorio;
	}
 
	private ConsultaRepositorio consultaRepositorio;
}

Legal, mas o teste se complica, já que a decisão por existir ou não a consulta cabe à camada de dados, e acabou ficando assim:

	@Test
	public void duasConsultasAoMesmoTempo() {
		medico.adicioneDisponibilidade(HorarioDisponivel.getInstance(DiaSemana.SEGUNDA, 8, 00, 17, 00));
 
		ConsultaFactory consultaFactory = new ConsultaFactory();
		Mockery context = new JUnit4Mockery();
 
		final ConsultaRepositorio consultaRep =  context.mock(ConsultaRepositorio.class);
		context.checking(new Expectations() {{
			one(consultaRep).existeConsultaPara(medico, horarioConsulta, 60); will(returnValue(false));
			one(consultaRep).existeConsultaPara(medico, horarioConsulta, 60); will(returnValue(true));
 
		}});
		consultaFactory.setConsultaRepositorio(consultaRep);
 
		// a primeira consulta está ok
		Consulta consulta = consultaFactory.novaConsulta(paciente, medico, horarioConsulta, 60);
		SimpleDateFormat sdf = new SimpleDateFormat("ddMMyyyyHHmmss");
 
		Assert.assertEquals(paciente, consulta.getPaciente());
		Assert.assertEquals(medico, consulta.getMedico());
		Assert.assertEquals("02032009150000", sdf.format(consulta.getInicio()));
		Assert.assertEquals("02032009160000", sdf.format(consulta.getFim()));
 
		// a segunda consulta é no mesmo horário
		Paciente paciente2 = new Paciente();
		paciente2.setNome("Maria");
		try {
 
			consultaFactory.novaConsulta(paciente2, medico, horarioConsulta, 60);
 
			Assert.fail("Realizada segunda consulta por engano");
		} catch (ConsultaNaoDisponivel e) {
 
		}
	}

Sempre fico com uma pulga na orelha quando uso mocks para testes. Afinal, estou testando o meu código (como se espera) ou o mock?  Bom, não consigo pensar em algo melhor. Vou deixar assim, que está rodando com sucesso.
Dessa vez, irei usar o JavaServer Faces 2.0 como camada visual, e vou ignorar aqueles Servlets que estavam antes.
Não irei mostrar todas as páginas, mas gostaria de mostrar como é para fazer um managed bean. É assim agora:

@ManagedBean(name="consulta")
@SessionScoped
public class ConsultaManagedBean {
  // ...
}

Nada de XML, você define o seu managed bean através de anotação. E o escopo é definido através de anotações @SessionScoped, @ViewScoped (um novo escopo que dura enquanto existir a página), @RequestScoped e @ApplicationScoped.
Uma outra coisa é que não é necessário declarar o destino da página em faces-config.xml todas as vezes. Por exemplo, se você definir um retorno com uma String, assim:

public String novo() {
		// preenche combo de médicos
		List<Medico> listaMedico = medicoRepositorio.todosMedicos();
 
		medicosItens = new LinkedHashMap<String, Long>();
		for (Medico m : listaMedico) {
			medicosItens.put(m.getNome(), m.getId());
 
		}
 
		// preenche combo de pacientes
		List<Paciente> listaPaciente = pacienteRepositorio.todosPacientes();
 
		pacientesItens = new LinkedHashMap<String, Long>();
		for (Paciente p : listaPaciente) {
			pacientesItens.put(p.getNome(), p.getId());
		}
 
		return "formNovaConsulta";
	}

E não definir essa String na navegações, será exibido a página cujo nome é essa String. Nesse caso acima, será exibido à página “formNovaConsulta.xhtml”.
Bom, é isso. Eu sei que demorei demaaais para mostrar essa nova parte. Mas ficou muito complicado, e percebi que fugi muito o tópico. Nas próximas séries sobre Java EE 6, não utilizarei esse exemplo, focando apenas nas novas features. Até.
]]>
			http://www.objectzilla.com.br/2009/03/22/aprenda-java-ee-6-agora-3/feed/
		1
		
		
		
		http://www.objectzilla.com.br/2009/02/24/aprenda-java-ee-6-agora-2/
		http://www.objectzilla.com.br/2009/02/24/aprenda-java-ee-6-agora-2/#comments
		Tue, 24 Feb 2009 20:49:34 +0000
		Leonardo
				
		

		http://www.objectzilla.com.br/?p=182
		
			Dessa vez, estarei utilizando a versão b37 do Glassfish v3. Por causa disso, você vai ter que fazer alterações à mão no plugin do Eclipse para o servidor Glassfish. Na versão b36 havia as pastas web e ejb dentro de module. Agora, todos os jars estão dentro de module, sem distinção de pastas.

Primeiro, feche o Eclipse. Iremos copiar o plugin do Glassfish e descompactá-lo, para alterar o seu arquivo de configurações. No Linux eu fiz assim, supondo que ECLIPSE_HOME seja uma variável onde aponta para a pasta do Eclipse:

$ mkdir -p ~/plugin # cria pasta plugin dentro de seuhome
 
$ cd $ECLIPSE_HOME/plugins #entra na pasta plugins dentro de eclipse
 
$ cp com.sun.enterprise.jst.server.sunappsrv_1.0.16.jar ~/plugin/ # copia o plugin do Glassfish para sua pasta
 
$ cd ~/plugin/ # vá para a sua pasta...
 
$ unzip com.sun.enterprise.jst.server.sunappsrv_1.0.16.jar -d plugin_glassfish # e extrai o conteúdo do jar dentro da subpasta plugin_glassfish
 
$ cd plugin_glassfish/serverdef/ #entre na pasta serverdef (do conteúdo recém extraído)
 
$ vim glassfishv3preludeserverdef.xml # edite este arquivo (não precisa ser, necessariamente, o vim)

Você vai encontrar isso na linha 184:

<archive path="${sunappserver.rootdirectory}/modules/web/jsf-impl.jar" />
<archive path="${sunappserver.rootdirectory}/modules/web/jstl-impl.jar" />

Troque para:

<archive path="${sunappserver.rootdirectory}/modules/jsf-impl.jar" />
<archive path="${sunappserver.rootdirectory}/modules/jstl-impl.jar" />

Agora vamos reempacotar o jar e devolvê-lo pro Eclipse:

$ cd ~/plugin # volta onde está a cópia do plugin do Eclipse
 
$ mv com.sun.enterprise.jst.server.sunappsrv_1.0.16.jar com.sun.enterprise.jst.server.sunappsrv_1.0.16.jar__old # mude o nome
 
$ cd plugin_glassfish/ # entre na pasta com conteúdo "dezipado"
 
$ zip -r ../com.sun.enterprise.jst.server.sunappsrv_1.0.16.jar ./ # e faça o zip de novo com o mesmo nome do jar
 
$ cd .. # volte um nível
 
$ cp com.sun.enterprise.jst.server.sunappsrv_1.0.16.jar $ECLIPSE_HOME/plugins/ # e copie o novo jar para a pasta de plugins do Eclipse

Ao abrir o Eclipse de novo, na versão b37, o projeto não sentirá mais falta de bibliotecas. Voltando…
No post anterior, fizemos uma aplicação já utilizando os recursos do EJB Lite. Porém, faltava alguma coisa para persistir os objetos.
No teste, instanciava-se ali mesmo os objetos necessários e jogava-os no método marcaConsulta(). Porém, num caso real, os objetos precisariam existir muito antes, armazenados num meio persistente (na maioria das vezes, em um banco de dados relacional). A prática corrente é encapsular essa obtenção de objetos do meio persistente através do DAO (Data Access Object, ou objeto de acesso aos dados). Nessa aplicação, seguiremos a prática de separar a interface da implementação, e chamarei a interface de .*Repository e a classe que a implementa de .*DAO. Usarei EJB Lite também para a implementação de persistência.
Aquele primeiro teste será modificado para buscar os objetos do repositório. Estaremos utilizando o JMock para simular o DAO, pois, além de não termos uma fonte de dados real (por enquanto), testes que dependem de recursos externos perdem a confiabilidade. Melhor fazer um stub e ter certeza que traz o resultado esperado

package br.com.objectzilla.agendamedica;
 
import java.util.Calendar;
 
import org.jmock.Expectations;
import org.jmock.Mockery;
import org.jmock.integration.junit4.JUnit4Mockery;
import org.junit.Assert;
import org.junit.Test;
 
public class AgendamentoTeste {
 
	@Test
	public void pacienteMarcaHoraComMedico() {
 
		Mockery context = new JUnit4Mockery();
 
		// ajustando o repositório de paciente
		final PacienteRepositorio pacienteRep =  context.mock(PacienteRepositorio.class);
 
		context.checking(new Expectations() {{
			Paciente paciente = new Paciente();
			paciente.setNome("Maria");
 
			oneOf (pacienteRep).getPaciente(32L); will(returnValue(paciente));
		}});
 
		// ajustando o repositório de médico
		final MedicoRepositorio medicoRep = context.mock(MedicoRepositorio.class);
 
		context.checking(new Expectations() {{
			Medico medico = new Medico();
			medico.setNome("Dr. Gregory House");
 
			oneOf (medicoRep).getMedico(4L); will(returnValue(medico));
		}});
 
		// um paciente...
		Paciente paciente = pacienteRep.getPaciente(32L);
 
		// um médico...
		Medico medico = medicoRep.getMedico(4L);
 
		// ambos agendam um horário
		Agendamento agendamento = new AgendamentoImpl();
		Calendar horario = Calendar.getInstance();
		horario.set(2009, Calendar.MARCH, 5, 17, 00, 00);
 
		agendamento.marcaConsulta(medico, paciente, horario);
 
		// agora, médico tem consulta com paciente marcada às 5
		Paciente pacienteMarcado = medico.consulta(horario);
		Assert.assertEquals(paciente.getNome(), pacienteMarcado.getNome());
	}
}

Tanto MedicoRepositorio quanto PacienteRepositorio são interfaces (mais tarde, criarei as implementações). Ao criá-las, o teste já é executado com sucesso.
Agora chegou a hora de refatorar. Repare que o teste, do jeito que está, é imbecil. Os mocks apenas complicaram a obtenção de objetos e, se deixasse como antes, seria a mesma coisa! Mas eu fiz essa alteração para um próximo passo: os repositórios não serão mais chamados pelo meu teste, mas pelo método marcaConsulta(), que receberia apenas os ids de médico e paciente. E como consequência, os mocks servirão para indicar que os métodos dos repositórios realmente são chamados. Veja como fica:

		// ajustando o repositório de paciente (omitido, pois é como era antes)
		// ajustando o repositório de médico (omitido, pois é como era antes)
 
		// id de paciente e médico
		long pacienteId = 32L;
		long medicoId = 4L;
 
		// cria um agendamento, passando os repositórios como parâmetro
		Agendamento agendamento;
		{
			AgendamentoImpl impl = new AgendamentoImpl();
			impl.setPacienteRepositorio(pacienteRep);
			impl.setMedicoRepositorio(medicoRep);
			agendamento = impl;
		}
 
		// cria um horário para a consulta
		Calendar horario = Calendar.getInstance();
		horario.set(2009, Calendar.MARCH, 5, 17, 00, 00);
 
		agendamento.marcaConsulta(medicoId, pacienteId, horario);
 
		// verifica se os métodos definidos no mock foram realmente chamados
		context.assertIsSatisfied();
 
		// agora, médico tem consulta com paciente marcada às 5
		Paciente pacienteMarcado = medicoRetornado.consulta(horario);
		Assert.assertEquals(pacienteRetornado.getNome(), pacienteMarcado.getNome());

Tente executar até que fique com sucesso. Se quiser, dentro do método marcaConsulta(), ao invés de pegar os objetos dentro dos repositórios, crie novos objetos Medico e Paciente. Vai dar erro, porque foi adicionado no teste a instrução context.assertIsSatisfied(), que garante que os métodos definidos no mock sejam realmente chamados por apenas uma vez (e dê erro caso contrário).
Existe ainda mais uma oportunidade de teste: o que acontece quando eu uso um identificador para um objeto que não existe? Deveria lançar exceção, mas, atualmente, a assinatura do método dos repositórios não possui qualquer sinalização disso. Farei também um teste para o caso de não achar objetos. Mas nesse caso, não mostrarei aqui, estando apenas no meu GitHub.
Chegou a hora da verdade, como fazer os façades existentes se tornarem Session Beans? Simples, com anotações! Primeiro, as interfaces de repositório:

@Local
public interface MedicoRepositorio {
 
	Medico getMedico(long id) throws MedicoNaoEncontradoException;
}


@Local
public interface PacienteRepositorio {
 
	Paciente getPaciente(long id) throws PacienteNaoEncontradoException;
}

A implementação do Session Bean Agendamento possui agora as dependências com os repositórios:

@Stateless
public class AgendamentoImpl implements Agendamento {
 
	@Override
	public void marcaConsulta(long medicoId, long pacienteId, Calendar horario)
			throws PacienteNaoEncontradoException, MedicoNaoEncontradoException {
		Paciente paciente = pacienteRepositorio.getPaciente(pacienteId);
		Medico medico = medicoRepositorio.getMedico(medicoId);
 
		medico.consulta(paciente, horario);
 
		medicoRepositorio.salvaConsultaMedico(medico);
	}
 
	@EJB
	public void setPacienteRepositorio(PacienteRepositorio pacienteRep) {
		pacienteRepositorio = pacienteRep;
 
	}
 
	@EJB
	public void setMedicoRepositorio(MedicoRepositorio medicoRep) {
		medicoRepositorio = medicoRep;
	}
 
	private PacienteRepositorio pacienteRepositorio;
	private MedicoRepositorio medicoRepositorio;
}

Na implementação dos repositórios, ainda não colocarei a persistência com o banco de dados. Ao invés disso, deixarei os objetos em memória. Numa situação como essa, esse lugar da memória deveria ser o único em toda a aplicação, ou seja, singleton. Até agora, singletons deveriam ser feitos à mão; na próxima versão, será possível usar EJB, bastando uma anotação, veja:

@Singleton
public class MedicoDAO implements MedicoRepositorio {
  //...
}

Isso é ainda uma demonstração, quando eu usar um banco de dados de verdade, voltarei a usar @Stateless. De fato, não é porque existe @Singleton que você sempre deve usá-lo porque, com essa anotação, as chamadas aos métodos serão serializadas (não ocorre execução em paralelo), reduzindo sensivelmente a escalabilidade. Portanto, use como último recurso. O código completo do DAO, você vê no meu GitHub.
Acabou? Nããããããooo! Vamos imaginar como seria uma tela de agendamento:

- Mostra-se uma lista de médicos, uma lista de pacientes e pede-se um horário de consulta.

- O usuário marca a consulta.

- Mostra-se a consulta marcada.
Três coisas que falta nos DAOs, uma busca por lista de médicos, outra para lista de pacientes, e um método que salva a consulta. Farei os três métodos:

@Local
public interface PacienteRepositorio {
 
	Paciente getPaciente(long id) throws PacienteNaoEncontradoException;
 
	List<Paciente> todosPacientes();
}


@Local
public interface MedicoRepositorio {
 
	Medico getMedico(long id) throws MedicoNaoEncontradoException;
 
	List<Medico> todosMedicos();
 
	void salvaConsultaMedico(Medico medico);
}

No teste, adicionarei também a exigência do método de marcarConsulta() salvar a consulta do médico. Mas, pra variar, não vou mostrar. (Se você estiver atento, faltou o conceito de Consulta, que está escondido como um atributo do médico. Numa próxima oportunidade, antes de adicionar qualquer outra funcionalidade, criarei esse tipo.)
Vamos às páginas web! Usarei Servlets e JSPs. A primeira página pega todos os pacientes e todos os médicos e exibe uma tela para digitar o horário da consulta. Seguindo o MVC, temos o Servlet agindo como Controller:

@WebServlet(value="/agendaForm")
public class AgendaFormServlet extends HttpServlet {
 
	private static final long serialVersionUID = -7874706688461756994L;
 
	@Override
	public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException,
			IOException {
 
		// obtém médicos
		List<Medico> medicos = medicoRepositorio.todosMedicos();
		req.setAttribute("medicos", medicos);
 
		// obtém pacientes
		List<Paciente> pacientes = pacienteRepositorio.todosPacientes();
		req.setAttribute("pacientes", pacientes);
 
		// passa para uma página jsp
		req.getRequestDispatcher("/WEB-INF/agendaForm.jsp").forward(req, resp);
	}
 
	@EJB
	private MedicoRepositorio medicoRepositorio;
 
	@EJB
	private PacienteRepositorio pacienteRepositorio;
}

Não se deveria haver duas chamadas ao model dentro de um controller. Mas nesse caso, não consigo imaginar uma situação melhor. Acho muito burocrático fazer um método que retorna um DTO contendo as listas de Medico e Paciente; além do nome do método resultante não ter uma boa abstração (ou você acha que listaMedicoEPaciente() é um nome bom?). E não consigo achar um jeito de usar apenas um objeto raiz, onde os outros seriam obtidos através deste; a relação entre Medico e Paciente ainda vai ser criada, ela não existe no momento de carregar o formulário. Portanto, deixarei assim mesmo.
A view não possui nada de novo em relação às versões anteriores:

	<jsp:useBean id="medicos" scope="request" type="java.util.List"/>
	<jsp:useBean id="pacientes" scope="request" type="java.util.List"/>
 
	<form method="POST" action="marcaConsulta">
		<p>Selecione o m&eacute;dico:
		<select size="1" name="medicoId">
			<option value="0">M&eacute;dicos</option>
			<c:forEach items="${medicos}" var="medico">
			<option value="${medico.id}">${medico.nome}</option>
			</c:forEach>
		</select>
		</p>
		<p>Selecione o paciente:
		<select size="1" name="pacienteId">
			<option value="0">Pacientes</option>
			<c:forEach items="${pacientes}" var="paciente">
			<option value="${paciente.id}">${paciente.nome}</option>
			</c:forEach>
		</select>
		</p>
		Dia: <input type="text" name="dia" size="10"><br/>
		Hora: <input type="text" name="hora" size="10"><br/>
 
		<p><input type="submit" value="Marcar Consulta"></p>
	</form>

O conteúdo será enviado à ação marcaConsulta, que será feita através da alteração do antigo Servlet AgendamentoServlet:

package br.com.objectzilla.agendamedica;
 
import java.io.IOException;
import java.io.PrintWriter;
import java.text.DateFormat;
import java.util.Calendar;
import java.util.Date;
 
import javax.ejb.EJB;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
@WebServlet(value = "/marcaConsulta")
public class AgendamentoServlet extends HttpServlet {
 
	private static final long serialVersionUID = -1218896541620785877L;
 
	@EJB
	private Agendamento agendamento;
 
	@Override
	public void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException,
			IOException {
 
		try {
			long medicoId = Long.parseLong(req.getParameter("medicoId"));
			long pacienteId = Long.parseLong(req.getParameter("pacienteId"));
 
			DateFormat dateFormat = DateFormat.getDateTimeInstance(DateFormat.SHORT,
					DateFormat.SHORT, req.getLocale());
 
			String horario = req.getParameter("dia") + " " + req.getParameter("hora");
			Date date = dateFormat.parse(horario);
 
			Calendar cal = Calendar.getInstance(req.getLocale());
			cal.setTime(date);
 
			// chamando método de agendamento
			agendamento.marcaConsulta(medicoId, pacienteId, cal);
 
			resp.sendRedirect(resp.encodeRedirectURL("consulta?medicoId=" + medicoId
					+ "&horario=" + horario));
 
		} catch (Exception e) {
			PrintWriter out = resp.getWriter();
			out.print("Você fez alguma coisa de errado!");
		}
	}
}

Dessa vez, apaguei o doGet() e coloquei a ação de salvar a consulta em um doPost(). Realizei um redirect em um outro Servlet que faz a consulta de horários.
Servlet:

package br.com.objectzilla.agendamedica;
 
import java.io.IOException;
import java.io.PrintWriter;
import java.text.DateFormat;
import java.util.Calendar;
import java.util.Date;
 
import javax.ejb.EJB;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
@WebServlet(value="/consulta")
public class ConsultaServlet extends HttpServlet {
 
	private static final long serialVersionUID = 8084899967543431263L;
 
	@Override
	public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException,
			IOException {
 
		try {
			long medicoId = Long.parseLong(req.getParameter("medicoId"));
 
			Medico medico = medicoRep.getMedico(medicoId);
 
			DateFormat df = DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT, req.getLocale());
			Date d = df.parse(req.getParameter("horario"));
 
			Calendar horario = Calendar.getInstance(req.getLocale());
			horario.setTime(d);
			req.setAttribute("horario", horario);
 
			Paciente paciente = medico.consulta(horario);
 
			if (paciente == null) {
				paciente = new Paciente();
				paciente.setNome("(ninguém)");
			}
 
			req.setAttribute("paciente", paciente);
 
			req.getRequestDispatcher("/WEB-INF/consulta.jsp").forward(req, resp);
 
		} catch (Exception e) {
			PrintWriter out = resp.getWriter();
			out.println("Você fez alguma coisa de errado!<br/><br/>");
			e.printStackTrace(out);
		}
	}
 
	@EJB
	private MedicoRepositorio medicoRep;
}

E JSP:

	<jsp:useBean id="paciente" scope="request" type="br.com.objectzilla.agendamedica.Paciente"/>
	<jsp:useBean id="horario" scope="request" type="java.util.Calendar"/>
 
	<p>Data: <fmt:formatDate value="${horario.time}" type="both" dateStyle="long" timeStyle="medium"/></p>
 
	<p>Paciente: ${paciente.nome}</p>
 
	<a href="agendaForm">De novo</a>

Você pode agora digitar http://localhost:8080/AgendaMedica/agendaForm no seu browser e inserir uma consulta qualquer. Ao fazer a submissão, uma nova página será exibida, cuja URL tem parâmetros de medicoId e horario. Mude esses parâmetros e você verá que, em horários que você não marcou horário, aparece (ninguém) como paciente.
Faltam coisas ainda. A agenda permite horários esdrúxulos, como agendamento no passado, agendamento fora do horário comercial, agendamento de dois pacientes com um minuto de intervalo, e sobreposição de horário. Precisamos resolver todas essas validações. E outra, precisamos criar a classe Consulta, pois não faz sentido temos que mudar Médico quando um paciente quer marcar um dia. E seria bem melhor também, fazer as páginas web com algum framework. JSF 2.0 seria uma ótima pedida.
Mas tudo isso num próximo post.
]]>
			http://www.objectzilla.com.br/2009/02/24/aprenda-java-ee-6-agora-2/feed/
		2
		
		
		
		http://www.objectzilla.com.br/2009/02/15/aprenda-java-ee-6-agora/
		http://www.objectzilla.com.br/2009/02/15/aprenda-java-ee-6-agora/#comments
		Sun, 15 Feb 2009 21:44:53 +0000
		Leonardo
				

		http://www.objectzilla.com.br/?p=154
		
			Quando fiquei craque no Java, a versão do “Enterprise Edition” era ainda 1.4. Eu aprendi a versão 5, logo depois do lançamento do Glassfish. Mas agora estou fazendo algo diferente, não vou esperar a versão Java EE 6 sair, vou aprender as coisas tão logo as novidades apareçam.

E você também pode fazer isso. Pegue uma versão promoted do Glassfish no site deles, que, assim como o Lost, tem sempre uma versão nova nas quartas à noite, que você baixa na quinta. A última versão, que estou usando nesta semana, é a b36.
Baixe a última versão disponível e descompacte num lugar que você achar apropriado. No Eclipse, na hora de instalar o servidor, basta escolher a opção “Glassfish v3 Prelude” (se você não usava Glassfish, na tela de novo servidor há uma opção de baixar os adaptadores para outros servidores). Pronto!
Eu vou fazer uma aplicação de exemplo, que é uma agenda de consultório médico. É babaca, mas tem uma regras óbvias que não dá pra ser tratado com o velho CRUD.
Vamos lá. Crie um “Dynamic Web Project” cujo Runtime seja o “Glassfish v3 Prelude”, vou chamá-lo de AgendaMedica. Não sei como vocês lidam com testes no Eclipse, mas costumo criar um novo projeto Java que referencia o projeto que estou interessado em testar. No caso, criarei também o projeto Java AgendaMedicaTeste. Após criado, dê <Alt> + <Enter> sobre o projeto, clique em “Java Build Path”, vá na aba “Projects” e adicione o projeto AgendaMedica.
No projeto AgendaMedicaTeste, eu já criei um método de testes pra realizar a consulta:

package br.com.objectzilla.agendamedica;
 
import java.util.Calendar;
 
import org.junit.Assert;
import org.junit.Test;
 
public class AgendamentoTeste {
 
	@Test
	public void pacienteMarcaHoraComMedico() {
		// um paciente...
		Paciente paciente = new Paciente();
		paciente.setNome("Maria");
 
		// um médico...
		Medico medico = new Medico();
		medico.setNome("Dr. Gregory House");
 
		// ambos agendam um horário
		Agendamento agendamento = new AgendamentoImpl();
		Calendar horario = Calendar.getInstance();
		horario.set(2009, Calendar.MARCH, 5, 17, 00, 00);
 
		agendamento.marcaConsulta(medico, paciente, horario);
 
		// agora, médico tem consulta com paciente marcada às 5
		Paciente pacienteMarcado = medico.consulta(horario);
		Assert.assertEquals(paciente.getNome(), pacienteMarcado.getNome());
	}
}

Beleza, mas o código não compila, né? Ora, não seja por isso. Vá criando as classes clicando nos erros com o botão direito do mouse, só não se esqueça de colocar as classes no projeto AgendaMedica. No caso, Agendamento é uma interface e o restante são classes.
Bom, tente rodar o script de teste (clique com botão direito sobre a classe e dê Run As… > JUnit Test). Vai dar erro, óbvio! Por isso, convido a você a escrever código nas classes até o script rodar com sucesso. Não se preocupe, se você não conseguir ou não tiver paciência, no final do post eu mostro o link onde você pode baixar o código.
Agora, vamos transformar a interface Agendamento em um Stateless Session Bean. Não precisa nem mover pra um projeto próprio, pois agora os EJBs podem ser “deployados” em aplicações WAR. Basta adicionar @Local na interface (a v3 ainda não possui suporte a @Remote), assim:

@Local
public interface Agendamento {
	// ...
}

E adicionar @Stateless na classe que implementa:

@Stateless
public class AgendamentoImpl implements Agendamento {
	// ...
}

Pronto, faça o deploy do projeto web no servidor Glassfish v3 e veja o seguinte log aparecer:
INFO: Bound Java:Global name [business view] : java:global/AgendaMedica/AgendamentoImpl#br.com.objectzilla.agendamedica.Agendamento
INFO: Bound Java:Global name [single business view] : java:global/AgendaMedica/AgendamentoImpl

Repare em como é realizado o binding com o JNDI. A partir da versão 6, não será mais uma implementação específica de contêiner. Todos os servidores de aplicações, se quiserem ser homologados para Java EE 6, deverão dispor seus EJBs, em contextos JNDI, de acordo com o seguinte padrão:
java:global[/<application-name>]/<module-name>/<bean-name>#<interface-name>
Onde:
<application-name> é opcional, refere-se ao nome do pacote EAR (não tem no nosso caso).
<module-name> é o módulo onde está o EJB (AgendaMedica).
<bean-name> é o nome do bean (AgendamentoImpl).
<bean-name> é o nome do bean (AgendamentoImpl).
<interface-name> é o nome completo da interface que implementa o bean (br.com.objectzilla.agendamedica.Agendamento).
O leitor atento deve ter reparado: está sendo feito dois bindings para o EJB! Isso também faz parte do padrão. Se o bean implementar apenas uma interface, um alias será criado onde o nome da interface não aparece.
Já que criamos o Session Bean, seria interessante se usássemos, não é não? Vamos fazer um Servlet, mas não precisa tomar o susto de configurar o wer.xml, pois basta criar um classe que herde de HttpServlet e adicionar uma anotação de acordo com o seguinte código:

@WebServlet(value="/agendamento")
public class AgendamentoServlet extends HttpServlet {
 
	@Override
	public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException,
			IOException {
 
	}
}

Após o deploy, basta digitar http://localhost:8080/AgendaMedica/agendamento e você vai ver… uma tela em branco. Normal, a gente não fez nada mesmo. Agora, vamos preencher o doGet() com uma chamada ao método de marcarConsulta() de agendamento. Eu também injetei uma instância de EJB.

@WebServlet(value="/agendamento")
public class AgendamentoServlet extends HttpServlet {
 
	@EJB
	private Agendamento agendamento;
 
	@Override
	public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException,
			IOException {
 
		String nomeMedico = req.getParameter("medico");
		String nomePaciente = req.getParameter("paciente");
		int hora = Integer.parseInt(req.getParameter("hora"));
 
		// criando médico
		Medico medico = new Medico();
		medico.setNome(nomeMedico);
 
		// criando paciente
		Paciente paciente = new Paciente();
		paciente.setNome(nomePaciente);
 
		// criando horário
		Calendar horario = Calendar.getInstance();
		horario.set(Calendar.HOUR, hora);
		horario.set(Calendar.MINUTE, 0);
		horario.set(Calendar.SECOND, 0);
 
		// chamando método de agendamento
		agendamento.marcaConsulta(medico, paciente, horario);
 
		PrintWriter pw = resp.getWriter();
		pw.format("Eu juro que marquei consulta para o paciente %s, com o médico %s, na hora %d.",
				medico.getNome(), paciente.getNome(), horario.get(Calendar.HOUR));
 
 
	}
}

Se você rodar http://localhost:8080/AgendaMedica/agendamento?medico=Jose&paciente=Adolfo&hora=14, vai ver que a aplicação mostra uma mensagem na tela que não diz se foi, ou não foi, feito algo. Precisaria de uma tela de consulta, mas só dá pra fazer isso se nossa aplicação persistisse os objetos entre as requisições, o que atualmente não ocorre.
Vou fazer isso no próximo post, onde apresentarei mais novos recursos e novas funcionalidades na aplicação pra que ela finalmente funcione de verdade.
Quem quiser, pode ir alterando a aplicação por conta própria, deixei no repositório GitHub em http://github.com/leonardoverissimo/javaee-6-application/tree/master.
]]>
			http://www.objectzilla.com.br/2009/02/15/aprenda-java-ee-6-agora/feed/
		4