Arquivo de outubro \27\-03:00 2009

Repositórios e Expressões Lambda

Publicado por Alexandre Valente em Uncategorized em 27/10/2009

Esta semana fizemos mais uma grande melhoria na nossa camada de domínio, incorporando expressões lambda .Net nas nossas consultas e parâmetros de ordenação de repositórios. Retomando o post sobre a camada de domínio, os repositórios são utilizados para tirar a dependência da aplicação dos detalhes de persistência de objetos e para ser uma representação abstrata de uma coleção de entidades de domínio.

A idéia é que eles facilitem a busca de entidades específicas ou implementem métodos mais complexos para a execução de consultas. Como no nosso caso usamos o NHibernate para camada de persistência, nós temos duas opções de efetuar estas consultas, os Criterias (DetachedCriteria ou expressões ICriterion simples) ou o HQL, que é uma linguagem de consulta parecida com SQL só que composta pelas entidades de domínio.

Consultas HQL são baseadas em strings (ver exemplo abaixo do nosso sistema de ServiceDesk), o que é extremamente flexível porém não suporta intellisense nem é compilada (o que pode facilitar erros no caso de refactors). Mas, para o HQL não temos muita opção, a alternativa que seria usar o NH Linq ainda não é viável (pelo que eu tenho visto, ainda não suporta muitas coisas).





public int TotalInbox(User user) {
   const string hql =
       @"select count(*) from Incident i inner join i.Allocation a


         inner join a.SupportGroup s inner join s.Users u 


         inner join i.Company c
         where i.ClosedOn is null and a.SupportUser is null
         and i.State != isnull(c.WaitingUserConfirmationState,-1) 


         and i.State != isnull(c.WaitingUserInformationState, -1) 


         and u = ?";
   return (int) ExecuteScalar<long>(hql, user);
}




O uso de Criterias é mais simples e é indicado para consultas com restrições diretas na entidade base (ou nas que possuem relacionamento direto com a entidade base). Porém, nos criterias é necessário especificar o nome da propriedade como string. Novamente, sem intellisense e sujeito a problemas de refactor. Como o uso de Criterias é muito mais freqüente, nós automatizamos na nossa camada de domínio a geração de uma classe estática com todas as propriedades das entidades de domínio (usando arquivos .tt de um editor T4). Desta forma, temos intellisense e no caso de refactor que cause alguma quebra, teremos um erro de compilação (já que as classes são sempre regeradas). E, conforme falado no post da camada de domínio, construímos ainda uma fluent interface para facilitar a escrita. O exemplo abaixo mostra isto em funcionamento. 




public long TotalClosed(User user) {
    return Query.Where(Restrictions.Eq(PN.User, user))


           .And(Restrictions.IsNotNull(PN.ClosedOn)).Count();
}




Esta solução estava bastante adequada até aparecer a alternativa de usarmos expressões lambda ao invés de gerar as classes estáticas. Existem algumas iniciativas já fazendo isto, como o projeto NHLambdaExtensions. Neste caso específico, porém, eles estão abordando isto como uma biblioteca à parte para a geração de Criterias do NH e não como algo integrado aos repositórios.


Felizmente, na nossa camada de domíno, os repositórios já são tipados para a entidade de domínio que eles representam. Desta foram, fica simples gerar as expressões. O exemplo abaixo mostra a mesma rotina acima, agora usando expressões lamdas.




public long TotalClosed(User user) {
    return 


      Query.Where(i => i.User == user && i.ClosedOn != null).Count();
}




Como pode ser visto, bem mais legível e intuitivo. E sem a necessidade de se usar classes estáticas de apoio! Ainda temos algum trabalho a ser feito, pois não é simples traduzir todos os tipos de lambda para restrições válidas. Mas para os casos mais simples como o acima, está já 100% funcionando.


Outro ponto interessante é que as funções que aceitam lambda podem ser expostos para camadas superiores de domínio, já que usar uma expressão lambda não causa dependência para a camada de persistência. Isto diminui de maneira significativa o próprio tamanho da implementação dos repositórios.


Finalmente, a utilização deste tipo de solução acaba sendo algo tão flexível que estamos passando a adotar em vários outros cenários. Na definição de classes de ordenação para consultas, na identificação de campos usados como atributos em formulários e controllers e assim por diante. Realmente algo muito simples que está aí desde o lançamento da versão 3.5 do .Net mas que demorou para  a “ficha cair” achar uma maneira legal de aplicar na nossa infraestrutura.


Quem quiser saber algum detalhe mais técnico da implementação basta me mandar um email. Até a próxima.

			

											
, , , , , 

										

												Deixe um comentário
					

					

			

			

		
			

				
Profissão Codificador


				

						

						
Publicado por Alexandre Valente em Desenvolvimento em 04/10/2009 

						

				


			

				
Acho que a carreira de muitos de nós, programadores, começa de maneira similar: usualmente em algum momento da adolescência temos contato com computadores, ficamos fascinados por eles (na minha época foi um Gradiente Hotbit MSX, com programação BASIC) e a partir daí começamos a programar. E se você está lendo este blog, é grande chance de que nunca mais você tenha parado!


Mas me pergunto como será o nosso futuro nesta carreira. Tirando os que mudam de área (viram gestores, analistas de “negócio”, instrutores ou simplesmente vão fazer outra coisa) ou os que passaram em concurso público (este é um assunto que eu nem vou entrar!), eu fico imaginando como seria o futuro dos que continuam a programar. Alguns se tornam consultores independentes famosos, o que irá garantir uma aposentadoria tranquila escrevendo livros, artigos e ministrando palestras. Mas acho que  atualmente a maioria dos bons codificadores trabalha no esquema de pessoa jurídica, para um ou mais clientes e vive da capacidade de horas que consegue fazer. E até quando? Em algum momento isto vai ficar cansativo, ou ele vai se desatualizar e vai sair do mercado (interessante que, salvo raras exceções esta ainda é uma área quase 100% masculina… mas isto é assunto pra outro post!). E qual será o destino destes codificadores?


Apesar de se trabalhar no esquema de pessoa jurídica implicar que se tenha um negócio, infelizmente esta é uma profissão com muito pouca “escala”, já que o limite são as horas que cada um consegue fazer no mês. Mesmo para os que têm uma veia empresarial e que contratam um ou mais auxiliares, esbarra-se no limite de gestão de equipe (que pra mim varia de 4 a 7 pessoas). A partir daí, a qualidade cai ou se começa a ter dificuldade de garantir entregas ou prazo. E as tentativas de crescimento com equipes maiores são extremamente complicadas – falo por experiência! E não é fácil ter um negócio dependente da venda de projetos ao invés de horas; da maneira que eles como são vendidos hoje, em regime de preço fechado, eles tem um risco altíssimo, que quase sempre é negligenciado para se garantir o melhor custo, resultando em mais prejuízos do que sucessos.


Assim me pego muitas vezes pensando neste assunto. Nossa profissão é jovem, ou seja, não tem muita gente no final de carreira ainda. Mas estamos prestes a chegar lá. E acho que se não começarmos a pensar e atuar nisto, pode ser que para a maior parte de nós, este fim de carreira não seja uma experiência muito tranqüila.


Outro ponto interessante é que os que permanecem codificando são justamente os melhores desenvolvedores. E lembrando da regra de 10:1 de produtividade (como o Steve McConnell sumariza bem aqui), isto significa que as pessoas que tem mais probabilidade de ter problemas no final da carreira são justamente as que são as grandes responsáveis por construir o que está sendo feito hoje, como líderes de times, arquitetos ou simplesmente “virando” noites para fazer aquele projeto atrasado e over budget ser entregue. De uma certa maneira, este grupo é a espinha dorsal dos que hoje fazem acontecer e que são usados pelos que não são tanto (para quem gosta de reflexões mais aprofundadas, recomendo o livro “Atlas Shrugged” da Ayn Rand. Escrito na década de 50, fala de uma sociedade onde poucas pessoas com excelência técnica e artística sustentam todos os demais até que elas se cansam e entram em “greve”… Muito interessante).


De certa maneira, a disseminação cada vez maior de metodologias ágeis melhora um pouco o cenário das pequenas empresas. A troca do modelo de venda em preço fechado por uma baseada em venda de equipes para iterações curtas beneficia todos, permitindo que os riscos sejam melhor gerenciados e expondo-os muito mais cedo no processo. Exemplos como a ThoughtWorks, que se especializou neste tipo de venda com sucesso mundial acabam incentivando a mudança de cultura que está em curso atualmente. Claro que vai demorar pra isto subir até que licitações públicas sejam feitas de forma diferente, por exemplo, mas acho que isto vai acabar acontecendo.


Mas isto não é a resposta para a grande maioria, que não tem vocação (ou interesse) em se transformar em empresários. E apesar de pensar bastante nisto, não vejo saída fácil e fico preocupado com o futuro destes desenvolvedores. Mas não deixo de conjeturar como seria se todos estes melhores codificadores se juntassem em algum tipo de empresa comum, onde a excelência técnica fosse aplicada na construção de produtos que resultassem em ganhos diretos. Interessante, não? Se alguém tiver pensamentos a respeito deste assunto, entre em contato!

			

											
, , 

										

												5 Comentários