JSF com Prevayler - Revista Java Magazine 95

O desenvolvimento de aplicações orientadas a objetos (OO) que utiliza bancos de dados relacionais para persistir seus objetos de negócio tem uma série de implicações. Uma delas é a quebra de encapsulamento. Ela acontece porque os dados podem ser manipulados irrestritamente por meio da SQL. Para amenizar esta situação, você pode até criar setters e getters para os atributos de suas classes, mas isso não significa nada para o banco de dados. Um UPDATE, por exemplo, não irá respeitar aquela regra de negócio fundamental que você implementou no método set.

Outro problema com o uso de bancos de dados relacionais é a restrição que eles impõem em seus objetos de negócio. Você não pode estruturar seus objetos de qualquer jeito; tem que ser de um jeito “mapeável” em tabelas e preferencialmente da forma mais simples possível, como o formato classe-tabela e atributo-coluna. E aqui está outro problema: o tempo computacional gasto com a conversão de objetos para tuplas e vice-versa. No entanto, embora existam alguns padrões de projeto para isso, o fato é que seus objetos de negócio, na maioria das vezes, devem seguir regras limitantes, como implementar uma interface ou estender uma classe, e os métodos devem seguir um padrão de nomenclatura.

Devido a estes fatores, alguns desenvolvedores criam o esquema de banco de dados para depois criar as classes; outros, por sua vez, criam as classes e depois as tabelas. Na primeira alternativa, pode-se arriscar em dizer que as classes resultantes utilizarão somente 10% de todo o poder da OO. São classes “anêmicas”. Na segunda alternativa, o mapeamento para tabelas poderá não ser trivial, podendo ser feito somente com alguns “ajustes” – afinal, é impossível mapear esses dois paradigmas (OO e relacional) sem perder alguma coisa. Esses problemas fazem parte de um conjunto maior, denominado de Object-relational impedance mismatch (algo como incompatibilidade objeto-relacional).

Deste modo, alguns acreditam que sistemas de informação utilizam pouquíssimas funcionalidades da OO porque a persistência de dados é feita de maneira não-OO, e.g. em bancos de dados relacionais. O Prevayler, contudo, fornece uma maneira de persistir seus objetos como eles deveriam ser persistidos: como objetos, e não como tuplas. Assim, seus objetos podem ter a estrutura, os nomes de métodos e os tipos de atributos que quiser. O sistema fica muito mais rápido porque os objetos estão sempre em sua forma nativa – não há a necessidade de converter tuplas, tipos, etc. A rapidez é importante principalmente em sistemas web, já que a maioria deles é orientada a consultas, ou seja, consultas são muito mais frequentes que inclusões.

Uma grande parte do mercado usa o JavaServer Faces para criar sistemas web. De forma simplista, o JSF é um framework em que as páginas web são criadas pela composição de componentes e que oferece uma forma simples de comunicação entre esses componentes e os objetos de negócio. Tal comunicação é feita utilizando managed beans, que são objetos com tempo de vida (ou escopo) predeterminado.

O JSF 2 trouxe uma série de novidades, dentre elas a navegação implícita, em que torna facultativa a especificação de regras de navegação no faces-config.xml, bastando apenas especificar a URL. Outra novidade é o escopo View, em que o managed bean continua vivo enquanto a aplicação estiver na mesma página, o que não é possível com o escopo Request porque a cada submissão um novo bean é criado. Esse escopo é ótimo para utilizar AJAX, o que, aliás, é outra inovação no JSF 2.

Neste contexto, vamos aprender a construir uma aplicação simples em JSF 2 utilizando as novidades supracitadas e tendo o Prevayler como framework de persistência de dados. Veremos as principais funcionalidades do Prevayler e como utilizá-las em JSF.

Prevayler

Prevayler é um framework open source de persistência inicialmente desenvolvido pelo brasileiro Klaus Wuestefeld. O framework oferece uma alternativa ao famigerado Mapeamento Objeto-Relacional, implementado por vários frameworks de persistência, como o Hibernate. Quando se utiliza esse mapeamento, os objetos de negócio ficam presos à semântica do banco de dados relacional, impedindo o uso de todo o poder da Orientação a Objetos (OO) e frequentemente quebrando parte do encapsulamento. Com o Prevayler, não precisamos mapear os objetos de negócio às tabelas do banco de dados porque simplesmente não há tabelas e nem mesmo banco de dados. Todos os objetos são mantidos vivos na memória RAM!

Mas e se o servidor der pane ou acabar a energia? Não tem problema. Periodicamente (toda noite, por exemplo), todos os objetos são serializados em um arquivo chamado de "