LINQ to SQL está morto?

Existe algum motivo para continuar usando o Linq to SQL ou é melhor mudar para técnicas ORM como EF, NHibernate etc.

Estamos usando o Linq to SQL em um novo aplicativo corporativo de grande porte que existirá por muito tempo. A motivação para esse novo aplicativo corporativo é que o aplicativo era comum escrito em Visual Basic e, como a Microsoft interrompeu o suporte, fomos forçados a reescrever o aplicativo. Parece que já estamos lá, mas desta vez com o nosso DAL (Data Access Layer).

Eu já li este artigo , mas ele se compara apenas à fraqueza da EF.

Se você já está usando e não encontra nenhuma dificuldade, eu continuaria com ele em projetos existentes.

O Linq2SQL é um ORM bastante agradável, mas limitado - se você deseja mapear seus objetos de maneiras mais complexas que as básicas fornecidas pelo Linq2SQL, ficará paralisado. A Microsoft corrigiu alguns bugs quando lançou o .net 4, mas afirmou que não vai dedicar recursos para estendê-lo.

Eu diria que se você tiver um projeto bastante simples que possivelmente tenha uma vida útil limitada, o Linq2SQL é uma escolha leve e decente, desde que você tome cuidado para não vazar dependências do Linq2SQL em todo o lugar. Para qualquer coisa mais, eu iria com outra coisa (NHibernate ou EF, por exemplo), pois o Linq2SQL é praticamente um beco sem saída.

Não está morto, mas a Microsoft agora está focada no Entity Framework.

Eu usei o LINQ to SQL em pequenos projetos, e é muito bom como uma camada de dados leve e consideraria usá-lo novamente em projetos de tamanhos semelhantes. A implementação do LINQ em si é realmente boa e até recentemente muito melhor que o projeto LINQ do NHibernate. No projeto maior em que usei o L2S, achei difícil criar um padrão de unidade de trabalho que me agradava, devido a limitações na classe 'DataContext' do L2S. Tentar implementar algo como 'Sessão por solicitação' com L2S parece muito difícil ou impossível.

Eu também não consideraria o L2S como um ORM verdadeiro, pois realmente não oferece muitas opções de mapeamento. Seu design de classe realmente precisa seguir o esquema do banco de dados (tabela por classe), caso contrário, ele lutará com você a cada passo do caminho. Outra coisa que eu não gosto no L2S é a necessidade de usar tipos específicos ( EntitySete EntityRef) para lidar com coleções, referências e carregamento lento. Isso significa que não é possível manter o ORM do modelo de domínio independente de adicionar outra camada de abstração.

Meu outro problema com o L2S é a única dependência do LINQ para gerar consultas. O provedor LINQ é muito bem escrito e geralmente cria SQL decente para a maioria das consultas, mas tenho minhas preocupações de que haja consultas mais complexas que não possam ser bem expressas com o LINQ. Usando o L2S, você basicamente precisa reverter para chamar procedimentos armazenados nesses casos, enquanto (por exemplo) o NHibernate possui várias APIs (provedor LINQ, QueryOver, HQL etc.) que podem ser usadas quando você deseja mais controle sobre o SQL gerado.

Na defesa do L2S sobre o NHibernate, há muito menos sobrecarga na instalação e execução de um projeto.

Não está morto, pois ainda funciona, mas se não estiver sendo desenvolvido mais adiante, pode fazer sentido mudar para outra coisa.

No entanto, se funcionar para o seu aplicativo, não há sentido em mudar para mudar.

mais estável que imho morto:

http://www.thinqlinq.com/default/LINQ-to-SQL-enhancements-for-2010.aspx

http://jonkruger.com/blog/2009/06/06/linq-to-sql-is-not-dead/

Eles transferiram seus esforços de melhoria para o Entity Framework, onde é realmente necessário para que esse produto seja bem-sucedido. Não espere nada de novo, além de compatibilidade e correção de bug no linq2sql por um tempo.

Este site é executado com um monte de linq2sql, se não me engano.

É estranho, mas já vi esse fraseado muito ("LINQ2SQL está morto") e não tenho certeza de onde ele vem *. É tão morto o Windows XP. A Microsoft interrompeu o suporte e criou algo novo (e aos meus olhos melhor), mas as pessoas ainda estão livres para usar o XP, assim como estão livres para usar o Linq2SQL. É certo que eu uso o Linq2SQL ao criar módulos DotNetNuke personalizados. No entanto, com novos recursos no EF4, como o primeiro código de desenvolvimento ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx ) é difícil encontrar razões para se manter no Linq2SQL. Não vejo um motivo para atualizar e atualizar o código, mas, para o novo código, não sei por que você não deseja usar o EF4.

* Com toda a honestidade, porém, sou muito ... obsessivo com a semântica! Peço desculpas se é irritante para os outros :)