Entity Framework und LINQ To SQL - Interessenkonflikt?

Question

Ich habe in der Blogosphäre für die letzte Woche gelesen, dass Linq zu SQL tot ist [und lebe EF und Linq zu Entities]. Aber als ich den Überblick auf MSDN las, schien es mir, dass Linq zu Entities eSQL genau so generiert, wie Linq zu SQL SQL-Abfragen generiert.

Jetzt, da die zugrunde liegende Implementierung (und da SQL Server noch kein ODBMS ist) immer noch ein relationaler Speicher ist, muss das Entity-Framework irgendwann die Übersetzung in SQL-Abfragen durchführen. Warum nicht die Linq zu SQL-Problemen beheben (m: m-Beziehungen, nur SQL-Server-Unterstützung usw.) und Linq zu SQL als Layer verwenden, der diese Abfragen erzeugt?

Ist dies wegen der Leistung oder EF verwendet eine andere Möglichkeit der Umwandlung der eSQL-Anweisung in SQL?

Es schien mir - zumindest für meinen ungelernten Verstand - eine natürliche Passform zu Dogfood Linq zu SQL in EF.

Kommentare?

Answer 1

Es ist erwähnenswert, dass Entity Framework hat (mindestens) drei Möglichkeiten, verbraucht zu werden:

• LINQ to Entities über Object Services über Entity-Client
• Entity SQL über Object Services über Entity-Client
• Entity SQL mit Entity-Client-Befehlsobjekten (am ähnlichsten klassischen ADO.NET)

Entity-Client spuckt schließlich eine Darstellung des ESQL-Befehls aus (in eine kanonische, datenbankunabhängige Form), die der ADO.NET-Provider für das spezifische RDBMS für die Konvertierung in speicherspezifisches SQL verantwortlich ist. Dies ist das richtige Modell IMHO, da im Laufe der Jahre viel Zeit investiert wurde (und weiterhin investiert wird), um großartige ADO.NET Provider für jedes Geschäft zu produzieren.

Da Entity Framework mit vielen Stores und damit vielen ADO.NET Providern zusammenarbeiten muss, gibt es weniger Spielraum für die einfache Optimierung des Entity Client auf Filialbasis (zumindest - wo wir mit v1 sind) . Das LINQ to SQL-Team hatte ein viel kleineres Problem zu lösen - "funktioniert nur mit SQL Server" und könnte daher leichter spezifische Daten speichern. Ich weiß, dass dem EF-Team bekannt ist, dass es Fälle gibt, in denen EF zu SQL Server TSQL weniger effizient als L2S produziert und daran arbeitet, dies für V2 zu verbessern.

Interessanterweise ermöglicht dieses Modell das Hinzufügen neuer Funktionen zwischen dem Entity Client und dem ADO.NET Provider für ein Geschäft. Diese Wrapping-Provider können Services wie Protokollierung, Überwachung, Sicherheit und Zwischenspeicherung hinzufügen. Dies wird als ein V2 Feature über http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx

diskutiert. Sie können sehen, dass es schrecklich schwierig und in der Tat restriktiv wäre, die L2S TSQL-Generation irgendwie in die Architektur des Entity Framework nachzurüsten.

Answer 2

Ein großer Unterschied zwischen Linq zu SQL und Entity Framework ist, dass EF die Entity Data Model Spezifikation (EDM) implementiert, und es gibt andere Produkte, die um den EDM herum gebaut werden, wie ADO.NET Data Services (alias Astoria).

Das EDM wird jetzt verwendet, um den AtomPub in einer neuen Spezifikation namens Open Data Protocol (OData http://odata.org/) zu erweitern, die verwendet wird, um CRUD zusätzlich zu REST zu standardisieren.

Answer 3

Tatsächlich generiert die EF keine EntitySQL beim Übersetzen von LINQ-Abfragen.In der EF haben wir eine datenstrukturbasierte Repräsentation für alle Abfragen, die als CQT oder kanonische Abfragebäume bezeichnet werden. Sowohl der LINQ-Übersetzer als auch der EntitySQL-Parser erzeugen CQTs, und der Rest der Query-Pipeline verwendet CQTs (und andere interne Zwischenformulare), die nach verschiedenen Transformationen zum ADO.NET-Provider (als CQT auf Filialebene) gelangen. Das ist dann verantwortlich für die Übersetzung in den Backend-SQL-Dialekt. Die Pfade sind also LINQ -> CQT -> SQL oder EntitySQL -> CQT -> SQL.