Extendiendo EF4 SQL Generation

Question

Estamos usando EF4 en un sistema bastante grande y ocasionalmente enfrentamos problemas debido a que EF4 no puede convertir ciertas expresiones en SQL. En este momento, debemos hacer algún trabajo de pies (DB/Code) o simplemente aceptar el golpe de rendimiento y permitir que la consulta se ejecute en la memoria.

Huelga decir que ninguno de estos es ideal y los hacks que a veces hemos tenido que usar reducen la legibilidad/mantenibilidad.

Lo que idealmente nos gustaría es una forma de ampliar las capacidades de generación de SQL del proveedor de EF4 SQL. Obviamente, hay algunas cosas, como las llamadas al método .Net, que siempre tendrán que ser del lado del cliente, pero algunas funcionalidades, como las comparaciones de fechas (por ejemplo, [Agrupar por semanas en Linq a Entities) deberían poderse hacer.

He buscado en Google pero quizás estoy usando una terminología incorrecta, ya que todo lo que obtengo es información sobre las nuevas características de EF4 SQL Generation.

Para un marco tan flexible y extensible, me sorprendería que esto no fuera posible. En mi cabeza, me imagino heredar del proveedor [SQL 2008] y extenderlo para manejar expresiones adicionales/similares en el árbol de expresiones que se le da para convertir a SQL.

Cualquier ayuda/sugerencias apreciadas.

Estamos utilizando VS2010 Ultimate, .Net 4 (perfil no cliente) y EF4. La aplicación se encuentra en ASP.Net y se ejecuta en un entorno de 64 bits en caso de que haga la diferencia.

Actualización: En respuesta a algunas solicitudes de aclaración;

Estamos utilizando un enfoque de primer código y tenemos una aplicación de consola que crea la base de datos y rellena algunas tablas de referencia.

Preferiría mantenerme alejado de los procesos almacenados a menos que también puedan generarse de una manera similar: en la actualidad, se generan nuevas versiones de la base de datos según sea necesario y un proceso separado migra/sincroniza datos. todo que actualmente hacemos con respecto a la base de datos usa entidades. Admito que no puedo dar una buena razón, pero ejecutar scripts SQL para generar procs almacenados parece estar mal en este escenario. Pero corrígeme si me equivoco.

Con respecto a un escenario específico, me temo que no puedo dar uno de nuestro código sin pasar por un largo ejercicio de burocracia - El link mentioned above es un buen ejemplo del tipo de cosas que estamos tratando de realizar. En este ejemplo, la implementación de un mecanismo que permita la aritmética de fechas:

DateTime firstDay = GetFirstDayOfFirstWeekOfYear(); 
var userTimes = from t in context.TrackedTimes 
       group t by new {t.User.UserName, WeekNumber = (t.TargetDate - firstDay).Days/7} into ut 
       select new 
       { 
        UserName = ut.Key.UserName, 
        WeekNumber = ut.Key.WeekNumber, 
        Minutes = ut.Sum(t => t.Minutes) 
       }; 

puedo ver una manera que esto podría lograrse mediante SQL solos pero no cómo hacerlo usando LINQ a Entidades (del lado del servidor).

Answer 1

recomendaría primero mirando EntityFunctions (genérico) o SqlFunctions (sólo SQL Server), que proporcionan una gran cantidad de funcionalidad de base de datos integrada dentro de una consulta LINQ normal a Entidades. Si eso no es suficiente, puede usar EdmFunctionAttribute para mapear una función de base de datos integrada o un procedimiento almacenado definido por el usuario. Una tercera opción es intentar que funcione como una consulta Entity SQL.

La última solución que sugirió (escribir un proveedor de EF) es bastante pesada. Es posible escribir un proveedor de EF que envuelva el proveedor de SQL existente, pero tendría que cambiar algunos de los árboles de expresión a Entity SQL como mínimo. Se han lanzado envolturas de proveedores de EF muy simples en MSDN Code. Sin embargo, lo trataría como último recurso.

Answer 2

La conversión de sus consultas LINQ basadas en .NET a SQL es manejada por el proveedor LINQ To Entities. No creo que el proceso central de traducción/compilación, que es extremadamente complejo, sea extensible. Tendría que escribir su propio proveedor desde cero.

Todavía tengo que encontrarme con cualquier consulta que pueda representarse en SQL y que no pueda expresarse en LINQ. Si tiene una consulta que es difícil de escribir como una consulta LINQ, ¿ha considerado utilizar procedimientos almacenados? Ayudaría si pudiera proporcionar algunos ejemplos de las consultas que no se convertirán.

ACTUALIZACIÓN:

Otra opción es crear métodos de extensión avanzados que utilizan las expresiones hechas a medida para formar la consulta. Aquí es un buen ejemplo que simula la función contiene() para ejecutar "donde en" consultas del tipo:

'Contains()' workaround using Linq to Entities?