Artigo Java Magazine 40 - Hibernate e Stored Procedures

Hibernate e Stored Procedures

Obtendo o Melhor dos Mundos O/R e Procedural

Aprenda a integrar eficientemente o famoso framework de persistência ás stored procedures de seu banco de dados

Desde a sua versão 3.0, o framework de persistência Hibernate suporta a integração com stored procedures para alguns dos principais bancos de dados (Oracle, DB2, Sybase e SQL Server) e atualmente a versão 3.1.3 também oferece suporte a stored procedures desenvolvidas para MySQL e Apache Derby. Neste artigo vamos discutir como tirar o melhor proveito deste recurso de integração.

Remédio ou veneno?

Os principais gerenciadores de bancos de dados oferecem linguagens procedurais para o desenvolvimento de stored procedures (SPs). As SPs são tradicionalmente empregadas em sistemas corporativos por três motivos básicos, detalhados a seguir.

Aumento de desempenho

Por se tratarem de rotinas armazenadas no próprio banco de dados as SPs têm acesso imediato aos registros das tabelas e são capazes de manipular um grande volume de informações sem gerar tráfego de rede. Variando entre fabricantes de banco de dados, as linguagens procedurais geralmente oferecem estruturas de controle e poderosos mecanismos de manipulação de cursores que permitem uma programação de baixo nível. Nas mãos de programadores experientes, essas linguagens podem resolver muitos problemas e gargalos de desempenho, que a arquitetura cliente/servidor, baseada em instruções SQL, não é capaz de

resolver. É verdade que muitos "gargalos" de desempenho são causados por problemas de modelagem do banco de dados.

Porém, o esforço de construção de uma stored procedure de alto desempenho pode ser menor do que e o necessário para remodelagem e migração de dados de produção.

Centralização de regras

Uma segunda motivação para o uso de stored procedures é a possibilidade de centralizar regras de negócio no repositório de dados. Freqüentemente encontramos várias aplicações desenvolvidas em plataformas diferentes acessando o mesmo banco de dados. Nesta situação

pode ser desastroso pressupor que todas as aplicações reproduzem fielmente as mesmas regras de negócio para manipular os dados. Aqui as stored procedures são valiosas para criar uma camada de regras unificada e obrigatória para todos que pretendem operar com os dados. (Triggers de banco de dados podem ser uma opção às SPs neste caso - confira o quadro

"Regras de negócio com Triggers".)

Mais segurança

As políticas de segurança de uma empresa podem apontar tabelas que contêm informações sensíveis e que não devem ficar à disposição dos programadores e da maioria das aplicações. As views de bancos de dados constituem uma primeira solução, expondo informações de maneira controlada e reduzindo assim os riscos de segurança.

Porém, em algumas situações o uso de views pode reduzir o desempenho em operações de consultas mais elaboradas especialmente quando precisam ser combinadas com outras tabelas através de joins. Quando encontramos tal impasse podemos abandonar as views e resolver as operações de consulta através de stores procedures desenvolvidas por administradores

de banco de dados (DBAs) ou por outros técnicos com permissão de acesso as tabelas mais sensíveis.

Desvantagens

Ao considerar as SPs, não podemos ignorar seus pontos negativos. O primeiro deles é a portabilidade. A criação de muitas stored procedures pode manter as soluções tecnológicas de uma empresa vinculadas a um fabricante de banco de dados, pois as linguagens procedurais

normalmente são proprietárias. Diante da necessidade de adotar um novo gerenciador de banco de dados (SGBD), a tarefa de re-escrita das SPs representa um investimento alto. Num momento como esse, as empresas podem preferir adotar outras arquiteturas para não cair em um novo cenário de dependência de um SGBD específico.

Um outro ponto negativo tem a ver com o desempenho. Uma stored procedure mal programada ou mal testada pode comprometer o desempenho de todo o banco de dados, e conseqüentemente, de todas as aplicações dependentes deste banco.

Discutimos algumas alternativas as SPs no quadro "Alternativas Java".

Vantagens do Hibernate no contexto

antes de mostrar como acessar SPs através do Hibernate, vamos comentar quatro capacidades muito importantes do Hibernate, que não podemos perder de vista ao adotar esse framework como solução de persistência.

A primeira dessas capacidades é o que todos esperam em um framework de persistência: o mapeamento objeto-relacional. Uma vez que as colunas das tabelas estejam mapeadas para os atributos das classes, não precisamos escrever instruções em SQL, ou manipular a API JDBC. Mais ainda, não precisamos instanciar e preencher os objetos com valores recuperados

de consultas ao banco de dados." [...] continue lendo...