Esse artigo mostra o que é e para que serve o ConfORM, um framework que permite o mapeamento por convenção no NHibernate, eliminando a necessidade de ter um arquivo XML ou uma classe (C# ou VB.NET) de mapeamento para cada entidade do modelo de negócio.
Em que situação o tema é útil
É especialmente útil em aplicações com um grande volume de entidades de negócio, onde a manutenção dos arquivos de mapeamento pode se tornar um problema. Com o ConfORM o volume de código voltado para o mapeamento é reduzido consideravelmente.
ConfORM
ConfORM é um framework criado em um projeto fora do NHibernate, mas que vem para atender uma necessidade muito solicitada pela comunidade, que é a geração automática dos mapeamentos de um modelo de negócio. Isso é possível através do conceito de Mapeamento por Convenção, permitindo que uma série de padrões e regras definidas para o modelo, possam ser utilizadas como base para a criação automática dos mapeamentos das entidades de negócio.
No desenvolvimento de aplicações de negócio sempre se tem uma grande preocupação com a produtividade do desenvolvimento, que impacta principalmente no tempo que é gasto com a manutenção dessas aplicações.
A orientação a objetos proporciona uma enorme produtividade se comparada com métodos utilizados em linguagens que não adotam essa filosofia. Uma de suas características que mais exemplifica o ganho de produtividade é a reutilização de código dentro de um projeto.
Quanto mais se aplica os conceitos básicos da orientação a objetos em uma aplicação, mais código é reutilizado, mais produtividade se ganha e mais fácil é dar manutenção nesse aplicativo.
Mas isso nem sempre é uma verdade absoluta em um projeto de software. Por mais que se tente reutilizar e diminuir ao máximo a repetição de código dentro de um projeto, sempre existe algum ponto onde isso não é inteiramente possível.
O NHibernate é uma ferramenta ORM (Mapeamento Objeto Relacional), que permite a utilização de um banco de dados relacional em uma aplicação modelada com a orientação a objetos. Para saber mais sobre o NHibernate procure por uma das dezenas de artigos sobre o assunto na .NET Magazine. Quem trabalha com NHibernate sabe exatamente onde é difícil aplicar técnicas de reutilização. O ponto onde temos uma grande repetição de código está nos arquivos de mapeamento.
O NHibernate possui um mecanismo de mapeamento que determina como cada classe de negócio deve ser interpretada e como é sua representação em uma tabela de um banco de dados. Isso permite que uma classe possa ser salva em um banco relacional, e posteriormente ter seus dados recuperados deste mesmo banco de dados.
NHibernate e ORM
O NHibernate é um dos Frameworks de código aberto e externo ao .NET mais antigo e conhecido pela comunidade. E não é à toa, já que o NHibernate é uma das ferramentas de O/RM mais eficientes existentes no mercado. O/RM é outra dessas muitas siglas que existem na área de software, e significa Mapeamento Objeto/Relacional (Object/Relational Mapping).
Mapeamento Objeto Relacional é uma técnica onde é definido um mapeamento entre as tabelas de um banco de dados, com as classes de uma aplicação orientada a objetos. Na programação orientada a objetos, quando é necessário armazenar dados em um banco de dados relacional, o O/RM é uma excelente prática.
Apesar de não ser uma prática obrigatória, o uso de ferramentas de O/RM tem se tornado uma tendência muito forte de mercado. Uma prova disso é que a própria Microsoft tem investido muito na construção do seu próprio O/RM, o ADO.NET Entity Framework.
O NHibernate surgiu pouco tempo depois do surgimento da própria plataforma .NET Framework. Na verdade, o NHibernate veio da plataforma Java onde existe o Hibernate, que é amplamente utilizado e adotado por essa comunidade de desenvolvedores.
Daí já é possível perceber que o NHibernate é fruto de um tipo de trabalho não muito convencional no meio Microsoft, o software livre. E é curioso dizer isso, mas o NHibernate é um projeto totalmente aberto, para a plataforma Microsoft .NET Framework. Quando o NHibernate começou a ganhar adeptos, o .NET Framework estava em sua versão 2.0. A solução mais próxima a um O/RM que a Microsoft oferecia na época, eram os datasets tipados, nativos do próprio ADO.NET.
Porém, os datasets estão longe de ser um O/RM, pois simplesmente simulam a estrutura do próprio banco de dados. Apesar de ser uma solução muito eficiente em situações simples, ao longo do tempo podem se tornar um pesadelo para a manutenção de softwares mais complexos.
Foi nesse cenário que o NHibernate ganhou espaço. Uma mistura de produtividade do lado dos bancos de dados, com boas práticas do lado da orientação a objetos. E mesmo quando a Microsoft lançou soluções como LINQ to SQL e a primeira versão do ADO.NET Entity Framework, o NHibernate não perdeu seus usuários.
O motivo principal para que isso não tenha acontecido, é o comprometimento dos envolvidos no projeto. São empresas e desenvolvedores interessados na qualidade da ferramenta, que não para de crescer. Desde o seu lançamento já houve quatro importantes verões: a 1.2, 2.0, 2.1 e a atual 3.0.
Além disso, o NHibernate foi extrapolando os limites do O/RM, e outros projetos paralelos foram surgindo, agregando ainda mais valor no que pode-se chamar de “Ecossistema NHibernate”. São iniciativas como o uNHAddins, Fluent NHibernate, Hbm2Net, Nhibernate.Validator, NHibernate.Caches, NHibernate.Mapping.Attributes, NHibernate.Linq, NHibernate.Burrow, NHibernate.Spatial, NHibernate.ProxyGenerators, o próprio ConfORM, entre outras diversas iniciativas livres ou até mesmo proprietárias.
A última grande versão do NHibernate, a 3.0, surgiu recentemente e compatibilizou a ferramenta com a versão 3.5 do .NET Framework. Nela foram embutidas diversas melhorias, incluindo a linguagem LINQ que se tornou nativa. Atualmente já temos a versão 3.1 que trouxe uma série de correções e melhorias da versão 3.0. E a versão 3.2 já está em andamento e breve deve sair um novo release.
