Conheça nesse artigo os recursos de comandos em Cascata (Cascade commands) que o NHibernate possui. Veja como esse mecanismo pode facilitar transações que envolvem comandos INSERT, UPDATE e DELETE em várias tabelas.
Para que serve
Comandos em cascata, ou Cascade Commands, servem para tornar mais simples operações que envolvem duas ou mais tabelas. São clássicas operações onde é necessário incluir em um banco de dados, o registro pai de uma tabela, juntamente com vários registros filhos de outra tabela relacionada.
Em que situação o tema é útil
O NHibernate torna transparente operações em cascata, e permite um nível de configuração e flexibilidade que não há igual em outras ferramentas de ORM. Se você trabalha com estruturas de dados mais complexas, onde é comum haver transações que envolvam duas ou mais tabelas, os recursos de Cascade do NHibernate podem ser especialmente úteis.
Cascade no NHibernate
O NHibernate se destaca por ser uma ferramenta de ORM muito flexível, o que significa que ele está preparado para os mais variados cenários possíveis, envolvendo diferentes bancos de dados relacionais, e padrões de modelagem da Orientação a objetos. Existem literalmente dezenas de possibilidades de configuração no NHibernate. Esse artigo irá explorar apenas uma dessas configurações, o Cascade. Veremos as diferentes formas de configurar operações em cascata em um exemplo prático com um banco de dados SQL Server.
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." [...] continue lendo...
