Una de las novedades más llamativas, o al menos ellos deben entenderlo así, pues aparece en portada, es la incorporación de LINQ (Language Integrated Query) al .Net Framework, que permitirá la extensión de los lenguajes disponibles para la plataforma con nuevas construcciones que permitan realizar consultas y actualizaciones sobre conjuntos de datos de una forma estándar y, como no podía ser menos, orientada a objeto.
El objetivo de este nuevo invento es facilitar al desarrollador, utilizando un lenguaje común (bastante parecido a SQL, por cierto), la realización de consultas sobre cualquier tipo de almacén. Hasta aquí, no hay nada nuevo. La novedad reside, en primer lugar, en que el almacén puede ser un vector, una colección, XML o una base de datos; además, el hecho de poder indicar de forma directa las instrucciones de consulta facilita enormente la programación, pues las comprobaciones sintácticas se harán en tiempo de edición y compilación, bastante mejor que con SQL hospedado, donde normalmente los errores se producen en ejecución. Interesante, ¿no?
Pero veámoslo con un ejemplo, en C# (aunque también podría ser en VB), tomado de la misma web. Supongamos que tenemos definido un array de strings de la siguiente manera:
Podemos hacer una consulta sobre este almacén de esta forma tan sencilla:string[] names = { "Burke", "Connor", "Frank",
"Everett","Albert", "George",
"Harris", "David" };
IEnumerable<string> expr =
from s in names
where s.Length == 5
orderby s
select s.ToUpper();
Se entiende a primera vista: al ejecutar esta sentencia, expr contendrá una enumeración de strings con los nombres de cinco caracteres, ordenados alfabéticamente, y pasados a mayúsculas del almacén names. Antes de LINQ, o sea, en este momento, sólo podríamos hacerlo iterando sobre el array original, enviando a una nueva colección los elementos que cumplieran el criterio, y ordenar los resultados. Un tostón, vaya.
Aparte de los aspectos sintácticos, bastante diferentes a lo conocido hasta el momento, esta sentencia incluye los siguientes puntos:
- "from s in names", estamos creando una variable local a la consulta, s, que representará a cada elemento en el array names. Bueno, esto es bastante similar a lo que estamos acostumbrados a utilizar en bucles foreach.
- "where s.length==5", ¡podemos utilizar cualquier tipo de expresión booleana como criterio de filtro! Fijaos que en este caso estamos usando la propiedad length de la clase string, pero podría ser cualquier cosa.
- "orderby s", podemos ordenarlas como creamos conveniente. Seguro, aunque no he podido comprobarlo, que la única limitación es que la expresión elegida implemente IComparable, para que el sistema pueda comparar valores.
- "select s.ToUpper()", indica lo que queremos obtener en la enumeración final.
- Bueno, aunque no aparezcan en el ejemplo anterior, es interesante saber que se pueden utilizar muchas más funcionalidades, ordenaciones inversas, agrupar los resultados, utilizar funciones de agregado, etc.
Ah, por cierto, no lo he comentado, pero se usa un generic para indicar el tipo contenido en la enumeración... de ahí el IEnumerable<string> del principio. Esto ha sido una de las grandes (y utilísimas) novedades del Framework 2.0, todavía reciente. Otro día hablaré de ellos, si me acuerdo.
Al comenzar este texto, hablaba de almacenes como una forma genérica de denominar a los contenedores de información sobre los que se pueden realizar queries, sin embargo el ejemplo sólo muestra cómo hacerlo sobre un array. ¿Y qué ocurre con los almacenes tradicionales, XML y bases de datos? Para ellos, se han creado XLinq y DLinq, implementaciones de LINQ destinadas a realizar consultas sobre estos dos tipos de fuente de datos, y siempre integrado en el lenguaje (nada de SQL o DOM), y de una forma muy parecida a lo visto con anterioridad.
LINQ está construido utilizando novedades que estarán presentes en C# 3.0 y VB.Net 9.0, como las expresiones lambda, árboles de expresiones, métodos de extensión, inicializaciones compuestas... todas ellas de entidad suficiente como para dedicarles un monográfico.
Desde luego, si hay algo que no se puede negar de estos muchachos de Microsoft es lo rápido que van. Y precisamente el problema es que, a veces, van demasiado rápido.
Aún no hay comentarios, ¡sé el primero!
Enviar un nuevo comentario