Rendimiento de Linq to Entities frente a ESQL

Question

Cuando se utiliza Entity Framework, ¿ESQL funciona mejor que Linq to Entities?

Preferiría usar Linq to Entities (principalmente debido a la verificación de tipos seguros), pero algunos de los otros miembros de mi equipo citan el rendimiento como una razón para usar ESQL.Me gustaría tener una idea completa de los pros y los contras de utilizar cualquiera de los métodos.

Answer 1

Las diferencias más obvias son:

Linq to Entities es un código fuertemente tipado que incluye una buena sintaxis de comprensión de consultas.El hecho de que "de" aparezca antes de "seleccionar" permite que IntelliSense le ayude.

Entity SQL utiliza consultas tradicionales basadas en cadenas con una sintaxis similar a SQL más familiar donde la instrucción SELECT viene antes de FROM.Debido a que eSQL está basado en cadenas, las consultas dinámicas se pueden componer de forma tradicional en tiempo de ejecución mediante manipulación de cadenas.

La diferencia clave menos obvia es:

Linq to Entities le permite cambiar la forma o "proyectar" los resultados de su consulta en cualquier forma que necesite con el botón "seleccionar nuevo{...}” sintaxis.Los tipos anónimos, nuevos en C# 3.0, lo han permitido.

La proyección no es posible utilizando Entity SQL ya que siempre debe devolver un ObjectQuery<T>.En algunos escenarios, es posible utilizar ObjectQuery<object>; sin embargo, debe evitar el hecho de que .Select siempre devuelve ObjectQuery<DbDataRecord>.Ver código a continuación...

ObjectQuery<DbDataRecord> query = DynamicQuery(context,
        "Products",
        "it.ProductName = 'Chai'",
        "it.ProductName, it.QuantityPerUnit");

public static ObjectQuery<DbDataRecord> DynamicQuery(MyContext context, string root, string selection, string projection)
{
    ObjectQuery<object> rootQuery = context.CreateQuery<object>(root);
    ObjectQuery<object> filteredQuery = rootQuery.Where(selection);
    ObjectQuery<DbDataRecord> result = filteredQuery.Select(projection);
    return result;
}

Hay otras diferencias más sutiles descritas en detalle por uno de los miembros del equipo. aquí y aquí.

Answer 2

ESQL también puede generar algunos SQL particularmente viciosos.Tuve que rastrear un problema con una consulta de este tipo que utilizaba clases heredadas y descubrí que mi pequeño ESQL de 4 líneas se tradujo en una declaración SQL monstruosa de 100000 caracteres.

Hice lo mismo con Linq y el código compilado fue mucho más manejable, digamos 20 líneas de SQL.

Además, lo que otras personas mencionaron, Linq es muy tipográfico, aunque es muy molesto depurar sin la función editar y continuar.

ANUNCIO

Answer 3

Entity-SQL (eSQL) le permite hacer cosas como consultas dinámicas más fácilmente que LINQ to Entities.Sin embargo, si no tiene un escenario que requiera eSQL, dudaría en confiar en él en lugar de LINQ porque será mucho más difícil de mantener (por ejemplo,no más comprobaciones en tiempo de compilación, etc.).

Creo que LINQ también le permite precompilar sus consultas, lo que podría brindarle un mejor rendimiento.marian rico blogueó sobre el rendimiento de LINQ hace un tiempo y analiza consultas compiladas.

Answer 4

Bonito gráfico que muestra comparaciones de rendimiento aquí: Se explora el rendimiento del marco de entidadNo hay mucha diferencia observada entre ESQL y las entidades, pero las diferencias generales significativas en el uso de entidades sobre consultas directas

Entity Framework utiliza dos capas de mapeo de objetos (en comparación con una sola capa en LINQ to SQL), y el mapeo adicional tiene costos de rendimiento.Al menos en la versión 1 de EF, los diseñadores de aplicaciones deben elegir Entity Framework solo si las capacidades de modelado y mapeo ORM pueden justificar ese costo.

Answer 5

Para mí, cuanto más código pueda cubrir con la verificación del tiempo de compilación, es algo a lo que le daría más importancia que al rendimiento.Dicho esto, en esta etapa probablemente me inclinaría por ESQL no solo por el rendimiento, sino que también (en la actualidad) es mucho más flexible en lo que puede hacer.No hay nada peor que usar una pila de tecnología que no tiene una característica que realmente necesitas.

El marco de la entidad no admite cosas como propiedades personalizadas, consultas personalizadas (para cuando realmente necesita ajustar el rendimiento) y no funciona igual que linq-to-sql (es decir,hay características que simplemente no funcionan en el marco de la entidad).

Mi impresión personal de Entity Framework es que hay mucho potencial, pero probablemente sea un poco "rígido" en su implementación para usarlo en un entorno de producción en su estado actual.

Answer 6

Para consultas directas estoy usando linq to entidades, para consultas dinámicas estoy usando ESQL.Quizás la respuesta no sea una u otra, sino y/también.