Proveedores de LINQ

En Internet hay abundante información sobre cómo utilizar LINQ, las distintas cláusulas que podemos utilizar en una expresión de consulta, etc. De lo que no encuentro tanta información es sobre “quién es quién en LINQ”, es decir, un punto de entrada para aquellos que nunca han oído hablar de LINQ y quieran poner en orden ciertos conceptos antes de embarcarse en su aprendizaje.

Con LINQ (Language INtregated Query o lenguaje integrado de consulta), podremos escribir sentencias en nuestro código .NET sobre distintos orígenes de datos (objetos en memoria, DataSet, XML, Entity Framework, etc.), de forma muy similar a como escribimos sentencias SQL en nuestro servidor de datos preferido.

La sintaxis de estas sentencias serán iguales con independencia del origen de datos al que estemos atacando. De este modo LINQ resuelve la necesidad de aprender distintos lenguajes para consultar distintos orígenes de datos (imagina que antes de LINQ necesitabas saber T-SQL para bases de datos, XPath/XQuery para documentos XML, etc.).

Es decir, con LINQ tenemos una sintaxis uniforme para recuperar y manipular datos desde distintos orígenes, y además permite que nuestra aplicación sólo tenga código .NET (nada de lenguajes foráneos incrustados en nuestro código como T-SQL, XPath, etc.). Por otro lado, imagina que con LINQ además aprovechamos todas las ventajas del IDE, como son el Intellisense, la validación de tipos fuertemente tipados, etc.

Muchas de las nuevas características de Visual Basic se han incluido para dar soporte a LINQ (ver por ejemplo métodos extensores, tipos anónimos, expresiones lambda, etc.). En realidad, son características valiosas por sí mismas y que se pueden utilizar sin hacer uso de LINQ, pero la realidad es que todas ellas son utilizadas por LINQ.

Antes de comenzar a utilizar LINQ, es preciso conocer sobre qué distintos orígenes de información se puede utilizar como lenguaje de consulta.

En realidad,LINQ sólo exige un proveedor para poder acceder a la información expuesta, esto es que casi cualquier origen de información podría ser consultado a través de LINQ, siempre y cuando dispongamos del proveedor adecuado.

Microsoft nos suministra de serie los siguientes proveedores:

• LINQ to Objects
• LINQ to XML
• LINQ to ADO.NET
• LINQ to DataSet
• LINQ to SQL
• LINQ to Entities

LINQ to Objects permite utilizar LINQ sobre objetos en memoria.

Permite consultar cualquier colección (o “secuencia” que parece un término más aceptado) que implemente IEnumerable o IEnumerable(Of T). Da igual como hayamos conseguido esta colección, el caso es que una vez dispongamos de ella podremos utilizar LINQ sobre la colección sin necesidad de un proveedor específico.

LINQ to XML permite utilizar LINQ sobre documentos XML.

LINQ to ADO.NET en realidad es el nombre que se da a los distintos proveedores de LINQ orientados a bases de datos relacionales. Dentro de esta categoría, podemos encontrar:

LINQ to DataSet. Está claro que el DataSet es el objeto principal en torno al cual gira toda la estrategia de ADO.NET y su modelo de datos desconectado.  De este modo, no podía quedarse sin su proveedor de LINQ específico.

LINQ to SQL. Este proveedor es, además de proveedor, una “primera aproximación” de Microsoft a los ORM. Es proveedor porque además de ORM también permite consultar posteriormente los objetos del modelo creado con LINQ. En cualquier caso, tengo la sensación de que poco a poco LINQ to SQL pierde fuerza en beneficio de Entity Framework (otro ORM pero bastante más hormonado y maduro que su predecesor). Es por ello que no hay que confundir LINQ to SQL con cualquier proveedor de LINQ que sea utilizado sobre cualquier ORM. Por ejemplo, a veces leo expresiones como “LINQ to SQL sobre mi modelo de Entity Framework”, y en realidad eso no es correcto y querrían decir (supongo) “LINQ to Entities sobre mi modelo de Entity Framework”. Es decir, cualquier hablamos de LINQ to SQL podemos estar hablando de 2 cosas, bien del ORM que se llama “LINQ to SQL”, bien del proveedor LINQ que permite consultar el ORM “LINQ to SQL” (lo que pasa es que el proveedor se llama igual que el ORM y de ahí viene las confusiones).

LINQ to Entities. Este proveedor permite consultar los modelos de datos de entidad creados por el ORM Entity Framework.

Aunque los proveedores aquí expuestos son los más habituales, el sencillo modelo de extensibilidad de los proveedores de LINQ permite que estén surgiendo nuevos proveedores ya sea por parte de empresas de terceros o de la comunidad. Por ejemplo, podemos encontrar proveedores para Flickr, Twitter, Active Directory, LDAP, WMI, CSV, etc.

Algunos enlaces interesantes al respecto son:

LINQ-To-Everywhere – List of LINQ Providers

Link to Everything: A List of LINQ Providers

Third-Party LINQ Providers

No me gustaría despedirme si un pequeña píldora de código que muestre la potencia de LINQ y los proveedores de terceros.

Imaginemos que quiero mostrar mis últimos tweets en una aplicación. Para ello haré lo siguiente:

Descargar e instalar el proveedor de LINQ to Twitter, desde http://linqtotwitter.codeplex.com/ o bien utilizar NuGet y olvidarme (si no sabes que es NuGet, puede visitar este otro post).

Programar una sencilla expresión LINQ que me devuelva mis últimos tweets. Esta es la parte importante puesto que el proveedor de LINQ to Twitter está recuperando información de Twitter y exponiéndola de la forma precisa para que pueda ser consultada con LINQ. Además, fíjate que yo no sé que API está utilizando internamente este proveedor para recuperar la información de Twitter, pero lo cierto es que tampoco me importa, es un proveedor y él sabrá como lo hace.

El código es el siguiente:

Imports LinqToTwitter

 

Module Module1

 

    Sub Main()

        Dim contexto As New TwitterContext

 

        ' Consulta Linq para recuperar mis últimos tweets

        Dim tweets = From tweet In contexto.Status

                     Where tweet.ScreenName = "panicoenlaxbox" And tweet.Type = StatusType.User

 

        For Each tweet In tweets

            Console.WriteLine("{0}", tweet.Text)

        Next

 

        Console.ReadLine()

    End Sub

 

End Module

 
Como puedes comprobar si sabes SQL, la expresión de consulta anterior te resultará muy intuitiva.

Sin duda, este ejemplo muestra como LINQ ha venido para quedarse,
LINQ to infinity, and beyond!

Un saludo!