Entity Framework versus LINQ to SQL
https://stackoverflow.com/questions/8676
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Agora que o .NET v3.5 SP1 foi lançado (junto com o VS2008 SP1), agora temos acesso à estrutura de entidade .NET.
Minha pergunta é esta.Ao tentar decidir entre usar o Entity Framework e o LINQ to SQL como ORM, qual é a diferença?
Pelo que entendi, o Entity Framework (quando usado com LINQ to Entities) é um 'irmão mais velho' do LINQ to SQL?Se for esse o caso, quais são as vantagens disso?O que ele pode fazer que o LINQ to SQL não consegue fazer sozinho?
Solução
LINQ to SQL oferece suporte apenas ao mapeamento 1 para 1 de tabelas de banco de dados, visualizações, sprocs e funções disponíveis no Microsoft SQL Server.É uma ótima API para construção de acesso rápido a dados em bancos de dados SQL Server relativamente bem projetados.LINQ2SQL foi lançado pela primeira vez com C# 3.0 e .Net Framework 3.5.
LINQ to Entities (ADO.Net Entity Framework) é uma API ORM (Object Relational Mapper) que permite uma definição ampla de modelos de domínio de objeto e seus relacionamentos com muitos provedores de dados ADO.Net diferentes.Dessa forma, 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.ADO.Net Framework foi lançado com o .Net Framework 3.5 SP1.
Este é um bom artigo introdutório ao MSDN:Apresentando LINQ para dados relacionais
Outras dicas
Acho que a resposta rápida e suja é essa
- LINQ to SQL é a maneira rápida e fácil de fazer isso.Isso significa que você avançará mais rápido e entregará mais rápido se estiver trabalhando em algo menor.
- Entity Framework é a maneira completa e sem barreiras de fazer isso.Isso significa que você levará mais tempo no início, 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 para SQL] como algo que "nunca deveria existir". Essencialmente, deveria ser apenas 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.Ele foi concluído a tempo para o infelizmente chamado ".NET 3.5 Service Pack 1", que mais parecia um lançamento principal do que um service pack.
...
Os desenvolvedores não gostam do [ADO.NET Entity Framework] por causa da complexidade.
...
a partir do .NET 4.0, o LINQ to Entities será a solução de acesso a dados recomendada para o LINQ to cenários relacionais.
Há uma série de diferenças óbvias descritas no artigo postado por @lars, mas a resposta curta é:
- L2S é fortemente acoplado - propriedade do objeto para um campo específico do banco de dados ou, mais corretamente, mapeamento de objeto para um esquema de banco de dados específico
- L2S só funcionará com SQL Server (até onde eu sei)
- EF permite mapear uma única classe para múltiplas tabelas
- EF cuidará de relacionamentos M-M
- A EF poderá atingir qualquer provedor de dados ADO.NET
A premissa original era que L2S é para desenvolvimento rápido e EF para aplicativos de n camadas mais "empresariais", mas isso está vendendo o L2S um pouco aquém.
LINQ para SQL
- Fonte de dados homogênea:servidor SQL
- Recomendado apenas para pequenos projetos onde a estrutura de dados é bem projetada
- O mapeamento pode ser alterado sem recompilar com SqlMetal.exe
- .dbml (linguagem de marcação de banco de dados)
- Mapeamento um-para-um entre tabelas e classes
- Apoia TPH herança
- Não suporta tipos complexos
- Abordagem que prioriza o armazenamento
- Visão centrada em banco de dados de um banco de dados
- Criado pela equipe C#
- Melhorias suportadas, mas não pretendidas
Estrutura de entidade
- Fonte de dados heterogênea: Apoie 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 o modelo e os arquivos de mapeamento Processo de artefato de metadados para copiar para o diretório de saída
- .edmx (modelo de dados de entidade) que contém:
- SSDL (linguagem de definição de esquema de armazenamento)
- CSDL (linguagem de definição de esquema conceitual)
- MSL (linguagem de especificação de mapeamento)
- Mapeamentos um-para-um, um-para-muitos, 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 que priorizam o código, o modelo e o armazenamento
- Visão centrada em aplicativos de um banco de dados
- Criado pela equipe do SQL Server
- Futuro das APIs de dados da Microsoft
Veja também:
Minha experiência com o Entity Framework não foi nada excelente.Primeiro, você precisa herdar das classes base do EF, então diga adeus aos POCOs.Seu design terá que estar em torno do EF.Com o LinqtoSQL eu poderia usar meus objetos de negócios existentes.Além disso, não há carregamento lento; você mesmo deve implementá-lo.Existem algumas soluções alternativas para usar POCOs e carregamento lento, mas elas existem IMHO porque o EF ainda não está pronto.Pretendo voltar depois do 4.0
encontrei uma resposta muito boa aqui que explica quando usar o quê em palavras simples:
A regra geral 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 de seus dados em sua camada de apresentação.Significando que você não planeja combinar dados de mais de uma tabela em qualquer visualização ou página.
Estrutura de entidade - Use essa estrutura se você planeja combinar dados de mais de uma tabela em sua visualização ou página.Para tornar isso mais claro, os termos acima são específicos para dados que serão manipulados em sua visualização ou página, não apenas exibidos.Isso é importante para entender.
Com a estrutura da entidade, você pode "mesclar" entregar dados 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 em vez de L2s, mas provavelmente seria a mais fácil de entender.L2S não tem a capacidade de mesclar dados para exibir a apresentação.
Minha impressão é que seu banco de dados é muito grande ou muito mal projetado se o Linq2Sql não atender às suas necessidades.Tenho cerca de 10 sites maiores e menores, todos usando Linq2Sql.Procurei 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, então já tenho 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, então pude ver os benefícios do Entity Framework em relação ao 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, então meu aplicativo também será lento.Usar a estrutura Entity em tal banco de dados parece uma solução rápida para disfarçar o modelo ruim, mas nunca poderia disfarçar o mau desempenho obtido com esse banco de dados.
As respostas aqui cobriram muitas das diferenças entre Linq2Sql e EF, mas há um ponto chave que não recebeu muita atenção:Linq2Sql suporta apenas SQL Server, enquanto EF possui provedores para os seguintes RDBMSs:
Fornecido pela Microsoft:
- Drivers ADO.NET para SQL Server, OBDC e OLE DB
Através de fornecedores terceirizados:
- MySQL
- Oráculo
- DB2
- VistaDB
- SQLite
- PostgreSQL
- Informix
- U2
- Sybase
- Sinergex
- Pássaro de Fogo
- Npgsql
para nomear alguns.
Isso torna o EF uma abstração de programação poderosa sobre 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 irá interoperar com uma ampla variedade de RDBMSs comuns.
Outra situação em que essa abstração é útil é quando você faz parte de uma equipe de desenvolvimento que trabalha com vários clientes diferentes ou com diferentes unidades de negócios dentro de uma organização e deseja melhorar a produtividade do desenvolvedor reduzindo o número de RDBMSs que eles precisam se tornar. familiarizado para suportar uma variedade de aplicações diferentes em diferentes RDBMSs.
Descobri que não poderia usar vários bancos de dados no mesmo modelo de banco de dados ao usar o EF.Mas no linq2sql eu poderia apenas prefixar os nomes dos esquemas com nomes de bancos de dados.
Esta foi uma das razões pelas quais comecei a trabalhar originalmente com linq2sql.Não sei se a EF ainda permitiu essa funcionalidade, mas lembro de ter lido que era para ela não permitir isso.
Se o seu banco de dados for direto e simples, o LINQ to SQL servirá.Se você precisar de entidades lógicas/abstratas em cima de suas tabelas, vá para o Entity Framework.
Nenhum dos dois ainda oferece suporte aos tipos de dados exclusivos do SQL 2008.A diferença da minha perspectiva é que Entity ainda tem a chance de construir um modelo em torno do meu tipo de dados geográfico em alguma versão futura, e o Linq to SQL, sendo abandonado, nunca o fará.
Gostaria de saber o que há com 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:
Linq2Sql pode ser um bom aliado, usá-lo com LinQ libera um ótimo timing de desenvolvimento.
Estou trabalhando para um cliente que tem um grande projeto que usa Linq-to-SQL.Quando o projeto começou, era a escolha óbvia, porque faltavam alguns recursos importantes no Entity Framework naquela época e o desempenho do Linq-to-SQL era muito melhor.
Agora o EF evoluiu e o Linq-to-SQL carece de suporte assíncrono, o que é ótimo para serviços altamente escaláveis.Às vezes, temos mais de 100 solicitações por segundo e, apesar de termos otimizado nossos bancos de dados, a maioria das consultas ainda leva vários milissegundos para ser concluída.Devido às chamadas síncronas ao banco de dados, o thread está bloqueado e não está disponível para outras solicitações.
Estamos pensando em mudar para o Entity Framework, apenas para esse recurso.É uma pena que a Microsoft não tenha implementado suporte assíncrono no Linq-to-SQL (ou o tenha aberto, para que a comunidade pudesse fazê-lo).
Adendo de dezembro de 2018: A Microsoft está migrando para o .NET Core e o Linq-2-SQL não é compatível com o .NET Core, então você precisa migrar para o EF para garantir que poderá migrar para o EF.Core no futuro.
Existem também algumas outras opções a serem consideradas, como LLBLGen.É uma solução ORM madura que já existe há muito tempo e foi comprovadamente mais preparada para o futuro do que as soluções de dados MS (ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.core).
O LINQ to SQL e o Entity Framework parecem semelhantes superficialmente.Ambos fornecem consultas do LINQ contra um banco de dados usando um modelo de dados.
O LINQ para SQL evoluiu do projeto LINQ, que saiu da equipe trabalhando com o desenvolvimento do idioma. Enquanto a estrutura da entidade era um projeto da equipe de programação de dados e estava focada no idioma da entidade SQL.A Microsoft não tem nenhuma intenção de desvalorizar o LINQ to SQL.
LINQ to SQL ainda faz parte do ADO.NET, enquanto o Entity Framework possui uma API separada.A estrutura de entidade é a versão superior do LINQ to SQL. A estrutura de entidade usa o modelo de dados de entidade para fazer a ponte entre seu aplicativo e seu armazenamento de dados.É o Modelo de Dados de Entidade, ou EDM, que fornece a definição do seu esquema conceitual, bem como as informações do esquema do banco de dados necessárias para interagir com o banco de dados e, finalmente, um esquema de mapeamento que vincula os dois.
Aqui estão algumas tarefas executadas pelo Entity Framework (modelo de dados de entidade).
• Gera automaticamente as classes do modelo e atualiza essas classes dinamicamente sempre que o modelo mudar.
• Cuida de toda a conectividade do banco de dados para que os desenvolvedores não fiquem sobrecarregados por terem que escrever muitos códigos para interagir com o banco de dados.
• Fornece sintaxe de consulta comum para consultar o modelo, não o banco de dados, e então traduz essas consultas em consultas que o banco de dados possa compreender.
• Fornece um mecanismo para rastrear alterações nos objetos do modelo, pois eles estão sendo usados nos aplicativos e lida com as atualizações no banco de dados.
Linq para SQL
É um provedor que oferece suporte apenas ao SQL Server.É uma tecnologia de mapeamento para mapear tabelas de banco de dados SQL Server para objetos .NET.É a primeira tentativa da Microsoft de um ORM - Object-Relational Mapper.
Linq para entidades
É a mesma ideia, mas usar o Entity Framework em segundo plano, como o ORM - novamente da Microsoft. A principal vantagem do suporte a vários bancos de dados do Entity Framework é que o desenvolvedor pode trabalhar em qualquer banco de dados, sem necessidade de aprender sintaxe para executar qualquer operação em diferentes bancos de dados diferentes.
De acordo com minha experiência pessoal, o EF é melhor (se você não tem idéia do SQL), o desempenho do LINQ é um pouco mais rápido, conforme comparado à linguagem LinQ eF, escrita em Lambda.
