7
Consulta de un modelo conceptual.Entity Framework Entity SQL vs Query builder methods
Sé que en EF existe 3 opción para consultar:
- LINQ to Entidad
- Entity SQL
- de consulta métodos constructor
Aquí un ejemplo de código para los dos últimos:
#region Query Entity Sql
string queryJob4 = @"SELECT VALUE myJobs FROM CmsJobs AS myJobs WHERE myJobs.JobId = @id";
ObjectQuery<CmsJob> queryJobs4 = new ObjectQuery<CmsJob>(queryJob4, context);
queryJobs4.Parameters.Add(new ObjectParameter("id", 58));
#endregion
#region Query Builder method
ObjectQuery<CmsJob>queryJob5 = context.CmsJobs.Where("it.JobId == @id", new ObjectParameter("id",66));
#endregion
I woul me gustaría saber:
- ¿En qué entorno es más apropiado de una forma a otra y por qué?
- ¿Qué usas y por qué?
Gracias chicos por sus opiniones!
preste atención a que la compilación de la expresión Liq to Entity también tiene un costo. Entity SQL redujo ese costo. – VdesmedT
@VdesmedT: [citación necesitada]. ¿Quiere sugerir que EF favorece Entity SQL sobre todos los demás y convierte internamente consultas de tipo estáticamente de Linq-to-Entites en una cadena Entity SQL y luego procede a analizar y recompilar esa cadena BACK en una expresión de árbol de comandos para su ejecución? Eso me parece un poco exagerado, pero solo estoy preguntando si tienes una fuente para respaldar esa afirmación. –
"Las consultas contra Entity Framework están representadas por consultas de árbol de mandatos, que se ejecutan contra el contexto del objeto. LINQ to Entities convierte consultas de consultas integradas en lenguaje (LINQ) a consultas de árbol de comandos, ejecuta las consultas en Entity Framework y devuelve objetos puede ser utilizado tanto por Entity Framework como por LINQ ". [fuente] (http://msdn.microsoft.com/en-us/library/bb386964.aspx). En ninguna parte eso implica que las consultas de LINQ-a-Entidades se conviertan en Entity SQL, por lo que no veo cómo se puede afirmar que Entity SQL puede ser menos costoso. –