NHibernate - Revista .net Magazine 86

Desde as primeiras aplicações comerciais, onde o espírito dos modelos relacionais já estava presente no processo de análise e desenvolvimento, era necessário se preocupar com a integridade dos dados que uma aplicação gera e armazena. Isso reflete diretamente na forma como as aplicações são desenvolvidas e principalmente modeladas. Essa é uma questão que já foi muito bem resolvida pelos bancos de dados relacionais, que fizeram da integridade referencial o mantra de qualquer modelo. Coisas como chaves primárias, chaves estrangeiras, chaves únicas, são lei dentro de um banco de dados, e não podem ser violadas em hipótese alguma. Isso sem dúvida trouxe muita estabilidade e confiabilidade para os dados de uma aplicação. A segurança que a integridade referencial dá ao desenvolvedor que modela corretamente um banco de dados é impagável.

Mas é óbvio que só a integridade referencial não resolve todos os problemas de integridade das informações de um banco de dados. Temos diversas outras questões e detalhes que podem ferir a integridade de um modelo de dados. Uma delas é resolvida pelo mecanismo de transação, dos próprios gerenciadores de bancos de dados.

Uma transação é o atestado de segurança de um banco de dados, que um determinado conjunto de comandos será executado integralmente. Caso algum dos comandos dessa lista falhe, o banco de dados se encarrega de desfazer (ou não fazer) os demais. Esse mecanismo trouxe ainda mais integridade aos modelos, garantindo que operações mais complexas se tornassem ainda mais seguras.

O fantasma da integridade voltou a assombrar os desenvolvedores quando estes tiveram que lidar com o paradigma da orientação a objetos. Com a crescente tendência das linguagens orientadas a objetos, cada vez mais aplicativos são modelados com esse novo paradigma, e não mais através das regras de modelagem do mundo relacional.

Apesar dessa mudança, os bancos de dados relacionais permanecem como opção número um para o armazenamento. A diferença é que nessa nova forma de se construir aplicações, o modelo é criado na orientação a objetos, e um mapeamento é feito para que os dados gerados por esse modelo sejam devidamente armazenados em um banco de dados relacional.

Com esse novo paradigma, é claro que a preocupação com a integridade aumentou. A integridade dos dados não deve mais ser garantida apenas pelo banco de dados, mas também pelo modelo criado pela orientação a objetos. E mais, a integridade precisa ser garantida no processo que faz a comunicação entre o modelo de objetos, e o modelo relacional do banco de dados.

Esse é um dos objetivos das ferramentas de ORM (Mapeamento Objeto Relacional), como é o caso do NHibernate. Um ORM precisa garantir ao modelo, a mesma integridade garantida pelo banco de dados relacional. Caso contrário o que temos é um modelo falho, onde sempre será preciso recorrer ao banco de dados para validar a integridade dos dados. Isso foge completamente da ideia de uma aplicação modelada com a orientação a objetos, onde toda a estrutura de dados, regras de negócio e integridade, são definidas em classes e associações, e não através de tabelas e relacionamentos.

Esse artigo irá explorar um dos principais recursos do NHibernate, que garantem alguns níveis de integridade ao modelo. São os recursos de Cascade, que garantem a execução automática de comandos para objetos associados ao objeto principal.

O Cascade do NHibernate permite uma série de configurações diferenciadas, mas em resumo, ele garante que ao persistir determinado objeto, outros objetos relacionados serão persistidos também. Causando assim uma operação em cascata. É claro que todo esse comportamento em cascata é configurado de acordo com a integridade esperada pelo modelo."