Set Operators, Concat, Union, Intersect, Except y Distinct

Seguimos con los operadores de LinQ, ahora le toca el turno a los ‘Set Operators’ u Operadores de Conjunto.

Los operadores de conjunto, nos permiten realizar actuaciones sobre dos secuencias (IEnumerable<T>) del mismo tipo de datos, dando como resultado una colección de este mismo tipo. Todas y cada una de sus ejecuciones se realizan de forma diferida o perezosa.

En caso de que alguna de estas colecciones sea null en el momento de realizar la llamada, el compilador lanzará un ArgumentNullException.

Vamos a detallar cada uno de sus operadores, para intentar que todo esto quede un poco más claro, haré un par de ejemplos para cada operador, uno con datos simples, colecciones de tipo int, y otro con una de las clases más utilizada en nuestros ejemplos y que tiene su definición en los post anteriores, el tipo Automovil. El objetivo  es comprender lo imprescindible, que es el uso de las sobrecargas que admiten un comparador de tipo IEQualityComparer<T> para los tipos compuestos, en el que indicaremos al compilador como queremos que se diferencien 2 objetos de este tipo.

Como en todas las reglas, hay una excepción y esta no iba a ser menos. El operador Distinct, cambiará, para utilizar una única colección en decremento de dos, pero eso lo contaremos un poquito más adelante.

Operadores de Elemento, First, Single, LastOrDefault ... etc.

Los operadores de elemento son todos aquellos métodos extensores dentro de la librería de LinQ, que devuelven una única pieza o el valor por defecto de su tipo a partir de una secuencia de datos IEnumerable<TSource>.

Estos operadores suelen estar compuestos por su definición simple y una variación ‘OrDefault’. Esta variación ‘OrDefault’, viene a significar, que en caso de no cumplirse el criterio de búsqueda, el operador no lanzará ninguna excepción y devolverá el valor por defecto del tipo al que pertenece la secuencia. Este valor por defecto es el que devolvería el operador default(T), que ya estudiamos con anterioridad.

Paginación con LinQ

Después del último post dedicado a los operadores de Partición, me ha parecido interesante el parar un poco con toda la ristra de descripción de operadores y entrar un poco en un ejemplo más jugoso de la vida real. En este ejemplo utilizaremos dos de los operadores descritos en el último post, Take y Skip, y veremos lo enormemente sencillo que puede llegar a ser, el realizar paginación de datos con el uso de estos operadores.

Para el ejemplo he utilizado una aplicación WPF. No entraré demasiado en su implementación y en las características de esta tecnología, para aparte de no confundir, centrarme en lo realmente significativo del post. Pero que nadie se preocupe si está interesado en la última tecnología de desarrollo de aplicaciones de escritorio de Microsoft, ya que si el tiempo y la dedicación me lo permiten, cuando acabe todo este tinglao de LinQ, la idea es empezar con WPF, ya que creo que el vacío de información en castellano es bastante grande, y no hay nada realmente didáctico.

Partitions Operators, Take, Skip, TakeWhile y SkipWhile

El objetivo de los operadores de partición, consiste en restringir el número de elementos de una secuencia. Para ello creará 2 subsecuencias en memoria, en base a un parámetro int o un Func<T, bool>, según el tipo de operador. Una de estas dos subsecuencias, serán el resultado, y la elección, también se tendrá en cuenta según el operador utilizado. Para vislumbrar mejor estas líneas, vamos a ver cada uno de ellos con más detalle:

Quantifiers Operators, All, Any y Contains

Los Quantifier Operators, son un grupo bastante especial de métodos extensores que devuelven un objeto de tipo bool.

 Este tipo de métodos son en ocasiones obviados, normalmente por su desconocimiento y sustituidos por la unión del uso del método Where() + Count().

Este suele ser un error común de uso, ya que los Quantifier Operators están optimizados para este fin, y la ganancia de rendimiento con su uso es más que evidente.

Más adelante haremos hincapié en ello con unos ejemplos que expongan este manifiesto.

Joins

Los sistemas de bases de datos relacionales tradicionales, tienen la habilidad de poder fundir múltiples conjuntos de datos (normalmente tablas) dentro del resultado de una consulta. Para realizar estas uniones, se tienen en cuenta los datos en común entre unos y otros conjuntos, realizándose generalmente entre claves primarias y claves ajenas (PK y FK).

 Si nos ceñimos al caso de LinQ y al trabajo con datos en memoria mediante la programación orientada a objetos (OOP), el uso de joins en sí, es mucho menos frecuente, pero para quien se sienta cómodo con este tipo de acciones, Microsoft nos proporciona el operador Join, dentro de su conjunto de métodos extensores.

También abordaremos el caso del operador GroupJoin, que nos ofrece la capacidad de relacionar 2 conjuntos de datos, con una tipología mucho más cercana al programador, creando propiedades de tipo colección dentro de las propiedades de la secuencia de resultado, eliminando de esta manera los campos con datos redundantes.

La claúsula GroupBy

Continuamos avanzando dentro de los operadores de consulta de LinQ, y ahora le toca el turno a Group By. Group By es otro de los operadores de consulta de proyección, que a grandes rasgos, nos permite desde una colección de entrada, devolver una colección de salida agrupada, mediante un sencillo grupo de claves valor. Donde la clave estará compuesta por los campos por los que hemos agrupados (los que forman el group by) y el valor lo formarán una colección de elementos que comparten los mismos valores para las propiedades que forman la clave.

IEqualityComparer

Llegado a este punto, vamos a hacer un pequeño parón dentro de los operadores de consulta, para centrarnos en una interface muy útil dentro de la comparación de nuestros objetos, y que bajo mi opinión, mucha gente no le da la importancia que realmente tiene, hasta llegar al punto de que muchos autores ni siquiera le dediquen una línea dentro de libros dedicados por entero a LinQ.

En pocas palabras, la interface IEqualityComparer<T>, nos permite especificar nuestra propia clave de comparación, sin que para ello tengamos que redefinir ninguno de los métodos iniciales de la clase Object. Esto nos ofrece una versatilidad gigante, ya que podemos crear todos los que queramos según nuestras necesidades y nuestro modo de operar. Veremos que esto será clave en el uso de operadores como Group By, Distinct, Union, Intersect, etc.

Proyecciones en LinQ, La cláusula Select y SelectMany

Dentro del mundo de LinQ, las proyecciones, determinan el tipo de datos que será devuelto o proyectado cuando sea aplicado a uno de nuestras secuencias IEnumerable<T>.

 En este apartado estudiaremos los operadores de consulta Select y SelectMany. Hay otros autores y expertos en la materia que les gusta añadir en el apartado de proyecciones las cláusulas Join, GroupBy y GroupJoin, pero en este caso yo he preferido crear un apartado específico para cada una de ellas y así intentar no excederme demasiado en cada una de las entradas para hacerlas más comprensibles y dar más énfasis a cada una de ellas, aplicando casos prácticos de uso.

Claúsula Where

La cláusula where, representa el elemento de filtrado dentro del mundo de LinQ, al igual que en el lenguaje SQL. Esta es una de las más usadas y de las más útiles de todas las que componen su librería de métodos extensores (System.Linq).

La parte más importante dentro de la cláusula Where, es el llamado ‘Predicate’, este es un Parámetro de tipo Func<TSource, bool> que viene a indicar la condición del filtrado. Os facilito la entrada del blog donde se explican en detalle los delegados anónimos Func y donde podéis ampliar información sobre estos tipos.

Operadores de Consulta

Dentro del universo de LinQ, tenemos dos formas diferentes de realizar las llamadas y hacer uso de nuestros métodos de extensores de IEnumerable<T>, la primera es haciendo uso de las Expresiones Lambda, que vendría a representar un uso cotidiano de cualquier método extensor, y la segunda es utilizando el llamado azúcar sintáctico (formato de consulta) y que nos permite realizar una consulta de manera muy similar a como realizaríamos una llamada en el lenguaje SQL.

Es importante señalar que hay algunas opciones que no están disponibles dentro del formato de consulta, aunque son las mínimas, y que iremos viendo según vayamos estudiando los operadores (métodos extensores).

Ejecución Diferida (Lazy Loading)

La ejecución perezosa o diferida (Lazy Loading) es el comportamiento por defecto que usa LinQ para ejecutar, valga la redundancia, sus métodos extensores. A grandes rasgos viene a significar que los métodos no se ejecutan en el momento de realizar su llamada, sino que se ejecutan en el momento en que consumimos (utilizamos) alguno de los datos devueltos por esta llamada. Con todo esto el motor de LinQ se asegura el no realizar cálculos, cargas de datos, etc., que el usuario no necesite en ese momento.

IEnumerable, Entendiendo las secuencias ...

La Iterface IEnumerable<T>, es una de las partes más importantes de todo el mundo de LinQ, ya que todos sus métodos extensores están realizados sobre este tipo y prácticamente todos ellos devuelven objetos de este mismo tipo.

 Podemos entenderla como la mínima expresión de una colección, y prácticamente la mayoría de las colecciones del Framework la implementan (List<T>, Observable<T>, Arrays, etc). En esta parte tenemos que indicar que hay una minoría de ellas que no lo hacen y que principalmente están formadas por colecciones especiales de controles gráficos, tales como el UIElementCollection que es la colección en la que se guardan los objetos contenidos dentro de un Grid de WPF. Cuando estemos acostumbrados a trabajar con LinQ y nos encontremos con una de estas colecciones, lo primero que pensaremos es que o nos falta algún using, o el intellisense o el propio Visual Studio nos están jugando una mala pasada. Un poco más adelante dentro del curso aprenderemos a convertirlas fácilmente en colecciones compatibles con la tecnología.

Métodos de Extensión - Extensions Methods

Los métodos de extensión, nos ofrecen la posibilidad de poder extender las clases de terceros, de poder añadir métodos a clases de las que no disponemos del código fuente y nos es de utilidad añadirles nuevas funcionalidades.

Esta característica se añadió en la versión 3.0 del .Net Framework, y es masivamente utilizada dentro de las librerías de LinQ, especialmente para el tipo IEnumerable<T>, que veremos con posterioridad en la siguiente entrada.

Expresiones Lambda

Vamos con la evolución de los métodos anónimos, para muchos las muy polémicas y comprometidas Expresiones Lambda.

Aparecieron en la versión 3.0 del Framework y vinieron a ser el apoyo ideal para nuestro bien amado LinQ. Las Expresiones Lambda tienen la capacidad de manejar eventos ‘inline’ asignando bloques de código a delegados o eventos, al igual que lo hacían nuestros métodos anónimos, pero de una forma más reducida y concisa, ‘echando mano’ de la inferencia de tipos.

Intentaremos desmitificarlas haciendo una comparativa con los métodos anónimos y desglosando cada una de sus partes y sus formas de uso.

Métodos, Delegados Anónimos

Lo primero para ver este apartado es explicar que podemos encontrárnoslo como Métodos Anónimos o Delegados Anónimos, aunque también podemos referirnos a ellos como Funciones Anónimas, o Funciones o Métodos ‘Inline’. Aparecieron en la versión 2.0 del Framework y vinieron a cubrir la incapacidad de poder definir un método dentro de cualquier porción de código, sin tener que echar mano de la forma clásica [public/private void/int/string/ … nombreMétodo (parámetros)].

Esto como veremos en la siguiente entrega fue superado por creces con la introducción de la Expressiones Lambda en la versión del Framework 3.0 y con el concepto de Inferencia de Tipos, pero como veremos en esta hay una excepción que poseen los delegados anónimos que no pueden realizar las Expressiones Lambda.

Eventos - events

Los eventos son un tipo definido dentro del CLR que nos permite notificar a otros objetos algo que está sucediendo en el interior de nuestra clase. Para que estos objetos puedan ser informados, antes tienen que suscribirse al evento.

Desde la aparición de Visual Basic 6, normalmente achacamos los eventos a controles tales como Buttons, Combobox, DataGrids, etc., pero su aplicación y su enfoque va mucho más allá, y su uso en clases que no forman parte de la GUI, es tan normal, tan común y tan útil como en éstas.

El concepto de evento está completamente ligado al de delegado, ya que se nutre de estos para guardar las acciones que se suscriben al mismo, y así añadir su restricción de firma para estas acciones, de manera que solo se puedan suscribir a estos eventos los métodos que cumplan con la firma de su delegado.

Delegados - Delegates - parte 3

La covarianza y la contravarianza son uno de esos conceptos dentro de la programación que a priori, no solemos verles una funcionalidad o un uso demasiado práctico, pero que cuando manejas, te das cuenta que vienen a romper una serie de limitaciones que sin su existencia nos haría tener que decir eso de ‘no se puede hacer’ en más ocasiones al día. 

Esto no es menos importante para LinQ  ya que tienen una aparición estelar con los delegados genéricos Func.

Para finalizar también veremos la posibilidad de realizar ejecuciones asíncronas con nuestros delegados.

Delegados - Delegates - parte 2

Continuamos con la segunda parte de nuestros queridos delegados, esa clase tan útil, y utilizada por el framwork y tantas veces se nos hace tan complicada de entender.

En esta segunda parte nos centraremos principalmente en estudiar la clase base y los métodos y propiedades más importantes de ésta, que hacen que el delegado realice una series de funciones muy marcadas y en ocasiones totalmente transparentes para nuestro trabajo diario con ellos, ya que están ocultas dentro de la redefinición de operadores.

La segunda parte del post irá dirigida al uso de Generics con delegados. En ella profundizaremos en la importancia y la potencia que tienen para la ejecución de referencias a funciones y a métodos genéricos. También daremos un repaso a los delegados genéricos más importantes del Framework y de LinQ en general que no son otros que Func<T> y Action<T>.

Delegados - Delegates - parte 1

Los siguientes posts sobre Delegados que arrancamos con esta primera parte, pretenden ser algo más que una simple pasada sobre lo que nos ofrece esta clase del CLR y su uso en LinQ. Estos posts intentan profundizar dentro de su usabilidad en el Framework ya que considero que es una de las partes más difícil de comprender y de dominar, y su comprensión total, nos hace no tener ningún tipo de barrera en LinQ dentro de su parte más avanzada.

La definición más lógica que suele realizarse cuando hablamos de un delegado, es que es lo más parecido a un puntero a una función en C++. Esto no es del todo cierto, ya que un delegado es una clase y no un tipo.