Entity Framework vs LINQ para SQL

Agora que o .NET v3.5 SP1 foi lançado (junto com o VS2008 SP1), agora temos acesso à estrutura de entidades .NET.

Minha pergunta é essa. Ao tentar decidir entre usar o Entity Framework e o LINQ to SQL como um ORM, qual é a diferença?

Pelo que entendi, o Entity Framework (quando usado com o LINQ to Entities) é um 'big brother' do LINQ to SQL? Se for esse o caso - que vantagens ele tem? O que é que o LINQ to SQL não pode fazer sozinho?

O LINQ to SQL suporta apenas o mapeamento 1 a 1 de tabelas, visualizações, sprocs e funções de banco de dados disponíveis no Microsoft SQL Server. É uma ótima API para a construção rápida de acesso a dados em bancos de dados SQL Server relativamente bem projetados. O LINQ2SQL foi lançado pela primeira vez com C # 3.0 e .Net Framework 3.5.

O LINQ to Entities (ADO.Net Entity Framework) é uma API ORM (Object Relational Mapper) que permite uma ampla definição de modelos de domínio de objeto e seus relacionamentos com muitos provedores de dados ADO.Net diferentes. Como tal, você pode misturar e combinar vários fornecedores de bancos de dados, servidores de aplicativos ou protocolos diferentes para projetar um mash-up agregado de objetos que são construídos a partir de uma variedade de tabelas, fontes, serviços etc. O ADO.Net Framework foi lançado com o .Net Framework 3.5 SP1.

Este é um bom artigo introdutório no MSDN: Introdução ao LINQ to Relational Data

Eu acho que a resposta rápida e suja é que

• O LINQ to SQL é a maneira rápida e fácil de fazer isso. Isso significa que você estará indo mais rápido e entregará mais rapidamente se estiver trabalhando em algo menor.
• O Entity Framework é a maneira completa e sem restrições de fazer isso. Isso significa que você levará mais tempo com antecedência, desenvolverá mais lentamente e terá mais flexibilidade se estiver trabalhando em algo maior.

O LINQ to SQL está realmente morto? por Jonathan Allen para InfoQ.com

Matt Warren descreve [LINQ to SQL] como algo que "nunca deveria existir". Basicamente, era para ser um substituto para ajudá-los a desenvolver o LINQ até que o ORM real estivesse pronto.

...

A escala do Entity Framework fez com que ele perdesse o prazo do .NET 3.5 / Visual Studio 2008. Foi concluído a tempo do infelizmente ".NET 3.5 Service Pack 1", que era mais uma versão importante do que um service pack.

...

Os desenvolvedores não gostam do [ADO.NET Entity Framework] devido à complexidade.

...

a partir do .NET 4.0, o LINQ to Entities será a solução de acesso a dados recomendada para o LINQ para cenários relacionais.

Há várias diferenças óbvias descritas nesse artigo @lars postadas, mas a resposta curta é:

• L2S está fortemente acoplado - propriedade de objeto a um campo específico do banco de dados ou mais corretamente o mapeamento de objetos para um esquema de banco de dados específico
• O L2S funcionará apenas com o SQL Server (tanto quanto eu sei)
• EF permite mapear uma única classe para várias tabelas
• A EF cuidará dos relacionamentos com MM
• A EF terá a capacidade de segmentar qualquer provedor de dados ADO.NET

A premissa original era que o L2S é para o Rapid Development e a EF para mais aplicativos de nível n "corporativos", mas isso está vendendo o L2S um pouco curto.

LINQ para SQL

1. Origem de dados homogênea: SQL Server
2. Recomendado para pequenos projetos apenas onde a estrutura de dados é bem projetada
3. O mapeamento pode ser alterado sem recompilar com SqlMetal.exe
4. .dbml (linguagem de marcação do banco de dados)
5. Mapeamento individual entre tabelas e classes
6. Suporta herança TPH
7. Não suporta tipos complexos
8. Abordagem Storage-First
9. Visualização centrada no banco de dados de um banco de dados
10. Criado por C # team
11. Melhorias suportadas, mas não mais, destinadas

Estrutura de entidade

1. Fonte de dados Heterogeneus: Suporte a muitos provedores de dados
2. Recomendado para todos os novos projetos, exceto:
   • pequenos (LINQ to SQL)
   • quando a fonte de dados é um arquivo simples (ADO.NET)
3. O mapeamento pode ser alterado sem recompilar ao definir arquivos de modelo e mapeamento Processo de Artefato de Metadados para Copiar no Diretório de Saída
4. .edmx (modelo de dados da entidade) que contém:
   • SSDL (linguagem de definição de esquema de armazenamento)
   • CSDL (linguagem conceitual de definição de esquema)
   • MSL (Linguagem de Especificação de Mapeamento)
5. Mapeamentos um para um, um para muitos e muitos para um entre tabelas e classes
6. Suporta herança:
   • TPH (tabela por hierarquia)
   • TPT (tabela por tipo)
   • TPC (tabela por classe de concreto)
7. Suporta tipos complexos
8. Abordagens de código primeiro, modelo primeiro e armazenamento primeiro
9. Visualização centrada no aplicativo de um banco de dados
10. Criado pela equipe do SQL Server
11. Futuro das APIs de dados da Microsoft

Veja também:

• Estrutura de entidade LINQ To SQL Vs
• Diferença entre LINQ to SQL e Entity Framework
• Entity Framework vs LINQ TO SQL

Minha experiência com o Entity Framework tem sido menos do que estelar. Primeiro, você deve herdar das classes base EF, então diga adeus aos POCOs. Seu design terá que ser em torno da EF. Com o LinqtoSQL, eu poderia usar meus objetos de negócios existentes. Além disso, não há carregamento lento, você deve implementar isso sozinho. Existem algumas soluções para usar POCOs e carregamento lento, mas elas existem no IMHO porque a EF ainda não está pronta. Eu pretendo voltar a ele depois da 4.0

Encontrei uma resposta muito boa aqui, que explica quando usar o que em palavras simples:

A regra básica para qual estrutura usar é como planejar a edição de seus dados em sua camada de apresentação.

• Linq para Sql - use essa estrutura se você planeja editar um relacionamento individual dos seus dados na camada de apresentação. Isso significa que você não planeja combinar dados de mais de uma tabela em qualquer visualização ou página.

• Estrutura de entidades - use essa estrutura se você planeja combinar dados de mais de uma tabela em sua exibição ou página. Para tornar isso mais claro, os termos acima são específicos para os dados que serão manipulados na sua exibição ou página, e não apenas exibidos. Isso é importante para entender.

Com o Entity Framework, você pode "mesclar" os dados apresentados para apresentar à camada de apresentação em um formulário editável e, quando esse formulário for enviado, a EF saberá como atualizar TODOS os dados das várias tabelas.

Provavelmente, existem razões mais precisas para escolher a EF do que o L2S, mas essa provavelmente seria a mais fácil de entender. O L2S não tem a capacidade de mesclar dados para a apresentação da visualização.

Minha impressão é que o seu banco de dados é bastante interessante ou muito mal projetado se o Linq2Sql não atender às suas necessidades. Eu tenho cerca de 10 sites maiores e menores, todos usando o Linq2Sql. Procurei e o Entity framework muitas vezes, mas não consigo encontrar um bom motivo para usá-lo no Linq2Sql. Dito isso, tento usar meus bancos de dados como modelo, para que eu já tenha um mapeamento 1 para 1 entre modelo e banco de dados.

No meu trabalho atual, temos um banco de dados com mais de 200 tabelas. Um banco de dados antigo com muitas soluções ruins, para que eu pudesse ver o benefício do Entity Framework sobre o Linq2Sql, mas ainda assim preferiria redesenhar o banco de dados, pois o banco de dados é o mecanismo do aplicativo e, se o banco de dados for mal projetado e lento, meu aplicativo também será lento. O uso da estrutura Entity em um banco de dados parece uma solução rápida para disfarçar o modelo ruim, mas nunca poderia disfarçar o desempenho ruim que você obtém desse banco de dados.

Você pode encontrar uma boa comparação aqui:

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-between-LINQ-to-SQL-and-Entity-Framework.html

http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1

As respostas aqui abordaram muitas das diferenças entre o Linq2Sql e o EF, mas há um ponto-chave que não recebeu muita atenção: o Linq2Sql suporta apenas o SQL Server, enquanto o EF possui provedores para os seguintes RDBMSs:

Fornecido pela Microsoft:

• ADO.NET drivers para SQL Server, OBDC e OLE DB

Via fornecedores terceirizados:

• MySQL
• Oráculo
• DB2
• VistaDB
• SQLite
• PostgreSQL
• Informix
• U2
• Sybase
• Synergex
• Firebird
• Npgsql

para nomear alguns.

Isso torna a EF uma poderosa abstração de programação em seu armazenamento de dados relacional, o que significa que os desenvolvedores têm um modelo de programação consistente para trabalhar, independentemente do armazenamento de dados subjacente. Isso pode ser muito útil em situações em que você está desenvolvendo um produto que deseja garantir que interoperará com uma ampla variedade de RDBMSs comuns.

Outra situação em que essa abstração é útil é onde você faz parte de uma equipe de desenvolvimento que trabalha com um número de clientes diferentes ou unidades de negócios diferentes dentro de uma organização e deseja melhorar a produtividade do desenvolvedor reduzindo o número de RDBMSs que eles devem se tornar familiarizado para oferecer suporte a uma variedade de aplicativos diferentes, além de diferentes RDBMSs.

Descobri que não podia usar vários bancos de dados dentro do mesmo modelo de banco de dados ao usar o EF. Mas no linq2sql eu poderia apenas prefixando os nomes dos esquemas com os nomes dos bancos de dados.

Essa foi uma das razões pelas quais eu originalmente comecei a trabalhar com o linq2sql. Não sei se a EF ainda permitiu essa funcionalidade, mas lembro-me de ler que se destinava a não permitir isso.

Se seu banco de dados for direto e simples, o LINQ to SQL o fará. Se você precisar de entidades lógicas / abstratas em cima de suas tabelas, vá para o Entity Framework.

Ainda não suporta os tipos de dados exclusivos do SQL 2008. A diferença da minha perspectiva é que a Entity ainda tem a chance de construir um modelo em torno do meu tipo de dados geográficos em alguma versão futura, e o Linq to SQL, sendo abandonado, nunca será.

Pergunto o que há com o nHibernate ou OpenAccess ...

Eu acho que se você precisa desenvolver algo rápido, sem coisas estranhas no meio, e precisa da facilidade de ter entidades representando suas tabelas:

O Linq2Sql pode ser um bom aliado, usá-lo com o LinQ desencadeia um ótimo momento de desenvolvimento.

Estou trabalhando para um cliente que possui um grande projeto que está usando o Linq-to-SQL. Quando o projeto foi iniciado, era a escolha óbvia, porque o Entity Framework estava ausente de alguns dos principais recursos da época e o desempenho do Linq-to-SQL era muito melhor.

Agora, a EF evoluiu e o Linq-to-SQL não possui suporte assíncrono, o que é ótimo para serviços altamente escalonáveis. Às vezes, temos mais de 100 solicitações por segundo e, apesar de otimizarmos nossos bancos de dados, a maioria das consultas ainda leva vários milissegundos para ser concluída. Devido às chamadas síncronas do banco de dados, o encadeamento está bloqueado e não está disponível para outras solicitações.

Estamos pensando em mudar para o Entity Framework, exclusivamente para esse recurso. É uma pena que a Microsoft não tenha implementado o suporte assíncrono no Linq-to-SQL (ou de código aberto, para que a comunidade possa fazê-lo).

Adendo dezembro de 2018: A Microsoft está migrando para o .NET Core e o Linq-2-SQL não é compatível com o .NET Core; portanto, você precisa migrar para o EF para garantir a migração para o EF.Core no futuro.

Também há outras opções a serem consideradas, como o LLBLGen . É uma solução ORM madura que já existe há muito tempo e foi comprovada como mais à prova do futuro do que as soluções de dados da MS (ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.core).

Linq para SQL

É o provedor que suporta apenas o SQL Server. É uma tecnologia de mapeamento para mapear tabelas de banco de dados do SQL Server para objetos .NET. É a primeira tentativa da Microsoft em um ORM - Mapeador Relacional a Objetos.

Linq para Entidades

É a mesma ideia, mas usando o Entity Framework em segundo plano, como o ORM - novamente da Microsoft, ele oferece suporte a várias vantagens do banco de dados.

De acordo com minha experiência pessoal, Ef é melhor (se você não tem idéia sobre SQL) o desempenho no LINQ é um pouco mais rápido do que na linguagem LINQ da EF, escrita em lambda.