none
Linq to SQL e Linq to Entities RRS feed

  • Pergunta

  •  A diferença mais óbvia é a que o Linq to SQL é voltado apenas para o SQL Server e o Linq to Entities é mais flexível, já que está ligado ao ADO.NET Entity Framework .então vem as duvidas...

    o Linq to Entities pode ser usado com o ADO que estamos usando no C# 2.0 ? se no futuro a microsoft mudar o ADO.NET Entity Framework .para ANOTHER-ADO  vou ter que ficar revendo meus conceitos de Linq to Entities para que este fique compativel com outro ADO de novo? seria possivel eu usar o Linq to Entities  de forma a utilizar o minimo de ADO.NET Entity Framework para evitar esses contratempos?

    terça-feira, 3 de julho de 2007 03:43

Respostas

  • Oi !

     

    Bem, vamos por partes...

     

    Vamos primeiro corrigir a afirmação inicial...

     

    1) Linq to SQL - ou DLINQ - refere-se a uma conversão da síntaxe de escrita do linq para linguagem SQL - o que não significa especificamente o servidor SQL Server. Portanto o DLINQ pode estar acessando qualquer servidor - apesar de isso não estar claro nas documentações atuais. Simplesmente dúvido que a MS seja biruta o suficiente para ignorar outros bancos.  Ela irá, no mínimo, criar um sistema de providers semelhante a muitos outros que já existem no .NET

     

    A) Então surge a pergunta natural - qual a diferença do DLINQ para o Entity Framework ? Enquanto o DLINQ é mapeado diretamente para tabelas de banco, o Entity Framework nos permite criar um modelo de objetos baseados nas tabelas de banco. Através do Entity Framework podemos criar uma classe cliente e dizer que os dados de cliente vem da tabela clientes mas também da tabela pessoas. As querys serão feitas sobre o resultado do Entity Framework - uma classe cliente - e o entity framework irá mapear isso para o modelo relacional.

     

    2) Não, não pode. O linq depende de recursos de linguagem que foram adicionados nas novas versões, C# 3.0 e VB.NET 9

     

    3) Pergunta difícil e especulativa... vamos analisar... Desde a versão 1.0 do framework, os fundamentos básicos do framework (CLR, BCL, linguagens, IL, etc) não mudaram. Ou seja, algumas tecnologias começam a ficar tão maduras que se tornam estáticas. Entre o framework 1.1 e o 2.0 houve um salto radical de produtividade, realmente. Mas a migração do 1.1 para o 2.0 foi uma migração extremamente simples. Para o 3.0, ocorreu apenas uma inclusão de 4 elementos no framework. Apenas as tecnologias mais avançadas (distribuição de dados) sofrera mudanças, o resto se tornou uma questão de usar ou não usar os novos elementos adicionados. Agora com o framework 3.5 o linq vai conviver com o ADO.NET. Quem gosta de mapeamento objeto relacional vai usar o linq, quem não gosta vai continuar com o ADO.NET. O que quero mostrar com isso é que as evoluções de versão encontram-se cada vez mais suaves e acredito que mudanças altamente radicais não venham a acontecer sem, pelo menos, haver grandes recursos de migração disponíveis.

     

    4) Não tem sentido. O linq to entities depende do ADO.NET Entity framework para fazer o mapeamento. Parece que você confundiu DLINQ com algo especifico para SQL  e linq to entities com algo disponível para outros bancos. Mas a diferença não é essa não.

     

    []'s

     

     

    terça-feira, 3 de julho de 2007 06:24

Todas as Respostas

  • Oi !

     

    Bem, vamos por partes...

     

    Vamos primeiro corrigir a afirmação inicial...

     

    1) Linq to SQL - ou DLINQ - refere-se a uma conversão da síntaxe de escrita do linq para linguagem SQL - o que não significa especificamente o servidor SQL Server. Portanto o DLINQ pode estar acessando qualquer servidor - apesar de isso não estar claro nas documentações atuais. Simplesmente dúvido que a MS seja biruta o suficiente para ignorar outros bancos.  Ela irá, no mínimo, criar um sistema de providers semelhante a muitos outros que já existem no .NET

     

    A) Então surge a pergunta natural - qual a diferença do DLINQ para o Entity Framework ? Enquanto o DLINQ é mapeado diretamente para tabelas de banco, o Entity Framework nos permite criar um modelo de objetos baseados nas tabelas de banco. Através do Entity Framework podemos criar uma classe cliente e dizer que os dados de cliente vem da tabela clientes mas também da tabela pessoas. As querys serão feitas sobre o resultado do Entity Framework - uma classe cliente - e o entity framework irá mapear isso para o modelo relacional.

     

    2) Não, não pode. O linq depende de recursos de linguagem que foram adicionados nas novas versões, C# 3.0 e VB.NET 9

     

    3) Pergunta difícil e especulativa... vamos analisar... Desde a versão 1.0 do framework, os fundamentos básicos do framework (CLR, BCL, linguagens, IL, etc) não mudaram. Ou seja, algumas tecnologias começam a ficar tão maduras que se tornam estáticas. Entre o framework 1.1 e o 2.0 houve um salto radical de produtividade, realmente. Mas a migração do 1.1 para o 2.0 foi uma migração extremamente simples. Para o 3.0, ocorreu apenas uma inclusão de 4 elementos no framework. Apenas as tecnologias mais avançadas (distribuição de dados) sofrera mudanças, o resto se tornou uma questão de usar ou não usar os novos elementos adicionados. Agora com o framework 3.5 o linq vai conviver com o ADO.NET. Quem gosta de mapeamento objeto relacional vai usar o linq, quem não gosta vai continuar com o ADO.NET. O que quero mostrar com isso é que as evoluções de versão encontram-se cada vez mais suaves e acredito que mudanças altamente radicais não venham a acontecer sem, pelo menos, haver grandes recursos de migração disponíveis.

     

    4) Não tem sentido. O linq to entities depende do ADO.NET Entity framework para fazer o mapeamento. Parece que você confundiu DLINQ com algo especifico para SQL  e linq to entities com algo disponível para outros bancos. Mas a diferença não é essa não.

     

    []'s

     

     

    terça-feira, 3 de julho de 2007 06:24
  • Dennes,

     

    O Linq to SQL é específico para realizar o mapeamento para o SQL Server. Você não vai conseguir fazer o mapeamento com outro banco. Quanto a sintaxe que ele gera na tradução da query, aí tudo bem.

    sexta-feira, 6 de julho de 2007 13:04
    Moderador
  • Oi !

     

    Quando você fala Linq to SQL está falando do DLINQ, certo ?

     

    Sim, no atual momento eu percebi.

     

    Mas você está certo de que não existem planos de montar a arquitetura como uma arquitetura de providers ou algo semelhante ? Porque limitar um recurso poderoso como o linq apenas ao sql server é... digamos... estranho...

     

    []'s

     

     

    sexta-feira, 6 de julho de 2007 13:28
  • Oi Dennes,

     

    Concordo, só que não será o Linq to SQL (DLinq era a denominação antiga) que proverá isso e sim o Linq to Entities + ADO.NET Entity Framework, que por sinal não será lançado com o Visual Studio 2008. Então, ainda vamos esperar um pouco para usar esses recursos com outros bancos de forma efetiva.

    sexta-feira, 6 de julho de 2007 13:35
    Moderador
  • Oi, Leo !

     

    Acho isso muito estranho....

     

    Linq to SQL - DLINQ - tem um objetivo : Fazer o acesso direto ao banco. Lembro inclusive de ter visto wizards para isso. Já o Entity Framework tem outro objetivo - Permitir o mapeamento do modelo relacional para um modelo de objetos, sem que o acesso seja direto a tabelas, como aconteceria com o DLINQ.

     

    A impressão que eu tenho (e estou falando de impressões e não informações) é de que com objetivos diferentes e métodos de trabalho diferentes ambos deveriam ter sua forma de "providers" para conexão a mais de um tipo de banco de dados....

     

    Achei muito estranho estes pontos...

     

    Uma pergunta pessoal : Eu tinha a impressão que você morava em Niterói ? Isso era verdade, ou quem sabe, ainda é ?

     

    Se ainda é, me escreve um e-mail (dennes@bufaloinfo.com.br), vamos agitar mais a comunidade aqui do Rio, afinal, eu também sou de Niterói.

     

    []'s

     

    sexta-feira, 6 de julho de 2007 20:23
  • Oi Dennes,

     

    A sua impressão está na direção certa, mas é que o Entity Framework através do EntityClient (qualquer semelhança com o SqlClient, OledbClient, etc não é mera coincidência) fará exatamente isso, não acessará direto ao banco e sim a um modelo que foi criado com base no modelo relacional (como vc mesmo disse) e você poderá usar uma linguagem propria, o Entity SQL ou o proprio Linq para realizar a queries.

     

    Quanto a pergunta, eu não moro em Niteroi, moro em Fortaleza-CE.

     

    Abraço,

    sábado, 7 de julho de 2007 13:30
    Moderador
  • Oi Leornardo,

     

    O DLinq dará suporte sim a outros databases, atualmente ele funciona apenas com SQL Server, porém o time do Linq está trabalhando num modelo de Provider que permitirá outros fabricantes fornecer a implementação para o seus bancos de dados.

     

    Segundo o Project Manager do Linq, a dificuldade de dar suporte ao Oracle e outros bancos de dados é que não há nenhum DB realmente SQL-ANSI e mesmo que tivesse, vários bancos tem recursos específicos que deve ter tratado pelo próprio fabricante. O post dele pode ser lido em: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=324513&SiteID=1

     

    Sobre o ADO Entity Framework, ele tá prometendo demais, porém não será lançado com o Orcas e deve ser lançado só no meio de 2008. Ainda assim, com algumas limitações que só serão implantadas num segundo release. Talvez em 2009 ??

     

    Publiquei dois posts sobre isso:

    Entity Framework: Só depois do Orcas: http://andrediasbr.blogspot.com/2007/07/entity-framework-s-depois-do-orcas.html

    Um pouco mais sobre ADO Entity Framework: http://andrediasbr.blogspot.com/2007/07/um-pouco-mais-sobre-ado-entity.html

     

    Abraços

    André

     

    sábado, 7 de julho de 2007 17:52
  • Oi André, blz?

     

    Veja só, estes posts já tem mais de um ano, e nesse período ocorreram alteracoes e encontros (um deles no TechEd http://blogs.msdn.com/adonet/archive/2007/06/15/database-vendors-discuss-the-entity-framework-and-linq-at-teched.aspx) entre a Microsoft e empresas que desenvolvem DB´s como IBM e Oracle.

    Bem, assim como o Dennes também disse, o Linq to SQL tem uma arquitetura que pode ser plugável a qualquer provider que forneça essa integração, prova disso é o objeto DataContext que aceita uma classe que implemente a interface IDbConnection, mas isso não é um esforço central da Microsoft (ao que parece) e sim de terceiros (prover esses providers), e muito provavelmente essa possibilidade seja apenas para o EF e o Linq to SQL fique voltado para o SQL Server.

     

    Segundo palavras do Matt Warren (Microsoft product manager for LINQ to SQL) em 12/04/2007:

     

    "LINQ to SQL actually stands for LINQ to 'databases that use SQL' or in other words LINQ for the relational data model. LINQ to Entities means LINQ for the Entity-Data-Model which is a kind of a relational++ model."

     

    Segundo Mike Pizzo (Architect, Data Programmability) em 28/04/2007:

     

    "What is the difference between LINQ to SQL and LINQ to Entities?

    LINQ to SQL supports rapid development of applications that query Microsoft SQL Server databases using objects that map directly to SQL Server schemas.  LINQ to Entities supports more flexible mapping of objects to Microsoft SQL Server and other relational databases through extended ADO.NET Data Providers."

     

    ...

     

    "If you do not require any of these features, LINQ to SQL may provide a simpler solution for rapid development. LINQ to SQL is targeted at rapid-development scenarios against Microsoft SQL Server and provides a simpler approach and richer design experience in the Orcas timeframe for applications with data classes that map directly to the schema of your Microsoft SQL Server database.

    Microsoft is defining a migration plan for customers that start with LINQ to SQL and require additional functionality, such as richer mapping capabilities or access to other stores, to migrate to the ADO.NET Entity Framework."

     

    Para ver o anuncio original, ver o link: http://blogs.msdn.com/data/archive/2007/04/28/microsoft-s-data-access-strategy.aspx

     

    Com base nos posts em blogs do time, materias, alem de algumas conversas com pessoas do time de Linq, pude perceber que embora a arquitetura do Linq to SQL permita acesso a outros BDs, a direcao do vento aponta que isso seja feito via EF. Mas como estamos na versao Beta1, algo pode mudar.

     

    Abraco, e vamos continuar ligados e trocando informacoes.

     

     

    domingo, 8 de julho de 2007 04:56
    Moderador
  •  

    Possoal, a proposta do LINQ é unificar a forma de se acessar fontes de informação, certo? Então se trabalharmos com SQL Server de uma forma totalmente diferente da forma que vamos trabalhar com outros SGBDs não estaremos fugindo da idéia de padronização de acessos às diversas fontes como objetos em memória, bancos de dados relacionais e arquivos XML?

     

    A Microsoft, assim, não estaria se distanciando dessa padronização?

     

     

     

    Rafael Camargo,

    Microsoft Student Partner

    http://rafael-camargo.spaces.live.com

    DevGoiás.NET - www.devgoias.net

     

     

    segunda-feira, 27 de agosto de 2007 11:58
  • O LINQ é sobre consulta à objetos. O LINQ for Entities age sobre o Entities Framework (EF), este último tetá suporte para outros providers.

     

    http://blogs.msdn.com/adonet aqui tem até um exemplo de como se criar um provider para o EF.

     

    Abraço.

    segunda-feira, 27 de agosto de 2007 13:53