Em Julho nós reportamos que o LINQ to SQL foi transferido para a equipe SQL Data Programmability. Este evento ampliou em muito a preocupação da comunidade de desenvolvedores, que teme que o trabalho no LINQ to SQL possa ser interrompido em favor do Entity Framework ADO.NET. Um anúncio recente de Tim Mallalieu, gerente de Produto de ambos LINQ to SQL e Entity Framework, exacerbou esta preocupação.
Nós estamos fazendo investimentos significativos no Entity Framework ao ponto de que ele será a nossa recomendação para soluções de acesso a dados no .NET 4.0 para cenários relacionais para o LINQ. Nós estamos ouvindo os clientes a respeito do LINQ to SQL e continuaremos evoluindo o produto baseado no feedback que recebemos da comunidade.
Se você interpretar literalmente, diz-se apenas que o Entity Framework receberá mais recursos de desenvolvimento que o LINQ to SQL. O problema é: a Microsoft tem um longo histórico de tornar tecnologias de acesso a dados obsoletas sem oficialmente dizer que estas não são mais suportadas.
Antes de irmos longe demais com o futuro do LINQ to SQL, paremos um momento para considerar seu passado. No The Origin of LINQ to SQL, Matt Warren descreve seu projeto como sendo algo "que não foi nem ao menos considerado para existir." Essencialmente, ele foi pensado apenas como um "dublê" para ajudá-los a desenvolver o LINQ até o momento em que o ORM real estivesse pronto. Mas este projeto, juntamente com o projeto mais amplo WinFS, parece ter sumido do mapa para nunca mais voltar. Na necessidade de alguma coisa, a decisão foi tomada visando iniciar o processo de transformar o LINQ to SQL em um produto de mercado.
Enquanto isso, outro projeto estava surgindo. O Entity Framework ADO.NET apresentou-se como sendo a solução total para mapeamento entre modelos de objeto e bases relacionais. Diferentemente do LINQ to SQL, que era específico para o SQL Server, este produto teria um backend plugável que, teoricamente, suportaria qualquer base de dados.
A escalada do Entity Framework causou o atraso do lançamento .NET 3.5/Visual Studio 2008. Foi completamente no prazo para o infelizmente chamado ".NET 3.5 Service Pack 1," que era mais um major release que um service pack. O Entity Framework foi criticado por duas razões.
Desenvolvedores não gostaram por causa de sua complexidade. Existe muito que um desenvolvedor precise aprender para utilizá-lo corretamente do que é necessário para o LINQ to SQL. Diferentemente do Entity Framework, o LINQ to SQL é melhor utilizado como um mecanismo de consulta e atualização sem nenhuma customização além de mapeamentos básicos de tabela.
Players de Banco de Dados também não gostaram da ferramenta por um motivo completamente diferente. Entity Framework não é específico por banco de dados, e não oferece maneiras de adicionar funcionalidades de bancos de dados específicos. Isto está tornando difícil para empresas como Oracle alcançarem a performance e funcionalidades que eles necessitam. DataDirect, um líder em adaptadores de alta performance para banco de dados, não liberará versões de drivers Oracle e Sybase até início do próximo ano. E a própria Oracle nem ao menos discute a possível data de entrega, uma vez que ela não consegue a performance desejada sem a Microsoft adicionar hooks adicionais em seu framework.
Com tanta coisa indo contra, não é novidade que equipes que esperam por um ORM mais leve não vejam o Entity Framework como uma opção viável. Mas ao mesmo tempo, eles estão preocupados com o fato de o LINQ to SQL já ser uma tecnologia morta.
Num post entitulado Microsoft mata o LINQ to SQL, Ayende Rahien escreve:
Fazer algo deste tipo é cuspir na cara de todos aqueles que investiram tempo e dinheiro no framework LINQ to SQL, apenas para ficarem a ver navios, com um produto acabado e um processo de porting custoso se algum dia eles quiserem ver novas funcionalidades. LINQ to SQL é um OR/M básico decente, e eu tive várias pessoas me dizendo que estavam dispostos a aceitar suas deficiências atuais, sabendo que seriam corrigidas na próxima versão. Agora, não haverá nova versão, e é muito ruim para a reputação da Microsoft.
Um comentarista da história original de nome Jens escreveu:
Então vocês estão realmente admitindo que o LINQ to SQL é um beco sem saída? Muito obrigado. LINQ to SQL possui esta atitude de "simplesmente funciona" e é subjacente ao nosso novo projeto. Eu nunca conseguiria persuadir meu chefe a migrar para o Entity Framework.
John, um outro comentarista, quer um caminho rasoável de migração entre os dois e uma versão "light" do Entity Framework.
Eu aprecio o desejo de se ter um único framework LINQ para banco de dados, mas eu espero que o proposto Entity Framework oferecerá compatibilidade completa com o LINQ to SQL? Permitir uma transição indolor às pessoas que não precisam de toda a força extra do framework. Eu preferiria fazer mapeamento OR por mim mesmo, e utilizar o LINQ to SQL como uma forma simples de pegar dados. EF é um caminho muito longe do que eu preciso!
O sentimento ecoou através de vários outros comentários. E é exatamente o que a Microsoft está fazendo. Num post de follow-up, Tim Mallalieu explicou:
Nós últimos meses nós estivemos buscando como alavancar o LINQ to SQL e o LINQ to Entities. Num primeiro olhar, alguém pode dizer que elas são tecnologias diferenciadas e podem ser evoluídas separadamente. O problema é que a intersecção de capacidades já está muito grande e os anseios dos usuários de cada uma das tecnologias levam os produtos a um caminho de convergência de funcionalidades muito rápido. Por exemplo, requisições comuns para o LINQ to Entities (que será entregue com o .NET 4.0) são POCO e Lazy Load. Similarmente, no lado do LINQ to SQL, nós somos questionados a prover novas estratégias de mapeamentos e outras funcionalidades que o EF já possui. Adicionalmente, existem requisições comuns por novas funcionalidades como UDT's e um suporte melhor a N-Tier para ambos. O anúncio realmente foca no ponto de que, após um profundo olhar e triangulação com parceiros internos e clientes, nós decidimos que o EF segue em frente no que diz respeito ao esforço global de convergência e com o tempo, fornecer uma solução única para que se possa abordar as diferentes requisições.
Então é isso; no longo prazo LINQ to SQL e LINQ to Entities se tornarão um só. No meio tempo, o trabalho de desenvolvimento no LINQ to SQL não será finalizado completamente.
Nós continuaremos a fazer investimentos no LINQ to SQL baseados no feedback dos clientes. Este post foi a respeito de esclarescer nossas intenções para o futuro e chamar a atenção para o fato de que da mesma forma que o .NET 4.0, o LINQ to Entities será a solução de acesso a dados recomendada para LINQ em cenários relacionais.