related - Entity Framework & LINQ to SQL-¿Conflicto de interés?

query data entity framework

Question

He estado leyendo en la blogósfera durante la semana pasada que Linq to SQL está muerto [y EF a largo plazo y Linq a Entidades]. Pero cuando leí la información general en MSDN, me pareció que Linq to Entities genera eSQL del mismo modo que Linq to SQL genera consultas SQL.

Ahora, dado que la implementación subyacente (y dado que SQL Server aún no es un ODBMS) sigue siendo un almacén Relacional, en algún momento el marco de la Entidad debe realizar la traducción en consultas SQL. ¿Por qué no corregir los problemas de Linq a SQL (relaciones m: m, solo soporte de SQL Server, etc.) y usar Linq a SQL como la capa que genera estas consultas?

¿Esto se debe al rendimiento o EF utiliza una forma diferente de transformar la declaración de eSQL en SQL?

Me pareció, al menos para mi mente no aprendida, un ajuste natural para dogfood Linq a SQL en EF.

¿Comentarios?

Answer 1

Vale la pena señalar que Entity Framework tiene (al menos) tres formas de consumo:

• LINQ a Entidades sobre Servicios de Objeto sobre Entity Client
• Entity SQL sobre Object Services sobre Entity Client
• Entity SQL que usa objetos de comando de Entity Client (más similar al clásico ADO.NET)

Entity Client finalmente escupe una representación del comando ESQL (en una forma canónica de base de datos independiente) que el proveedor ADO.NET para el RDBMS específico es responsable de convertir en SQL específico de la tienda. Este es el modelo correcto en mi humilde opinión, ya que a lo largo de los años se ha invertido mucho tiempo (y se seguirá invirtiendo) en la producción de excelentes proveedores de ADO.NET para cada tienda.

Como Entity Framework necesita trabajar con muchas tiendas y, por lo tanto, con muchos proveedores de ADO.NET, hay menos posibilidades de que optimicen fácilmente lo que el Entity Client genera por tienda (al menos, eso es donde estamos con v1). El equipo LINQ to SQL tenía un problema mucho más pequeño que resolver: "funciona solo con SQL Server" y, por lo tanto, podía almacenar material específico más fácilmente. Sé que el equipo de EF sabe que hay casos en los que EF a SQL Server está produciendo TSQL de manera menos eficiente que L2S y está trabajando para mejorar esto para V2.

Curiosamente, este modelo permite agregar nuevas capacidades entre Entity Client y ADO.NET Provider para una tienda. Estos "proveedores de envoltura" pueden agregar servicios tales como el registro, la auditoría, la seguridad y el almacenamiento en caché. Esto se trata como una función de V2 en http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx

Si observas el panorama completo, puedes ver que sería terriblemente difícil y de hecho restrictivo intentar y de alguna manera adaptar la generación de L2S TSQL al archivo de Entity Framework.

Answer 2

Una gran diferencia entre Linq a SQL y Entity Framework es que EF implementa la especificación del modelo de datos de la entidad (EDM), y hay otros productos que se basan en el EDM, como ADO.NET Data Services (también conocido como Astoria).

El EDM se está utilizando ahora para extender el AtomPub en una nueva especificación llamada Open Data Protocol (OData http://odata.org/ ), que se utiliza para estandarizar CRUD además de REST.

Answer 3

En realidad, el EF no genera EntitySQL al traducir consultas LINQ. En EF, tenemos una representación basada en la estructura de datos para todas las consultas llamadas CQT o árboles de consulta canónicos. Tanto el traductor LINQ como el analizador EntitySQL producen CQT, y el resto del canal de traducción de consulta usa CQT (y otras formas intermedias internas), que después de varias transformaciones llegan al proveedor ADO.NET (como CQT a nivel de tienda), que luego es responsable de traducirlo al dialecto SQL del back-end. Entonces las rutas son LINQ -> CQT -> SQL o EntitySQL -> CQT -> SQL.