Jan 08 2007
.NET: Cinco dicas sobre o NHibernate
Depois de um ano batendo a cabeça contra o teclado para aprender a usar o NHibernate, sinto-me na obrigação de alertar/ajudar aos usuários sobre alguns detalhes que às vezes te deixam de cabelo em pé (ou sem cabelo, tanto faz, o chefe enchendo o saco será o mesmo).
1. Nunca, em hipótese alguma, use chaves primárias compostas
Eu fui obrigado a utilizar o NHibernate com tabelas que possuíam chaves primárias (PKs) compostas. Primeiramente, essa é uma péssima opção de design. Não acha? Então me responda: qual é o papel das PKs? No meu ponto de vista, e de outros “zilhões” de desenvolvedores do século 21, a PK serve unicamente para identificar uma linha de uma determinada tabela. É isso! Ponto final. Nada de querer facilitar a visualização de relacionamentos (cliente com seus contatos, por exemplo).
Enfie isso na sua cabeça e faça de conta que aprendeu com o tempo:
Chave primária = um e somente um campo chamado ID do tipo inteiro
O NHibernate teoricamente suporta o mapeamento de chaves compostas. Claro, na teoria é lindo. Na prática é um desespero. A sintaxe muda, a documentação é precária e até mesmo os próprios autores do best-seller no assunto, Hibernate In Action (é uma ótima referência ao NH, apesar de ser escrito baseado no irmão mais velho), não recomendam as PKs compostas.
2. Não use campos do tipo TIME
Por algum motivo cientificamente explicável, o NH não implementa suporte nativo aos campos TIME. Em outras palavras, isso significa que se você tiver um campo deste tipo na base de dados, terá que fazer uma implementação extra/proprietária para tratá-lo.
A solução é um tanto quanto simples, porém obscura. A documentação sobre este assunto é precária e o melhor de tudo: eu tinha uma implementação pra resolver esse problema… assim que fiz um update para a última versão do NH ela parou de funcionar! Maravilha, heim? Removeram umas classes que eu utilizava. Tudo bem que eram classes beta, mas estavam lá para qualquer abelhudo desesperado sair usando.
3. Curva de aprendizado gigante
Se você pensa que vai sair mapeando tabelas através de arquivos XML e classes C# e logo depois criar seu sistema e distribuí-lo, esqueça. Talvez esse não seja um ponto tão negativo quanto aparenta, pois a complexidade do NH faz com que os desenvolvedores tirem a bunda da cadeira e comecem a estudar padrões de projeto, gerenciamento de sessão e tudo o que há de melhores práticas para projetar e desenvolver um software.
Com o NH fui forçado a aprender técnicas de mapeamento objeto/relacional (O/R), alguns patterns do GoF e vários recursos do .NET. Tudo isso, sem dúvida alguma, refletiu em um crescimento intelectual/financeiro no que diz respeito à minha profissão.
4. Query By Example ignora a chave primária
A Query By Example (QBE) é um recurso muito interessante dos frameworks de persistência de objetos. Basicamente funciona assim: você instancia um objeto, carrega algumas propriedades e pede para o framework retornar todos os registros de acordo com o informado. O SQL gerado trará na sua clausula WHERE as restrições de acordo as propriedades carregadas no objeto.
Ponto negativo: o NH não considera os campos da chave primária. Mais uma vez a composite-id, ou seja, chave primária composta, ferra com a nossa vida. Sem ela, não é preciso usar QBE com campos da PK, afinal se a PK só tem um campo e você conhece ele, não tem motivo para informar outros. Com ela a coisa complica. Imagine o seguinte: cadastro de Clientes e Contatos, sendo que a tabela de Contatos possui sua chave primária formada pelos campos CodigoCliente e CodigoContato. Se eu quiser saber quais contatos de um determinado cliente são de Santa Catarina? O que fazer?
1 Contato c = new Contato(); 2 c.CodigoCliente = 1; 3 c.Estado = "SC";
Uma QBE usando o objeto do exemplo acima não iria considerar o valor da propriedade CodigoCliente. E aí, como fico? Não dá pra buscar todos os contatos de um cliente que moram em SC?
Para resolver esse “problema” (na realidade, como comentado anteriormente, é um problema de design) usa-se HQL, onde a query será montada manualmente incluindo as propriedades necessárias.
5. Os hermanos têm as respostas
É a realidade: o NHibernate não possui uma documentação sequer boa. A única solução para garantir a sobrevivência é pegando algumas idéias da comunidade Java, afinal eles estão anos luz à nossa frente quando o tema é persistência objeto/relacional.
O site JEEBrasil é uma excelente fonte de artigos sobre o Hibernate. E já que os dois frameworks são irmãozinhos (dizem que o NH nasceu superior, pois já conhece os erros do Hibernate e por isso não comete os mesmos - isso não reflete a minha opinião), por que não utilizar a documentação do outro? Vale a pena.
É isso aí. Apesar dessas considerações, continuo usando ele em projetos pessoais e profissionais. Depois que entra no ritmo, a produtividade cresce muito. Portanto, se você tem trauma dos DataSets que a Microsoft criou para resolver seus problemas (uh mau gosto heim), eis uma possível alternativa.
Espero que isso ajude alguém que esteja pensando em usar o NHibernate.
Até +.
