Neste artigo veremos alguns problemas que bancos de dados relacionais impõem em sistemas orientados a objetos e como resolvê-los utilizando o Prevayler. Também veremos os principais conceitos e funcionalidades do mesmo e como podemos utilizá-lo com o JSF 2.
Em que situação o tema útil:
Útil principalmente em sistemas com consultas intensivas, como é o caso da maioria dos sistemas Web. Com o Prevayler, as consultas chegam a ficar 10.000 vezes mais rápidas que bancos de dados relacionais. Além disso, você pode utilizar todo o poder da orientação a objetos sem se preocupar com os detalhes restritivos de persistência. Dessa forma seus sistemas ficarão mais simples, mais velozes e mais manuteníveis.
Resumo DevMan:
O Prevayler é uma biblioteca de persistência que grava seus objetos na forma em que deveriam ser gravados: como objetos (e não como tuplas). Não há mapeamento em tabelas, configuração de servidor de bancos de dados, nem restrição do que você pode utilizar em seu modelo de negócios. Tenha todo o poder da orientação a objetos sem se preocupar com os detalhes de persistência. No artigo, é explicado como podemos utilizar essa biblioteca com o JSF 2.
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 snapshot. E se o servidor cair antes do snapshot ser criado? Perderei todas as alterações feitas? Não. Todas as alterações (i.e. inclusão, exclusão e alteração) também são registradas em disco antes de serem executadas. Ao ligar o computador novamente, o último snapshot é carregado e todas as alterações são executadas na mesma ordem em que ocorreram.
A quantidade de informações que você pode guardar está limitada ao tamanho da sua memória RAM. Para muitas aplicações, isso não chega a ser um problema. De modo geral, os objetos Java ocupam bem menos espaço na RAM do que quando persistidos em um banco de dados relacional. Imagine que um objeto Cliente, por exemplo, ocupe 256 bytes na memória. Ter um milhão de clientes significa cerca de 244 MB e isso representa menos de 6% de uma modesta memória de 4 GB.
...
