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

Question

He estado leyendo en la blogósfera durante la semana pasada que Linq to SQL está muerto [y EF de larga vida y Linq to Entities]. 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 instrucción 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 ser consumida:

• LINQ a las entidades sobre Servicios de objeto más de entidad cliente
• Entidad SQL más de Servicios de objeto sobre la entidad cliente
• Entity SQL utilizando objetos de entidad de comandos de cliente (más similares a ADO.NET clásico)

entidad cliente en última instancia, escupe una representación del comando ESQL (en una forma de agnóstico de base de datos canónica) que el proveedor de 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, 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 discute como una característica V2 encima en http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspx

Si nos fijamos para ello el cuadro más grande se puede ver que sería terriblemente difícil y ciertamente restrictiva para tratar de alguna manera de montar posteriormente L2S generación TSQL en el archiecture del marco de la entidad.

Answer 2

Una gran diferencia entre Linq to 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 crean en torno al EDM, como ADO.NET Data Services (también conocido como Astoria).

El EDM ahora se utiliza para extender el AtomPub en una nueva especificación llamada Open Data Protocol (OData http://odata.org/), que se utiliza para estandarizar CRUD sobre 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.