Al usar Entity Framework, ¿ESQL funciona mejor que Linq para Entidades?Rendimiento de Linq a Entidades vs ESQL
Preferiría utilizar Linq para Entidades (principalmente debido a la verificación de tipo fuerte), pero algunos de los otros miembros del 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 usar cualquiera de los métodos.
Las diferencias más obvias son:
LINQ a Entidades está fuertemente tipado código que incluya buena comprensión de sintaxis de la consulta. El hecho de que el "desde" aparece antes que el "seleccionar" permite que IntelliSense lo ayude.
Entity SQL utiliza consultas tradicionales basadas en cadenas con una sintaxis similar a SQL más familiar, donde la instrucción SELECT aparece antes que FROM. Debido a que eSQL está basado en cadenas, las consultas dinámicas pueden estar compuestas de manera tradicional en tiempo de ejecución utilizando la manipulación de cadenas.
La diferencia clave es menos obvio:
LINQ a Entidades le permite cambiar la forma o el "proyecto" los resultados de la consulta en cualquier forma que se desee con la opción “Seleccionar nueva {...}” Sintaxis . Los tipos anónimos, nuevos en C# 3.0, han permitido esto.
La proyección no es posible utilizando Entity SQL, ya que siempre debe devolver un ObjectQuery <T>. En algunos casos, es posible utilizar ObjectQuery <objeto>, sin embargo debe evitar el hecho de que .Select siempre devuelve ObjectQuery <DbDataRecord>. Ver código de abajo ...
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 descritos por uno de los miembros del equipo en detalle here y here.
Cuantos más códigos pueda abarcar con la comprobación de tiempo de compilación para mí, es algo que le daría más importancia que el rendimiento. Habiendo dicho eso en esta etapa, probablemente me inclinaría hacia ESQL no solo por el rendimiento, sino que también (en el presente) 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 función que realmente necesitas.
Entidad marco no admite cosas como propiedades personalizadas, consultas personalizadas (para cuando realmente se necesita ajustar el rendimiento) y no funciona igual que linq-to-sql (es decir, hay funciones que simplemente no funcionan) trabajar en el marco de la entidad).
Mi impresión personal del Entity Framework es que hay un gran potencial, pero es probable que sea un poco "rígido" en su implementación para usar en un entorno de producción en su estado actual.
Entity-SQL (eSQL) le permite hacer cosas tales como consultas dinámicas más fácilmente que LINQ to Entities. Sin embargo, si no tiene un escenario que requiera eSQL, vacilaría en confiar en él a través de LINQ porque será mucho más difícil de mantener (por ejemplo, no tendrá que realizar más comprobaciones en tiempo de compilación, etc.).
Creo que LINQ le permite precompilar también sus consultas, lo que puede proporcionarle un mejor rendimiento. Rico Mariani blogged about LINQ performance hace un tiempo y analiza las consultas compiladas.
ESQL también puede generar algunos sql especialmente viciosos. Tuve que rastrear un problema con una consulta de ese tipo que usaba clases heredadas y descubrí que mi pequeño ESQL de 4 líneas se tradujo en una declaración de monstruo SQL de 100 000 caracteres.
Hizo lo mismo con Linq y el código compilado era mucho más manejable, digamos 20 líneas de SQL.
Además, lo que otras personas mencionaron, Linq es muy tipeo, aunque es muy molesto depurar sin la función editar y continuar.
AD
gráfico agradable comparaciones mostrando rendimiento aquí: Entity Framework Performance Explored no hay mucha diferencia observada entre ESQL y Entidades pero las diferencias globales significativas en el uso de las entidades sobre las consultas directas
Entity Framework utiliza dos capas de mapeo objeto (en comparación con un único capa en LINQ to SQL), y la asignación adicional tiene costos de rendimiento. Al menos en EF versión 1, los diseñadores de aplicaciones deben elegir Entity Framework solo si las capacidades de modelado y mapeo ORM pueden justificar ese costo.
Para consultas directas estoy usando linq para entidades, para consultas dinámicas estoy usando ESQL. Quizás la respuesta no sea cualquiera de las dos cosas, sino también /.