De que se trata o artigo

Trata da utilização do NHibernate para possibilitar a configuração do modelo de dados do sistema de forma mais dinâmica e a adaptação deste mesmo modelo com o modelo de dados físico presente no cliente, em tempo de execução, ou seja, sem necessidade de ajustar o sistema para atender o padrão.

Em que situação o tema é útil

No desenvolvimento de um sistema de integração de dados que solicite ler, alterar ou gravar dados a partir de um sistema diferente onde, o mesmo já possui uma estrutura consolidada das informações. Um bom exemplo de aplicação é um sistema de emissão de NFe (Nota Fiscal Eletrônica), onde devem ser lidas informações das notas a partir de qualquer sistema, ou seja, qualquer estrutura de dados disponível.

NHibernate – Mapeando modelos dinâmicos com XML

O artigo inicia com uma breve introdução sobre NHibernate e a conceituação e utilização de modelos dinâmicos com o auxílio desta ferramenta, de forma a flexibilizar mais o projeto da aplicação tornando-a assim mais genérica. Após, será apresentado um exemplo básico de aplicação, para que o leitor coloque em prática os conceitos apresentados do modelo dinâmico utilizando a ferramenta NHibernate.

Atualmente temos disponíveis várias ferramentas de mapeamento objeto-relacional (O/RM) no mercado que auxiliam, e muito, o desenvolvimento de aplicações para banco de dados. Uma das ferramentas que está bem consolidada no mercado é o NHibernate. Esta ferramenta nasceu baseada em seu “irmão” para aplicações Java, o Hibernate, o que possibilitou a nós, programadores .NET, trabalhar de forma orientada a objetos com nossos banco de dados. Basicamente o NHibernate permite persistir objetos em banco de dados sem a necessidade de termos que tratar comandos SQL e ainda trabalhando em apenas um ambiente orientado a objetos, o que facilita a programação e organização do código fonte de nossas aplicações. Os comandos SQL necessários para gravar, alterar, excluir e pesquisar dados na base de dados são gerados automaticamente por ele.

Primeiramente, para quem não trabalhou ainda com NHibernate, sugere-se que ao menos faça a leitura e os exemplos práticos já demonstrados em artigos anteriores da .NET Magazine, pois será necessário ter um entendimento básico para entendimento dos cenários aqui expostos.

Para quem trabalhou ou trabalha com NHibernate com certeza sabe que temos arquivos de mapeamento para as classes do projeto. Estes arquivos são do tipo XML e são os responsáveis por gerar o “mapa” que permite o vínculo de classes com tabelas físicas no banco de dados. Geralmente temos um arquivo de mapeamento para cada classe no projeto, ou seja, temos vários arquivos do tipo XML que mantêm o mapeamento funcionando.

Quando trabalhamos com ferramentas de mapeamento objeto-relacional, na maioria das vezes o que queremos está compreendido em duas possibilidades mais utilizadas, que são:

• Criar uma aplicação conforme um modelo de dados lógico já definido: Neste caso o desenvolvedor cria as classes do seu sistema de acordo com o modelo do banco de dados pré-existente e então realiza o mapeamento entre estas classes e as suas tabelas físicas permitindo assim a persistência dos dados do aplicativo no banco de dados ao qual foi baseado;

• Criar uma aplicação que gere o Banco de Dados conforme o modelo de classes (Conceitual) do sistema: Neste caso o desenvolvedor cria as classes de seu sistema de acordo com as suas necessidades e então realiza um mapeamento destas classes e a geração automática do banco de dados através deste, assim criando uma forma de persistir os dados do aplicativo em um banco de dados.

Ambos os casos citados anteriormente são os mais comuns quando o NHibernate ou outra ferramenta de mapeamento é utilizada. Se realizarmos uma breve pesquisa na internet sobre exemplos ou artigos de NHibernate, com certeza serão encontrados muitos resultados contemplando estas formas de utilização.

Porém, há alguns casos em que não são possíveis, ou melhor, não são viáveis as aplicações descritas anteriormente para certo tipo de aplicativo. Imaginem um aplicativo de envio e validação de NFe (nota fiscal eletrônica) no site da receita federal. A NFe é exigida obrigatoriamente para diferentes tipos de empresas de diferentes produtos, como por exemplo uma empresa do setor metal-mecânico ou do setor têxtil, do setor calçadista, etc. E cada empresa destas possui seu próprio sistema de gestão ou um sistema de gestão fornecido por software-houses diferentes, onde a estrutura do banco de dados difere para cada uma delas, desde nome de tabelas, campos, informações, locais de informações.

Agora pense que todas estas empresas possam utilizar apenas um único software para gerar suas NFe e assinar sem a necessidade de ter que desenvolver ou contratar uma empresa para desenvolver uma versão específica para sua estrutura de dados e nem ao menos necessitar alteração de seu sistema atual para fornecer os dados necessários a um software terceiro. Isto é possível, conforme será demonstrado mais adiante.

Modelo dinâmico

Certamente o leitor já se deparou com a necessidade de desenvolver algo que não seja fixo em seu aplicativo, uma formatação de telas ou páginas, ou alguma configuração que se ajuste de acordo com as preferências do usuário do aplicativo. No NHibernate temos a possibilidade de agregar esta funcionalidade aos modelos de mapeamento, onde conseguiremos atingir o conceito de dinamismo em nossa aplicação. Como o conceito de modelo dinâmico ainda é pouco usado com ferramentas O/RM, esta funcionalidade é muitas vezes não percebida ou ignorada no NHibernate, porém está lá.

Inicialmente, para construir uma aplicação que não dependa de uma estrutura de entidades fixa, é um tanto lógico que não poderemos ter classes (de negócio) fixas no aplicativo, pois não conseguiremos atualizá-las de forma satisfatória em tempo de execução alterando seu nome seus atributos, os tipos de dados, ao menos não de uma forma prática e performática, além de que não saberemos quais entidades o cliente deseja considerar para o aplicativo. Visando esta necessidade, o NHibernate permite trabalhar com Collections, ao contrário de classes definidas. Utilizando Collections, os campos de nossas entidades podem ser definidos em uma Hashtable ou um Dictionary, e o que nos define qual a entidade que estamos trabalhando é o nome que mapeamos para a mesma no arquivo de mapeamento, o qual temos que informar no momento de realizar uma transação com o modelo. Se trabalharmos nesta forma já estaremos aplicando um modelo dinâmico.

...
Quer ler esse conteúdo completo? Tenha acesso completo