12

He estado aprendiendo acerca de la carga IQueryable y la carga diferida/ejecución diferida de consultas.Exponer IQueryable Over WCF Service

¿Es posible exponer esta funcionalidad a WCF? Me gustaría exponer un servicio LINQ-to-SQL que devuelve un IQueryable que luego puedo realizar consultas adicionales en el cliente, y finalmente ejecutar usando un .ToList(). ¿El formato OData es aplicable en este contexto?

Si es posible, ¿cuál es el término para esta técnica y cuáles son algunos buenos tutoriales que puedo seguir? Gracias.

+0

Para Silverlight puede utilizar los servicios de WCF RIA – RichardOD

Respuesta

11

Debe comprobar WCF Data Services que le permitirá definir consulta LINQ en el cliente. WCF Data Services es probablemente la única solución para su requerimiento.

IQueryable sigue siendo solo interfaz y la funcionalidad depende del tipo que implementa la interfaz. No puede exponer directamente las consultas Linq-To-Sql o Linq-To-Entities. Existen múltiples razones, como contextos de vida cortos o serialización, que ejecutarán la consulta para que el cliente obtenga una lista de todos los objetos en lugar de la consulta.

+0

Gracias, esto es lo que estaba buscando. – Trust

1

Por lo que yo sé, el DataContext no es serializable significado que no se puede pasar por ahí con WCF

1

Puede usar http://interlinq.codeplex.com/ que le permite enviar consultas Linq por WCF.

WCF Data Services solo se puede usar con webHttpBinding y no todas las consultas de Linq se pueden expresar. Escribir consultas cuando se utiliza WCF Data Service no es tan atractivo - requiere expresiones de cadena tales como:

.AddQueryOption("$filter", "Id eq 100"); 
0

He estado luchando con la misma pregunta, y se dio cuenta de que una pregunta así formada es un problema resuelto.

IQueryable básicamente sirve para filtrar la consulta antes de enviarla a su llamada a la base de datos, de modo que en lugar de obtener 1000 registros y filtrar solo 10, se obtienen esos 10 para comenzar. Ese filtro pertenece a su capa de servicio, pero si está creando una API, supongo que la correlacionará con parámetros Y/O en su URL.

http: // {host}/{entity}/q? Name = john & edad = 21.

por lo que terminan con algo como esto:

Filter:Column1=Value1 > http://{host}/{entity}q?column1=value1 > SELECT * 
                    FROM Entity 
                    WHERE Column1=Value1 

MVC     > WCF         > DB 

se puede encontrar una muy buena muestra de [here]

Por último, ya que su carga útil del WCF será muy probablemente un JSON, se puede (y debería) deserializarlos en sus Modelos de Dominio dentro de una colección. Es hasta este punto donde debería producirse la búsqueda, así que recomendaría algunos caché de WCF (y dado que es HTTP, es realmente simple). Todavía utilizará LINQ en el lado de la aplicación web, sin la cláusula LINQ "DÓNDE" (a menos que desee crear dinámicamente la URL expresada anteriormente)

Para una consulta O compleja, le importaría terminar con múltiples WCF consultas (1 por "y") y luego concatenar todos juntos

-1

Si es posible enviar IQuerable <> sobre WCF no es una buena cosa seguridad sabia, ya que IQuerable <> podrían exponer a cosas como la cadena de conexión a la base de datos . Sin embargo, algunos de los comentarios anteriores parecen prometedores.

+0

"no es algo bueno para la seguridad" ... ¿eso no depende de la forma específica en que se implemente 'IQueryable'? – Crono

1

https://remotelinq.codeplex.com/ es otra opción. Pero funciona en AppDomain para escanear los ensamblajes actuales y serializarlos. Esta tecnología no es apta para WinRT como no Dominios para la aplicación WinRT