wpf - ¿Cómo pasar de LINQ a SQL a "LINQ to WCF"?

linq-to-sql

Question

Estoy armando una aplicación WPF que eventualmente usará los servicios web de WCF como su fuente de datos.

Durante la fase de creación de prototipos, estoy usando LINQ to SQL en una base de datos SQL 2008 y he llegado a apreciar la facilidad con la que puedo hacer "Agregar nuevo elemento | LINQ to SQL Classes" y generar una clase de modelo para una tabla, luego hablar para ello con LINQ y pasar esto a mi interfaz de usuario XAML, muy agradable.

Pero, ¿qué sucede cuando cambiamos el origen de datos de SQL Server a los servicios web de WCF? Para continuar usando LINQ, ¿tendré que hacer lo siguiente?

• escribir mis propias clases de LINQ-to-web-service manualmente (usando IQueryable etc.?)
• ¿Existe una herramienta de generación de código que hace esto, algo así como "LINQ-to-WCF" (extraño que este término ni siquiera aparece en Google)
• ¿O tendré que obtener de forma ineficiente grandes cantidades de registros de mi servicio web, crear objetos a partir de ellos y luego a LINQ-to-objects para consultarlos?

Gracias por cualquier dirección que pueda dar aquí.

AGREGADO: gracias por las respuestas, muy útiles, pero causaron cierta confusión:

• este tutorial de MSDN dice "Agregar nuevo elemento | Servicio de datos de entidad ADO.NET "
• Tengo VS2008 y puedo hacer "Agregar nuevo elemento | Modelo de datos de entidad ADO.NET "
• este video de MSDN dice que debo crear un nuevo proyecto con la plantilla de servicio de datos ADO.NET que no tengo en VS2008
• ¿Cuáles son las diferencias entre todos estos, que se usan con más frecuencia?
• y por lo que he leído hasta ahora, todo lo que tiene que ver con "LINQ to Entities" implica costos, mientras que "LINQ to SQL" es gratuito, ¿las opciones de "Entity Data Service / Model" anteriores tienen que ver con LINQ to Entities?

Answer 1

¿Has echado un vistazo a los servicios de datos ADO.NET ? Aquí puede consultar un almacén de datos a través del cable con la sintaxis de linq.

Conservará el contexto de datos LINQ to SQL pero lo expondrá a la web y permitirá que sus clientes consulten el contexto en las declaraciones LINQ estándar. Obviamente, debe proteger los servicios de datos para que solo los clientes autorizados se puedan conectar pero, esencialmente, con un trabajo mínimo, puede lograr que su contexto de datos sea "del lado del cliente", por así decirlo.

Answer 2

Probablemente querrás ADO.NET Data Services . Tendrá que agregar una implementación de interfaz IUpdatable a sus entidades, y puede usar LINQ to SQL , Entity Framework, SubSonic o una cantidad de otras. Estamos usando las plantillas CodeSmith PLINQO , que le permiten agregar esta funcionalidad a LINQ to SQL.

Answer 3

Puede agregar una clase Linq a SQL directamente a un proyecto WCF y establecer el Modo de serialización en la clase Linq a SQL a Unidireccional. Si haces esto, las clases aparecerán en el servicio WCF.

Answer 4

Un LINQ genérico para WCF puede no tener sentido. En particular, las llamadas a WCF solo exponen datos de maneras muy específicas, lo que realmente no se ajusta a la forma de hacer las cosas LINQ. Por ejemplo, mi servicio podría tener el siguiente contrato:

List<DAO> GetObjectsInDateRange(DateTime start, DateTime end);
void ExportObjectsToLegacySystem(List<DAO> data);

¿Cómo se expresa en formato LINQ? En particular, cuando el inicio y el final no son miembros de DAO. La única forma de expresarlo sería que el servicio exponga una interfaz IQueryable y no sé cómo es posible.

Ahora, siempre puedes hacer:

var data = from dao 
in wcfService.GetObjectsInDateRange(DateTime.Today,DateTime.Today.AddDays(50))
where dao.AmountOfStuff > 20
select dao;

Dicho esto, sin duda puede crear una interfaz LINQ adaptada a su propio servicio. Digamos que su servicio tiene un método:

List<DAO> GetObjects(DAOFilter filterObject);

donde DAOFilter es un objeto que especifica todos sus criterios de "dónde", lo que puede hacer es escribir un proveedor LINQ que traduzca todas las expresiones en este objeto DAOFilter. Esta sería una solución increíblemente única con una cantidad considerable de trabajo, así que desaconsejaría.

Me hago eco del consejo para echar un vistazo a ADO.Net Data Services .