Na atual vertente do desenvolvimento, usamos cada vez mais orientação
a objetos e, consequentemente, temos que persistir nossas informações em
algum lugar seguro e de fácil acesso. Para isso, podemos utilizar um
SGBD (Sistema Gerenciador de Bancos de Dados) que também seja OO, ou então lançamos mão de um recurso chamado ORM
(Object-Relational Mapping ou Mapeamento Objeto-Relacional).
Trabalhando dessa forma, conseguimos fluir com nossos domínios de
problema sem nos preocuparmos diretamente com o armazenamento das
informações, tudo pode ser feito utilizando a prática e simples OO. Com
isso, surgiram novas formas de se obter os dados, ou objetos, desejados.
E uma que está em alta ultimamente entre os desenvolvedores .Net é a
“Language Integrated Query” ou como é mais conhecida: LINQ.
À primeira vista LINQ, é “uma coisa linda de Deus” (parafraseando uma
amiga minha), faz consultas em coleções e possui os mais variados
retornos, além, é claro, de garantir que suas consultas estão escritas de
forma correta. A partir daqui, encontramos nosso primeiro desafio:
“Tenho uma tela repleta de filtros dinâmicos, algo como uma consulta de
BI”, normalmente isso seria resolvido com uma simples concatenação de
“strings” para formar uma grande cláusula “where”, mas como resolver
isso com LINQ, já que o mesmo é formado apenas de código compilado?
Pensando nisso, a equipe de desenvolvimento do LINQ disponibilizou uma
biblioteca de consultas dinâmicas, que pode ser obtida neste exemplo. Incluindo a biblioteca em nossos projetos, podemos fazer consultas como o exemplo a seguir:

Utilizando a “Dynamic Query Library”, fica bem simples criar as
consultas dinâmicas; esse é um recurso muito bom e muito útil, mas usem
com sabedoria devido ao custo computacional maior. Caso queira se
aprofundar no assunto, recomendo, antes de qualquer coisa, ler esse artigo no blog de Scott Guthrie.
Certo, resolvido o problema das consultas dinâmicas, o sistema é
implantado e, após alguns meses de funcionamento, um usuário identifica
um comportamento estranho e questiona a consistências dos dados; ele
está no telefone falando com o suporte e espera uma resposta imediata. Em um ambiente tradicional, simplesmente faríamos uma consulta SQL e, com
o retorno imediato, poderíamos analisar se a consistência foi realmente
comprometida. Mas o que faremos se o nosso banco de dados foi gerado
por um ORM e estiver organizado de uma forma simplesmente incompreensível?
Novamente as grandes mentes do mundo do desenvolvimento estão aí para
nos salvar! Depois de algumas pesquisas e leituras, encontrei o
recomendadíssimo LINQPad,
ele é muito parecido com o antigo “SQL Query Analyzer” e faz consultas
LINQ diretamente em nosso objetos de negócio possibilitando a solução
do problema apresentado. O LINQPad está disponível para uso e download
gratuito e, pagando uma licença, é possível ter acesso a recursos
avançados tal como o “Autocompletion”.
O LINQPad foi apenas um exemplo de ferramenta que já existe, mas nada
nos impede de construirmos o nosso próprio “LINQ Query Analyzer”. Podemos inclusive usar a biblioteca de consultas dinâmicas para isso.
Se você se animou com a idéia, deixe um comentário e eu posso, em um
próximo artigo, construir um passo a passo. Até a próxima!







