Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Mapeando modelos dinâmicos do NHibernate usando XML - Revista .net Magazine 88
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 necessi
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 88
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.
Quando mapeamos nossas classes de modo convencional, nos arquivos do tipo XML, iniciamos com a tag “class” e definimos o atributo “name” com o nome da classe que será a representação da tabela física mapeada com esta. Como já comentado antes, não teremos classes definidas no modelo, portanto aqui entra a diferença do modelo dinâmico.
Talvez alguém já tenha percebido que temos mais possibilidades de atributos nesta tag, e dentre elas, temos o atributo “entity-name”. Este é o atributo que utilizaremos para referenciar as entidades no mapeamento. Os demais campos mapeados no arquivo XML mantêm a mesma forma de estruturação, com as tags do tipo id, property e relacionamentos, assim conforme faríamos para o modelo convencional com o NHibernate.
Na Listagem 1 podemos visualizar um arquivo de configuração para a tabela Produto de uma base de dados. Estão destacados os atributos “entity-name” que tornam o mapeamento dinâmico. Nesta listagem estamos considerando que as entidades “Grupo” e “Fornecedor” também estão mapeadas conforme mapeamento dinâmico, como podemos verificar nas tags de relacionamento ao final do mapeamento.
Claro que apenas realizando as configurações conforme citado e abolindo as classes de persistência de nosso aplicativo ainda não teremos uma configuração dinâmica. O que precisamos ainda é permitir que de alguma forma nosso arquivo de mapeamento seja configurado e definido pelo usuário, pois será ele quem definirá quais entidades o aplicativo utilizará e quais os campos de cada entidade, relacionamentos etc.
" Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Fabio Rosa
Analista Programador há 3 anos, integrante da equipe de desenvolvimento da empresa Lógica Informática. Domínio em UML, SQL Server, WPF, Silverlight, Windows Forms e GeneXus. Cursando Análise e Desenvolvimento de Sistemas pela UNOPAR.
