Ir al contenido principal

LINQ: Language Integrated Query

Un lenguaje camaleónico

Hoy vamos a explorar y a hablar un poco de LINQ y de cómo podemos manipular colecciones de datos para ciertas necesidades específicas.

LINQ, pronunciado "link" (aunque, como hispanohablantes, tendemos a enfatizar la "q"), nos permite realizar consultas directamente en el lenguaje de programación que estamos utilizando, en este caso, C#.

Lo que hace especial a LINQ es su capacidad para integrarse con diversas fuentes de datos: colecciones en memoria (como listas y arrays), bases de datos relacionales, archivos XML, etc. Sin embargo, la forma en que construimos nuestras consultas puede variar según el tipo de fuente de datos que estemos manejando. Ya que, por ejemplo, no es lo mismo realizar una consulta sobre una colección de objetos en memoria que trabajar con un conjunto de filas de un DataTable.

Para lograr esta capacidad de trabajar con cualquier fuente de datos, LINQ depende de la interfaz IEnumerable<T>, que le permite trabajar con colecciones independientemente de su origen. Esta interfaz define una forma común y estándar de acceder a los elementos de una colección, lo que permite que LINQ aplique consultas y transformaciones de manera uniforme sobre diferentes tipos de datos, como listas, arrays, bases de datos, archivos XML, y más.

Para aclarar y hacer un poco más extensible el párrafo anterior, dentro de las propiedades intrínsecas del lenguaje, se encuentra también la transformación de datos. Supongamos por un momento, que la fuente de datos que estamos utilizando en la consulta son datarows pero queremos como resultado un objeto, eso lo podríamos conseguir fácilmente con LINQ.

¿Por qué nació LINQ?

Antes de LINQ, los desarrolladores enfrentaban desafíos importantes al trabajar con datos provenientes de diferentes fuentes, como bases de datos, XML o colecciones en memoria. 


.NET Language-Integrated-Query
imagen obtenida del sitio oficial de Microsoft Learning

Las consultas solían requerir código específico para cada fuente de datos, lo que generaba dificultad en el mantenimiento del código y propensión a errores: Al depender de cadenas de texto para consultas (como SQL o XPath), los errores de sintaxis no se detectaban hasta el tiempo de ejecución.

Principales hitos de LINQ

  • 2005: LINQ comenzó como un proyecto de investigación en Microsoft liderado por Anders Hejlsberg, el arquitecto principal de C#.
  • 2006: Microsoft presentó LINQ como una tecnología en desarrollo durante la Professional Developers Conference (PDC).
  • 2007: Se incluyó oficialmente en .NET Framework 3.5 como parte del ecosistema de C# 3.0 y Visual Studio 2008.

Componentes clave 

  • Extensiones de métodos: Habilitaron el uso de métodos como Where, Select, y OrderBy sobre colecciones.
  • Delegados y expresiones lambda: Facilitando consultas más expresivas.
  • Tipos anónimos y propiedades automáticas: Simplificaron la creación de estructuras de datos temporales para resultados de consultas.

Las bases

Para quienes están familiarizados con SQL, la estructura de LINQ puede resultar similar, aunque con diferencias relevantes. Un aspecto clave a tener en cuenta es que LINQ es un lenguaje compilado, lo que significa que las consultas se traducen a código ejecutable en tiempo de compilación y se procesan sentencia a sentencia. En contraste, SQL es un lenguaje interpretado que ejecuta las instrucciones proporcionadas directamente en el motor de base de datos de manera interna. 

Por este motivo es que, por ejemplo, una de sus diferencias es que el select está hasta el final.

Si esquematizamos o armamos una especie de esqueleto sobre la estructura, podemos decir que una query básica con LINQ se vería más o menos así:
FROM elemento IN FuenteDeDatos
WHERE elemento.Condicion1 && elemento.Condicion2 || elemento.Condicion3
GROUP elemento BY elemento.PropiedadAgrupar INTO grupo
ORDERBY grupo.Key DESCENDING
SELECT new {
    Propiedad1 = grupo.Key,
    Total = grupo.Count(),
    Promedio = grupo.Average(e => e.PropiedadNumerica)
}
Otra particularidad del lenguaje, es que no existe la cláusula HAVING como tal, es el WHERE el que se encarga de realizar esa tarea filtrando como si fuera un IF. Si está antes del agrupar, filtra igual que SQL pero en cambio si está después de una agrupación se comporta como HAVING filtrando grupos.

Para poder usar LINQ debemos importar la librería System.Linq.
    
    using System.Linq;

Objetos anónimos

Los objetos anónimos son un concepto importante que hay que conocer y entender, ya que en LINQ se utilizan con frecuencia. Estos objetos nos permiten crear estructuras de datos sin la necesidad de definir previamente una clase. 

En otras palabras, es posible generar un conjunto de propiedades específicas directamente dentro de una consulta, lo cual es útil por ejemplo cuando querés trabajar con resultados personalizados.

El uso de var en este contexto es más aplicable, se vería más o menos así:
var resultado = from producto in listaProductos
                where producto.Precio > 100
                select new { 
                               producto.Nombre, 
                               producto.Precio
                           };

// Iterar sobre los resultados
foreach (var item in resultado)
{
    Console.WriteLine("Nombre: " + item.Nombre + " Precio: " + item.Precio);
}

¿Por qué elegir crear un objeto anónimo?

En este ejemplo, estamos asumiendo que el objeto Producto tiene muchas propiedades adicionales (por ejemplo, Código, Descripción, Categoría).
Solo nos interesan las propiedades Nombre y Precio para esta consulta específica.
En lugar de trabajar con todo el objeto, creamos una proyección que contiene solo lo necesario.

Por otro lado, existen varias operaciones de conjunto que veremos puntualmente con algún ejemplo simulando que tenemos una fuente de datos y un ecosistema estructurado con .NET.

Algunos de las operaciones más utilizadas son las siguientes:
  • ToList<tipo>(): Convierte un conjunto de datos en una lista fuertemente tipada (List<T>), garantizando que los elementos cumplen con un tipo específico.

  • ToList(): Convierte un conjunto de datos en una lista genérica (List<T>), deduciendo automáticamente el tipo de los elementos.

  • Any(): Determina si al menos un elemento en una colección cumple con una condición especificada o si la colección tiene elementos.

  • First(): Devuelve el primer elemento de una colección que cumpla una condición especificada. Si no se especifica una condición, devuelve el primer elemento.

  • Last(): Devuelve el último elemento de una colección que cumpla una condición especificada. Si no se especifica una condición, devuelve el último elemento.

  • Distinct(): Devuelve los elementos únicos de una colección eliminando duplicados basados en igualdad.

De la teoría a la práctica

En el siguiente enlace de Github, van a encontrar un repositorio con una clase .NET que cuenta con algunos ejemplos básicos.


Más adelante, voy a cargar en ese mismo repositorio algunos ejercicios prácticos que pueden ser útiles para comprender un poco mejor LINQ. Por eso te invito a que te guardes el link o que le des follow a mi perfil de Github.



De momento, esto es todo lo que quería compartir, aunque probablemente esta no sea mi última entrada sobre LINQ. Hay varios temas que quedaron en el tintero, pero con el objetivo de que la lectura no se haga demasiado extensa, voy a intentar fragmentarlos para futuras publicaciones.

Y bien, esta fue la última entrada del año. Estamos prácticamente con un pie en el 2025, y quiero agradecer a todos los que han llegado hasta este punto. Este año no ha sido precisamente tranquilo en lo personal, pero debo confesar que la cantidad de conocimientos que he adquirido en el 2024 ha sido muy significativa y me ha dejado profundamente satisfecho.

Creo firmemente que uno siempre debe intentar equilibrar los distintos ámbitos de su vida. Sin embargo, también hay momentos en los que es necesario priorizar y, si hace falta, aislarse un poco para poder alcanzar esas metas que nos llenan de satisfacción y nos ayudan a crecer como personas. No es sencillo. 

La tecnología tiene esa capacidad fascinante de cambiar de manera brusca y de renovarse constantemente, lo que a menudo nos mete en una rueda que nunca deja de girar. Por eso, siempre debemos recordar esa frase que mencioné en una de las entradas de este blog: dividir los problemas en pequeñas unidades manejables para abordarlas y resolverlas de forma atómica, asegurando que cada parte se resuelva de manera completa e independiente.

Divide y vencerás.

Feliz año para todos. Que el 2025 los encuentre gozando de buena salud, con nuevas oportunidades y rodeados de las personas que los aman.


imagen con nota feliz año 2025

Otros artículos

Principio de Responsabilidad Única (SRP) – SOLID explicado con ejemplos

Introducción a S.O.L.I.D En esta entrada, intentaremos abordar un nuevo ciclo de conceptos que tienen que ver sobre los principios SOLID , que son fundamentales en la programación orientada a objetos o POO . Estos principios fueron formulados, en principio, por Robert C. Martin , también conocido como " Uncle Bob ", con el objetivo de mejorar la mantenibilidad y escalabilidad del código de software. SOLID es un acrónimo que representa cinco principios de diseño: Single Responsibility Principle (SRP) – Principio de Responsabilidad Única Open/Closed Principle (OCP) – Principio de Abierto/Cerrado Liskov Substitution Principle (LSP ) – Principio de Sustitución de Liskov Interface Segregation Principle (ISP) – Principio de Segregación de Interfaces Dependency Inversion Principle (DIP) – Principio de Inversión de Dependencias Estos principios nos ayudan a crear software más ...

Open/Closed Principle (OCP) – SOLID explicado con ejemplos

Continuando con el repaso de los principios de S.O.L.I.D. que inició en el hilo anterior - si no lo viste hacé click acá  Principio de Responsabilidad Única (SRP) - vamos a ver el segundo en orden de aparición: Principio de Abierto/Cerrado (OCP por sus siglas en inglés). Definición Formal El principio OCP (Open/Closed Principle) establece que el código de una clase o un módulo debe estar abierto para la extensión, pero cerrado para la modificación. Esto significa que no se deben realizar cambios en el código existente cuando se requiere alterar alguna funcionalidad. En lugar de modificar el código existente, se debe crear una nueva implementación que extienda la funcionalidad. La única excepción a esto son los arreglos de bugs, donde está permitido modificar el código existente. Si se desea introducir una nueva funcionalidad, como la ordenación en un método existente, en lugar de modificar el código, se crearía una nueva implementación q...

Roadmap para Desarrolladores Backend en .NET en 2025

El mundo del desarrollo backend está en constante evolución, y mantenerse actualizado con las mejores prácticas y tecnologías es clave para seguir siendo competitivo en el mercado. Si estás buscando una guía clara y estructurada para mejorar tus habilidades en . NET backend , el sitio roadmap.sh ofrece un excelente punto de partida. Para esta entrada vamos a explorar lo siguiente: ¿Qué es roadmap.sh y por qué es relevante? El roadmap backend para .NET en 2025 Tecnologías y habilidades esenciales para backend a considerar ¿Qué es roadmap.sh y quién lo creó? roadmap.sh es una plataforma ampliamente reconocida dentro de la comunidad de desarrolladores. Fue creada por Kamran Ahmed, un Google Developer Expert y contribuidor en múltiples proyectos de código abierto. Desde su lanzamiento, la plataforma ha crecido exponencialmente, acumulando más de 300,000 estrellas en GitHub y una comunidad activa de...

Codewars

Como algunos ya saben, soy un gran entusiasta de las plataformas en línea dedicadas a la educación y al entrenamiento de habilidades, lo que podríamos llamar "gimnasios mentales". Hoy quiero presentarles, o tal vez recordarles, una de mis favoritas: Codewars, conocida también como " Guerras de Código " en español. Si aún no la conocían, los invito a explorarla. Y si ya la conocían, este es un buen momento para redescubrirla y sacarle más provecho. ¿Qué es Codewars? Codewars es una plataforma educativa en línea diseñada como un juego para entrenar habilitades de programación. fue fundada en noviembre de 2012 por Nathan Doctor y Jake Hoffner . La idea surgió durante una competencia de Startup Weekend ese mismo año, donde desarrollaron un prototipo que obtuvo el primer lugar. En la actualidad, Codewars es propiedad de Qualified , una empresa tecnológica que ofrece una plataforma para evaluar y entrenar habilidades en ingeniería de software. Con esta herramienta pod...

Principio de Sustitución de Liskov (LSP) – SOLID explicado con ejemplos

¿Qué es el Principio de Sustitución de Liskov? Imaginá que tenés un control remoto universal diseñado para funcionar con cualquier televisor. Si un nuevo modelo de TV no responde a los mismos comandos, el control deja de ser útil. El Principio de Sustitución de Liskov es como una garantía de que cualquier 'televisor' (o clase derivada) va a funcionar correctamente con el 'control remoto' (o clase base). El Principio de Sustitución de Liskov ( LSP ) es el tercer principio de SOLID , representado por la letra L y establece que: Los objetos de una clase derivada deben poder sustituir a los objetos de su clase base sin afectar el comportamiento correcto del programa. En otras palabras, si una clase hija hereda de una clase padre, cualquier instancia de la clase hija debería poder usarse en lugar de una instancia de la clase padre sin alterar la funcionalidad esperada. ¿Quién es Bárbara Liskov? Bárbara Liskov es una destacada científi...

Principio de Segregación de Interfaces (ISP) – SOLID explicado con ejemplos

El Principio de Segregación de Interfaces es otro de los principios SOLID y establece que: Una clase no debería verse obligada a depender de métodos que no utiliza .  En otras palabras, en lugar de crear una interfaz grande con muchos métodos, es mejor dividirla (segregar) en interfaces más pequeñas y específicas. Pero.. ¿Por qué? Obliga a implementar métodos innecesarios Si una clase solo necesita una "parte" de la funcionalidad de una interfaz, pero esta interfaz es muy grande, se va a ver obligada a implementar métodos que no usa. Esto es casi que inevitable si no buscamos la manera de separar mejor las responsabilidades. Imaginemos una interfaz IVehiculo que tiene los siguientes métodos: public interface IVehiculo { void Conducir () ; void Volar () ; void Navegar () ; } Si una clase Auto implementa esta interfaz, se ve obligado a definir métodos como Volar() o Navegar() , aunque un auto no vuela ni navega. public c...