Um pouco mais sobre ADO Entity Framewrok

Como eu escrevi no post anterior, essa semana eu baixei o CTP de junho do Orcas para dar uma olhada no produto, na verdade, o meu real interesse é ver como está a evolução do LINQ e e em particular do ADO Entity Framework (EF).

Pra quem não conhece, o EF será o novo framework de mapeamento ORM da Microsoft, uma espécie de concorrente do NHibernate.

Bom, após analisar os exemplos do EF, confesso que fiquei muito confuso. Não entendi muito bem porque eu tinha que fazer o mapeamento tanto em arquivos XML e também decorar as minhas entidades (DTO, Model, etc) com vários atributos com as mesmas informações que já estavam no XML.

Postei essa dúvida no fórum do MSDN (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1824146&SiteID=1 ) e algumas pessoas do time me responderam que é isso mesmo. A arquitetura do produto até agora te obriga a fazer uma herança na sua entidade, decorar suas propriedades com atributos e ainda por cima fazer o mapeamento com XML.

Ok, ok.. O visual studio faz boa parte do trabalho pra você, mas e o tal dos conceitos de persistence ignorance, POCO? Poxa, eu não quero que o meu model fique fortemente acoplado com um framework. Alguns podem falar que é purismo, que é frescura, mas não é. Eu simplesmente quero deixar meu model, minhas entidades de negócio desacopladas pra poder usar um outro framework sem muitos problemas se eu quiser.

No entanto, o pessoal do time de dev do produto disseram que a cada release eles estão trabalhando para chegar mais próximo do POCO (Plain Old CLR Objects), ou seja, uma classe .net que não herde de ninguém, não tenha nenhum atributo, umas classe pura e sem metadados. Isso é ótimo, mas me disseram também que isso não estará nem na primeira release que deve sair no meio de 2008.

Legal, então vou ter que esperar até 2009 pra ter um framework da Microsoft pra ORM que aplique conceitos básicos de orientação a objetos e que faça o que muitos frameworks (como o NHibernate, por exemplo) já fazem há algum tempo?? É isso aí !!

Estranho né?? Nem tanto, achei talvez uma explicação para isso. Parece que um dos Devs do produto não acha (ou pelo menos achava) isso importante e só começou a estudar isso agora, pois a comunidade está pedindo muuuito e ele achou que deveria ter uma razão pra isso :-)

Vamos ao comentário dele: "I have devoted real time to studying agile design principles and domain driven design........ Initially I thought that some of the requests for *complete* persistence ignorance were the products just of dogma rather than fully informed and reasoned arguments, but when so many people give such passionate feedback it was clear that I needed to investigate more before I could claim to have any sort of an informed opinion. The product of my research is that I am now truly convinced of the importance of complete persistence ignorance for some scenarios. As a result, the team is now working on a series of product changes aimed at ensuring that a later move to complete persistence ignorance will not be a fundamental breaking change."

O post completo pode ser lido em: Persistence Ignorance: OK, I think I get it now.

Bom, pelo menos fico feliz que o time da Microsoft começou a olhar outras alternativas de arquitetura e estudar um pouco de Design Patterns. (Que coisa não??)

Vou ficando por aqui esperando ansiosamente o próximo CTP pra ver o que teremos de melhoria no Entity Framework, mas enquanto não me convencerem que o EF é melhor, vou continuar com o bom e velho NHibernate, feito pela comunidade e com código aberto :-)


André Dias