Entity Framework vs LINQ para SQL

828

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?

.net entity-framework linq-to-sql

— Chris Roberts
fonte

138

Penso que as respostas abaixo devem ser reexaminadas porque há muito tempo desde o lançamento da EF, para que os novos desenvolvedores que chegarem aqui possam ter uma impressão errada. A EF tornou-se uma ferramenta GRANDE e FÁCIL desde seu lançamento inicial. Você acabou de configurar a conexão com o banco de dados e isso representa 90% de tudo o que você precisa. Desenvolvimento muito rápido, do ponto de vista experiente! A partir daí - LINQ é seu melhor amigo. É altamente personalizável, o MVC simplesmente adora e para as pessoas que dizem que é ruim - Aprenda a usá-lo primeiro (e se apóie no LINQ também)!

— graumanoz

10

Só para ficar claro - não é como se você tivesse escolha agora - a MSFT efetivamente matou o LINQ2SQL em favor da EF. No entanto, o fato de o MSFT open-source EF ter ajudado a sugar menos e está definitivamente melhorando. Mas para qualquer um que entrar na EF - não deixe de entender que ainda existem muitas peculiaridades na EF. Eu postei sobre um - stackoverflow.com/questions/305092/…

— nikib3ro

4

@ kape123, (a) LINQ to SQL não está "morto"; ainda é utilizável; (b) LINQ to SQL é o método padrão de acesso a dados no desenvolvimento do Windows Phone 8.

— Ryan Lundy

9

@ user3308043, [citação necessária].

— Ryan Lundy

3

@Kyralessa - A partir de 2010 (com o lançamento do .NET4.0, a citação mais recente que pude encontrar), a MS reconheceu que , embora algum investimento possa ser feito no LINQ2SQL ", a maior parte do investimento geral estará na Entidade Estrutura."

— kmote

483

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

— Kris
fonte

parece que você usa LINQ to SQL para consultar na EF

— PositiveGuy

11

@CoffeeAddict Embora tenham estilo muito semelhante ao uso de lambdas LINQ, cada API tem bases completamente diferentes. Por exemplo, a maneira LINQ2SQL gera consultas SQL permite o uso de funções SQL, enquanto L2E não, ou pelo menos não o fez a partir de 2008.

— Kris

2

A abordagem orientada a objetos da EF torna muito fácil e conveniente o uso, pode ser codificada muito rapidamente, gerenciada. Para mim, apenas a melhor maneira de acessar dados.

— Antoine Pelletier

10

Esta resposta é obsoleta. Agora LINQ to SQL suporta mapeamento one2many

— George Lanetz

201

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.

— Brad Tutterow
fonte

32

Você também tenderá a escrever menos linhas de código com L2S para realizar a mesma coisa que faria com a EF. Nenhum carregamento lento no EF significa que você está sempre verificando se algo foi carregado ou não.

— 21715 Paul Mendoza

Brad, o que você sugeriria para um site de comércio eletrônico? Quer dizer, eu não posso ver nada que não seja CRUDs simples acontecendo lá ...

— PositiveGuy

2

@CoffeeAddict obviamente, o top 3 das respostas mais votadas diz L2S para CRUD simples

— IsmailS

11

@ Banford Com EF no .NET 4.0, acho que é melhor que o L2S. Os recursos que estavam faltando no EF na 3.5 que o L2S havia sido adicionado ao EF no .NET 4.0. Suas instruções LINQ agora no EF no .NET 4.0 terão a mesma aparência das do L2S. A EF oferece algumas coisas extras que você pode fazer agora, além do que o L2S oferece.

— Paul Mendoza

40

Esta resposta está agora com 5 anos e está desatualizada. Entidade Quadro 6 está agora no beta e é muito melhorado, inclui preguiçoso carregamento, o apoio enum, etc, etc

— Tim

109

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.

— Zack Peterson
fonte

56

Na verdade, não gostamos da EF porque ela tem um designer tão ruim e é extremamente, extremamente buggy. Eu nunca achei que fosse tão complexo assim.

— BlueRaja - Danny Pflughoeft

12

Muitos dos principais sites de comércio eletrônico usam o LINQ to SQL. Exemplos: Redbox, Stackoverflow, etc.

— PositiveGuy

14

Conheço muitos bons desenvolvedores que usam LINQ to SQL e dizem que esses artigos são totalmente exagerados. Concordo. O LINQ to SQL foi usado em poderosos .coms e ainda é.

— PositiveGuy

4

Sim, chamar .ToString () em uma propriedade inteira em uma consulta L2EF não deve causar uma exceção.

— StingyJack

3

@ BlueRaja-DannyPflughoeft Ainda é verdade depois de mais de 5 anos?

— Vikas Rana

94

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.

— JamesSugrue
fonte

13

Sua cotação "L2S funcionará apenas com o SQL Server (tanto quanto eu sei)" precisa ser atualizada: o projeto de código aberto "dblinq" substitui o assembly LINQ to SQL por um que possa falar com MySQL, PostgreSQL, Ingres, Firebird, SQLite. .. e Microsoft SQL (é claro).

— Contango

1

espere ... para que o EF não crie objetos DL fortemente acoplados?

— PositiveGuy

7

sim, a premissa original de que o L2S não é uma solução capaz da empresa não é mais verdadeira. Quero dizer, o StackOverflow é executado no L2S e em vários outros .coms, como o Redbox, e muitos outros.

— PositiveGuy

74

LINQ para SQL

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

Estrutura de entidade

Fonte de dados Heterogeneus: Suporte a muitos provedores de dados
Recomendado para todos os novos projetos, exceto:
- pequenos (LINQ to SQL)
- quando a fonte de dados é um arquivo simples (ADO.NET)
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
.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)
Mapeamentos um para um, um para muitos e muitos para um entre tabelas e classes
Suporta herança:
- TPH (tabela por hierarquia)
- TPT (tabela por tipo)
- TPC (tabela por classe de concreto)
Suporta tipos complexos
Abordagens de código primeiro, modelo primeiro e armazenamento primeiro
Visualização centrada no aplicativo de um banco de dados
Criado pela equipe do SQL Server
Futuro das APIs de dados da Microsoft

Veja também:

— Ryszard Dżegan
fonte

6

Essa é a resposta mais atual e detalhada.

— ErTR 16/03/16

2

O Entity Framework não usa LINQ to SQL quando, digamos, você está escrevendo um dbSet<Orders>.Where()...ToList()? Eu acho que é enganoso ter o Entity Framework contrário ao LINQ e ao SQL.

— Don Cheadle

4

O @mmcrae EF não usa L2S, ambos são fornecedores de linq para bancos de dados subjacentes. Se você interpretá-lo como Linq para um banco de dados, semelhante ao linq para objetos e linq para xml, sim, ambos são semelhantes no linq para um banco de dados. Mas não, a EF não usa L2S (ou vice-versa). Duas ferramentas completamente separadas.

— Maarten

4

"Recomendado para todos os novos projetos, exceto ... pequenos", eu discordo. O Code First é uma maneira extremamente rápida de atingir o chão com pequenos projetos. Fora isso, ótima atualização para esta pergunta.

— precisa saber é o seguinte

51

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

— Jiyosub
fonte

7

A falta de suporte ao POCO é a principal razão pela qual escolhi o LINQ to SQL sobre o Entity Framework. Posso revisitar a EF quando a incorporar na próxima versão, como prometem. Existem alguns projetos adicionais por aí que realizam POCOs para a EF, mas não o suficiente.

— 31410 Joseph Ferris

27

No caso de alguém (como eu) não sabe o que POCO significa: Plain Old CLR Objeto

— CBono

4

Realmente não vejo qual é o grande problema de não apoiar POCOs ... é mais um nível de abstração. Crie uma fábrica, injetando o repositório de dados e construa seus POCOs lá. Provavelmente é uma boa ideia de qualquer maneira.

— EightyOne Unite

3

Eu ouvi dizer que POCO é possível no EF 4

— PositiveGuy

8

Apoio POCO está disponível nos dias de hoje e herança não é mais um requisito para classes de entidade @CoffeeAddict POCO é apenas um objeto simples, sem dependência de um quadro específico e é uma parte importante de modernos padrões de estrutura de entidade

— Chris McGrath

46

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.

— Nawaz
fonte

36

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.

— terjetil
fonte

1

Você está perdendo o objetivo - mesmo com bancos de dados pequenos, você pode querer algo diferente de um relacionamento 1: 1 entre tabelas de banco de dados e objetos de código / domínio. Depende apenas de quanta abstração você deseja nos objetos de barramento / domínio.

— alquimico,

18

Eu percebi isso :) Hoje, eu gosto de codificar manualmente minhas entidades comerciais. Ainda uso o Linq2sql, mas apenas dentro de meus repositórios, onde obtenho dados usando o Linq2sql e converto as entidades linq2sql em minhas entidades comerciais personalizadas. Talvez um pouco mais de trabalho do que usar um mapeador de or, mas ainda gosto de manter minha camada de negócios livre de qualquer código específico do mapeador de OR.

— terjetyl

25

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

— Omer K
fonte

2

Algumas coisas na resposta não estão corretas. Um EDMX não é necessário se você usar o Code First. E eu não entendo como o DI entra em jogo quando você está usando o Code First.

— Maarten

1

Além disso, o Linq to SQL pode preencher um banco de dados das classes de modelo muito bem. Não tenho certeza se ele também pode gerar o próprio banco de dados, mas a geração do esquema e das tabelas se enquadra nos recursos do Linq to SQL.

— Tom16

Obrigado pela resposta, eu acho que o pode-se usar sqlmetal.exe docs.microsoft.com/en-us/dotnet/framework/tools/... para gerar o código / mapeamento do banco de dados ao usarLinq to SQL

— Vinod Srivastav

23

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.

— veleiro
fonte

15

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.

— Banford
fonte

12

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.

— vintana
fonte

4

O Entity Framework permite uma camada de abstração da parte superior do banco de dados. O problema com muitos mapeadores OR hoje (na minha opinião) é que eles fornecem um mapeamento 1 para 1 entre tabelas e classes. O modelo de banco de dados nem sempre reflete a maneira como pensamos sobre ele em termos de modelo de negócios.

— senfo 02/10/08

Acabou o espaço. De qualquer forma, com base no que disse acima, argumentaria que sua resposta não está completa.

— senfo 02/10/08

7

Eu acho que esse é um péssimo conselho. O L2S é bom, independentemente da simplicidade ou complexidade do seu banco de dados. A verdadeira armadilha é não ter uma separação adequada de preocupações. Se você tentar mesclar sua camada de negócios e sua camada de acesso a dados e usar seus objetos Linqed up para tudo, encontrará o L2S limitante. Mas isso é um problema com um design excessivamente simplista e monolítico. O L2S faz um ótimo DAL e, se você considerar a consulta e a persistência uma preocupação separada das regras de negócios, você economizará muitos problemas em muitas áreas a longo prazo.

— mattmc3

1

isso não me diz nada. O que é simples nos seus termos?

— PositiveGuy

1

e o que você quer dizer como exemplo para a necessidade de "lógico / abstraído". Sim, eu sei o que é abstração, mas um exemplo em seu contexto, por favor ... para me explicar exatamente o que você está dizendo ... descreva, não me dê apenas gírias gerais ... isso é tudo relativo ao orador dizendo essas palavras, então eu não tenho idéia do que você quer dizer com isso.

— PositiveGuy

8

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 ...

— John Dunagan
fonte

3

Tipos de dados espaciais do SQL Server 2008 (Open Geospatial Consortium OGS) suportados a partir do Entity Framework 5. Outros provedores (Devart for Oracle) também são suportados. Consulte msdn.microsoft.com/en-us/data/dn194325 .

— subsci

6

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.

— MRFerocius
fonte

4

"sem coisas estranhas no meio", ok, o que você quer dizer com isso. Exemplo de uma "coisa estranha no meio"

— PositiveGuy

Seria bom editar ou excluir esta resposta, não é mais útil para o desenvolvimento moderno e pode colocar as pessoas no caminho errado.

— Giulio Caccin

6

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).

— Ramon de Klein
fonte

2

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.

— Umang Patwa
fonte