Blog del CIIN : LINQ

LINQ To SharePoint o LINQ4SP: Disponible la RC1!

Juan Carlos González Martín — Thu, 09 Oct 2008 22:34:27 GMT

Por fin, después de unos meses en lo que poco se ha sabido sobre la evolución de esta extensión de LINQ específicamente pensada para realizar consultas contra elementos de SharePoint, tenemos disponible la primera release candidate (RC1) de LINQ To SharePoint (LINQ4SP) . Podéis descargaros LINQ4SP de este enlace . Aparte de la noticia de la RC1 de LINQ4SP, creo que también es destacable que esta extensión de LINQ para SharePoint no esté incluida en el proyecto original de Codeplex , lo que creo que...(read more)

SharePoint y LINQ (I)!

Juan Carlos González Martín — Wed, 03 Sep 2008 18:25:30 GMT

Recientemente en uno de los proyectos en los que estamos trabajando surgió la necesidad de consultar datos de una lista de SharePoint y mostrarlos ordenados en base a uno de los campos de la misma. La primera alternativa en la que pensamos para solventar esta necesidad fue la de CAML , pero entre medias también pensamos que LINQ era otra opción interesante. La primeras preguntas que nos surgieron aquí fueron ¿cómo está la integración de SharePoint y LINQ? , ¿puedo consultar datos de una lista de...(read more)

ADO.NET EF: ...enredando y más ejemplos (I)

Juan Carlos González Martín — Thu, 29 May 2008 22:51:53 GMT

En el último post sobre ADO.NET EF & LINQ To SQL os hablaba de que ya había algún ejemplo concreto para la Beta1 del SP1 de Visual Studio 2008. En concreto os hablaba del ejemplo ADO.NET Entity Framework Query Samples que está disponible en MSDN Code Gallery. El caso es que el equipo de ADO.NET nos comenta en una de sus últimas entradas que se han actualizado todos los ejemplos que había para ADO.NET EF a la Beta1 del SP1 de Visual Studio 2008. Entre los ejemplos actualizados, y que tendré que...(read more)

ADO.NET Entity Framework y LINQ To SQL: Ejemplos de las novedades del SP1 Beta 1!

Juan Carlos González Martín — Wed, 21 May 2008 22:11:51 GMT

Poco a poco empiezan a aparecer ejemplos de algunos de los cambios que vienen con el SP1 Beta 1 de .NET Framework 3.5 . En esta ocasión, os dejo algunos recursos interesantes sobre el tema: ADO.NET Entity Framework Query Samples Beta Refresh 1, se trata de un proyecto de tipo Windows Forms que podéis encontrar en MSDN Code Gallery . La aplicación permite probar una serie de consultas Entity SQL y LINQ to Entities al modelo definido sobre la base de datos Northwind. Documentación en MSDN sobre ADO...(read more)

VLINQ: Diseñador de consultas para LINQ To SQL!

Juan Carlos González Martín — Sun, 13 Apr 2008 21:45:46 GMT

Si hace unos meses hablábamos de una útil e imprescindible herramienta para probar nuestras consultas LINQ como es LINQPad, hace un rato me he encontrado otro diseñador de consultas específico para LINQ To SQL, pero que se diferencia de LINQPad en qué se trata de un diseñador que se integra con Visual Studio 2008 como un Add-In más y que nos ayuda en el diseño de dichas consultas. Se trata del proyecto VLINQ, que durante 6 meses fue desarrollado y liderado por un equipo de desarrollo francés en colaboración con Microsoft. Os podéis descargar VLINQ de este enlace.

CIIN & Nuberos.NET: LINQ & ADO.NET Entity Framework!

Juan Carlos González Martín — Mon, 17 Mar 2008 12:57:42 GMT

Después del retorno y primer evento de Nuberos.Net en 2008 (sobre Silverlight y en el que José María Cuesta nos contó las posibilidades de Silverlight y surgieron discusiones interesantes sobre las otras grandes opciones que hay en el mercado: SVG y Flex), estamos que no paramos y ya tenemos en marcha el evento correspondiente a este mes de marzo: LINQ & ADO.NET Entity Framework. Aquí van los detalles del evento:

Conoce LINQ, el nuevo framework que habilita la definición de consultas integradas en el lenguaje y permite crear querys contra objetos de memoria, bases de datos relacionales, documentos XML, y otros elementos. Haremos un recorrido práctico de las principales características y novedades de este nuevo lenguaje que vendrá con la nueva versión de Visual Studio, y que se apoya en las innovaciones de lenguaje introducidas en las nuevas versiones de C# (3.0) y VB (9.0). Veremos alguno de los sabores de LINQ como: LINQ To Objects, LINQ To SQL o LINQ To Entities...y completaremos el evento con la nueva revolución tecnológica en el acceso a datos en plataforma .NET: ADO.NET Entity Framework. Ven con nosotros y preparate para la gran revolución: Are you ready?

Datos de interés:

Audiencia: Desarrolladores, Jefe de Proyecto
Requistos previos: Conocimientos del entorno Visual Studio 2005 / Visual Studio 2008
Fecha: Jueves, 27 de marzo
Hora: 19:00 a 21:00
Precio: gratuito
Ponente: Juan Carlos González Martín (Centro de Innovación en Integración, CIIN).
Lugar:

AGENCIA DE DESARROLLO LOCAL DE SANTANDER - Servicio de Promoción de Empresas y Autoempleo

Bajos del Mercado de México

c/ Alta 133

39008 Santander CANTABRIA

España

Más información y registro al evento en este enlace.

Extensibilidad de LINQ: LINQ Flavours!

Juan Carlos González Martín — Sun, 02 Mar 2008 11:55:05 GMT

Como sabéis, una de las grandes novedades de Visual Studio 2008 y de .NET Framework 3.5 es el Language Integrated Query (LINQ) que habilita la definición de consultas integradas en el lenguaje de programación y es una de las piedras angulares de las nuevas versiones de C# y VB. Precisamente, muchas de las innovaciones que se han introducido en estas nuevas versiones son la base de LINQ, y el resumen de las mismas es el siguiente:

Ahora bien, además de apoyarse en estas innovaciones, LINQ define un modelo ampliable y extensible para definir nuestras propias consultas o API's de consulta, de manera que podemos ir más allá de las extensiones para LINQ que por defecto vienen con Visual Studio 2008, .NET Framework 3.5 y ADO.NET Entity Framework:

LINQ To Objects y LINQ To XML para trabajar con fuentes de datos no relacionales.
Para ADO.NET tenemos:
- LINQ To Datasets
- LINQ To SQL
- LINQ To Entities

Tras esta pequeña introducción, la idea de este post es hacer una recopilación y recorrido por las extensiones que para LINQ se han ido creando durante los últimos dos años, algunos de los cuales presentó Octavio Hernández en su charla dentro del lanzamiento de Visual Studio 2008, SQL Server 2008 y Windows Server 2008 (me hubiera gustado estar en el evento y asistir a esta charla).. Empecemos.

Proveedores de LINQ Personalizados

Como comentábamos, LINQ es un modelo completamente extensible y aquí están algunas de las extensiones que he ido descubriendo cuando he preparado seminarios de LINQ, en los propios cursos de LINQ,...

PLINQ, o Parallel LINQ. Concebido inicialmente como un proyecto de investigación de Microsoft, esta extensión permite que las consultas LINQ se puedan ejecutar en varios procesadores. La concepción en cuanto a uso de PLINQ es similar a la de LINQ To Objects y LINQ To XML, sin embargo, PLINQ necesita especificar de alguna forma que las consultas se van a ejecutar en varios procesadores: el método de extensión AsParallel...un ejemplo de como sería la sintaxis de PLINQ es el siguiente:

IEnumerable<T> data = ...;
var q = from x in data.AsParallel() where p(x) orderby k(x) select f(x);
foreach (var e in q) a(e);

CLINQ (que no es Continuous LINQ, proyecto en Codeplex que he descubierto esta tarde...), en este caso nos referimos al proyecto CLINQ que Tomas Petricek, MVP de C#, inició para que el lenguaje C++ tuviese soporte para LINQ (de hecho, cualquier lenguaje que soporte la CLS puede añadir sus propias implementaciones de LINQ). Por ejemplo, mediante las extensiones desarrolladas por Tomas para C++, la consulta a una BD en C++ quedaría:

// create connection to database
NorthwindData db(".. connection string ..");

// declare database query
Expr<Customers^> cvar = Var<Customers^>("c");
CQuery<String^>^ q = db.QCustomers
  ->Where(clq::fun(cvar, cvar.City == "London"))
  ->Select(clq::fun(cvar, 
      cvar.ContactName + Expr<String^>(", ") + cvar.CompanyName));

// execute query and output results
for each(String^ s in q->Query)
  Console::WriteLine(s);

Tomas ha creado una sección en Codeplex dedicada a extensiones para LINQ. De momento está incluido CLINQ, pero según el autor, poco a poco irá añadiendo alguna más.

LINQ To SharePoint, como no podía ser de otro modo, existe desde hace tiempo un proveedor de LINQ específicamente pensado para realizar consultas contra listas de SharePoint usando sintaxis LINQ. Esta extensión tiene su sección correspondiente en Codeplex, y además de habilitar consultas LINQ, dispone de una herramienta de creación de clases sobre las que definir consultas a partir de listas de SharePoint: SpMetal (misma idea que el SQLMetal de LINQ To SQL). Actualmente en Codeplex tenemos disponble la versión v0.2.4.0 alfa preparada para .NET Framework 3.5 y Visual Studio 2008. Un ejemplo de uso de esta extensión es el siguiente:

var ctx = new SharePointDataContext(new Uri(http://fileserver));
ctx.Credentials = new NetworkCredential("dimitri","LinqToSharePoint");

var books = ctx.GetList<Books>();

var res = from b in books
select new { b.Title, b.Author};

foreach (var u in res)
Console.WriteLine(u);

LINQ To Amazon, en este caso se trata de una extensión creada por uno de los autores del libro LINQ in Action, Fabrice Marguerie, que permite consultar libros de Amazon mediane LINQ. De hecho, esta extensión permite consultas LINQ contra un cierto catálogo de libros, obteniendo las estructuras XML que devuelven los servicios web de Amazon. Un ejemplo de uso de esta extensión sería el siguiente:

var query =
from book in new Amazon.BookSearch()
where
    book.Title.Contains("ajax") &&
    (book.Publisher == "Manning") &&
    (book.Price <= 25) &&
    (book.Condition == BookCondition.New)
select book;

var sequence = query.ToSequence();

LINQ To NHibernate, esta extensión permite escribir consultas LINQ que son posteriormente traducidas a Criteria Queries que son ejecutadas por un objeto de Sesión NHibernate. Todo el código de este proyecto está accesible en este enlace...y aunque un poco fuera de tópico, fijaros en la sorpresa que os encontraréis si entráis en la página principal Hooked on LINQ: LINQ Reference Stuff...pero fijaros en el formato ;) :

Desde luego, las tazas son "molonas", creo que me las voy a pedir por esto y porque merece la pena darle soporte a Hooked on LINQ. Están realizando un excelente trabajo.

DbLINQ Project, se trata de un proyecto en Code2Code en el que podéis encontrar las bases de un proveedor LINQ para bases de datos Oracle, MySQL y PostgreSQL. Como se comenta en la página del proyecto DbLINQ, se garantiza que las consultas simples funcionarán sin problemas, aunque no las complejas...precisamente la disponibilidad del código habilita que los desarrolladores puedan testear bien estas extensiones y evaluar, extender y corregir el comportamiento del proveedor al modelar consultas complejas. Las releases del código están en este enlace. Todo el proyecto se está desarrollando bajo licencia MIT para ser compatible con el proyecto Mono.
LINQ To LDAP, se trata de un proveedor capaz de enviar consultas LINQ a un directorio activo sobre LDAP partiendo de las expresiones de filtrado en LDAP que aparecen en la RFC 2254. Un ejemplo de uso de este proveedor creado por Bart de Smet's es el siguiente:

LINQ To TFS, esta nueva extensión creada por Octavio Hernández,y de la que tuve conocimiento a raíz del post de Octavio, la podemos encontrar en Codeplex y se trata de un proveedor de LINQ preparado para consultar el repositorio de Team Foundation Server en el que se hace el almacenamiento y control de versiones de Work Items.
LINQ To Flickr, esta extensión al estilo de LINQ To Amazon permite consultar fotografías de Flickr por tag, fecha de creación, identificador de usuario o título. El autor de esta extensión es el egipcio
Mohammed Hossam El-Din.
LINQ To JSON, se trata de una extensión para JSon.NET que permite crear y consultar objetos JSON mediante consultas de LINQ. Su creador es James Newton, y esta extensión permite trabajar con objetos JSON de manera similar a como LINQ To XML permite manipular estructuras XML.

JObject o = JObject.FromObject(new

{

channel = new

{

title = "James Newton-King",

link = "http://james.newtonking.com",

description = "James Newton-King's blog.",

item = from p in posts orderby p.Title

select new

{

title = p.Title,

description = p.Description,

link = p.Link,

category = p.Categories

}

});

BLINQ, en este caso no se trata de una extensión en sí, sino de una herramienta (descontinuada) que permite generar sitios ASP.NET para visualizar, crear y manipular datos obtenidos mediante LINQ a partir de un cierto esquema relacional.

Y como podéis ver en este recopilatorio Hosam Kamel, el listado completo de proveedores de LINQ que podemos encontrar en la red es este:

LINQ to Amazon.
LINQ to Active Directory.
LINQ to Bindable Sources (SyncLINQ).
LINQ to CRM.
LINQ to Geo - Language Integrated Query for Geospatial Data.
LINQ to Excel
LINQ to Expressions (MetaLinq).
LINQ to Flickr.
LINQ to Google.
LINQ to Indexes (LINQ and i40).
LINQ to IQueryable.
LINQ to JSON.
LINQ to LDAP.
LINQ to NHibernate.
LINQ to JavaScript.
LINQ to Lucene.
LINQ to Metaweb(freebase).
LINQ to MySQL, Oracle and PostgreSql (DdLINQ project).
LINQ to RDF Files.
LINQ to Sharepoint.
LINQ to SimpleDB.
LINQ to Streams.
LINQ to WebQueries.
LINQ to WMI.
LINQ to XtraGrid.

Está claro que el título del post de Hosam, LINQ To Everything, es muy apropiado.

Creación de proveedores de LINQ personalizados

Además de las extensiones comentadas, cualquier desarrollador puede crear las suyas propias. De hecho, estos son algunos ejemplos que muestran como habría que proceder:

Escribir un proveedor personalizado desde cero: en esta entrada tenéis un ejemplo.
Escribir proveedores personalizados partiendo del proyecto LINQExtender de Codeplex. El ejemplo en este caso está aquí.

Nota: Ambos ejemplos han sido realizados por Mehfuz Hossain.

...¿y existe LINQ fuera de la plataforma Microsoft? Buena pregunta, y la respuesta es que sí. De hecho, en el mundo Java ya ha aparecido LINQ for Java o Quaere. Como se comenta en este post, Quaere is a DSL que añade sintaxis de consultas tipo SQL en el desarrollo de aplicaciones Java basándose en el modelo del proyecto LINQ ;)...como muestra, un pequeño ejemplo de Quaere:

Integer[] numbersA = {0, 2, 4, 5, 6, 8, 9};
Integer[] numbersB = {1, 3, 5, 7, 8};
Iterable<Variant> pairs =
    from("a").in(numbersA). 
    from("b").in(numbersB).
    where(lt("a", "b")).
    select(
        create(
            property("a"),
            property("b")
        )
    );

Sin más, hasta aquí llega este post en el que he intentado reflejar la extensibilidad de LINQ. Espero que os haya resultado interesante.

ADO.NET Entity Framework: eSqlBlast...no es tan bueno como LINQPad, pero casi e igual de útil...

Juan Carlos González Martín — Mon, 11 Feb 2008 22:45:50 GMT

En el último post sobre ADO.NET Entity Framework os comentaba otras formas de realizar consultas contra un Entity Data Model (EDM) de ADO.NET Entity Framework: Entity SQL (eSQL) y Object / Entity Services. También os comentaba que existía una herramienta interesante de la que os iba a hablar en el siguiente post sobre ADO.NET Entity Framework...pues dicho y hecho. La herramienta en cuestión forma, como no podía ser de otro modo, de la correspondiente sección de Codeplex dedicada a ejemplos sobre la nueva versión de ADO.NET: ADO.NET Samples. Y la herramienta en cuestión es eSQLBlast, la cuál os podéis descargar en la pestaña releases de esta sección de Codeplex. Como se indica en la página de descarga, eSqlBlast es una suite de herramientas diseñada para editar y ejecutar consultas eSQL contra EDM's de ADO.NET Entity Framework. La versión actual de eSqlBlast funciona perfectamente (como os demostraré) con la Beta 3 de ADO.NET Entity Framework, y la versión descargable de la misma es el proyecto de Visual Studio 2008 que hay que compilar para poder empezar a probar la herramienta. Finalmente, y no menos importante, el creador de esta genial herramienta que está sin duda al mismo nivel que LINQPad (aunque esta le gana en el aspecto gráfico): Zlatko Michailov, Program Manager de Microsoft. Sin más, veamos el funcionamiento y utilidad de eSqlBlast.

eSqlBlast en acción

Tras compilar el proyecto y ejecutar eSqlBlast, lo primero que tenemos que hacer es especificar la cadena de conexión al EDM correspondiente. Para ello, y siguiendo la pauta explicada en el post anterior para escribir cadenas de conexión a EDM's para eSQL, eSqlBlast necesitará en primer lugar el connection string a la BD, y a continuación los archivos de metadatos que describen el modelo (archivos .csdl, .msl, y .ssdl):

Data Source=.\SQLEXPRESS;AttachDbFilename="C:\Documents and Settings\Administrator\Desktop\Labs LINQ\Soluciones & Demos\BD\CLIENTES.mdf";Integrated Security=True;Connect Timeout=30;User Instance=True;MultipleActiveResultSets=True

Una vez que hemos especificado la cadena de conexión, basta con pulsar CONNECT para que eSqlBlast se conecte satisfactoriamente al EDM especificado:

Una vez conectados, ¿que nos permite hacer eSqlBlast con el EDM? Pues la respuesta es que tres cosas:

Por un lado nos permite inspeccionar el modelo a través de la pestaña Model. Aquí tendremos que especificar el archivo de metadatos que describe a nivel conceptual el EDM (en este caso el archivo .csdl), y tras pulsar RENDER tendremos la descripción del EDM desde un punto de vista conceptual:

Como veis, eSqlBlast nos da la misma vista que tenemos con el Model Explorer en Visual Studio 2008, de manera que dado un cierto EDM podremos inspeccionar las entidades que lo componen, el tipo de las mismas en cuanto a descripción de sus miembros, si hay tipos complejos, y las asociaciones existentes.

Realizar y ejecutar una consulta eSQL contra el modelo. Así, por ejemplo:

SELECT clientes.ID_Cliente,clientes.DireccionCliente,clientes.CiudadCliente
FROM BD_Clientes_Entities.Md_Clientes as clientes

Visualizar los resultados de la ejecución de la consulta eSQL contra el EDM. En este caso, no solo se visualiza el resultado de la ejecución eSQL, sino también la propia sentencia eSQL, el número de filas devueltas y la consulta T-SQL real que se envía a la BD (por cierto, tengo que encontrar en el código del proyecto como se saca esto pues lo desconozco para ADO.NET Entity Framework).

Y hasta aquí llega este post sobre eSqlBlast. Sin duda una herramienta útil que nos permite probar las características de eSQL y que además nos da una idea de hasta que punto es extensible ADO.NET Entity Framework. Espero que el post os haya resultado interesante.

ADO.NET Entity Framework: LINQ To Entities, Entity SQL y Entity Services (II)

Juan Carlos González Martín — Thu, 07 Feb 2008 23:30:31 GMT

Hace un par de semanas escribía un primer post sobre ADO.NET Entity Framework complementario a la estupenda serie de posts que sobre esta temática ha venido realizando Jorge Serrano. En este post veíamos los fundamentos de ADO.NET Entity Framework, como construir un Entity Data Model (EDM) a partir de una cierta BD, y como realizar operaciones (de selección, inserción, actualización o borrado) mediante LINQ To Entities. La idea de este post es mostraros la flexibilidad de ADO.NET Entity Framework en cuanto a que para operar contra el EDM no sólo disponemos de LINQ To Entities, sino que tenemos otras dos opciones: Entity SQL (eSQL) y Entity Services. Empecemos.

Recordando los componentes de Entity Framework

Aunque Jorge Serrano ya nos explicó los componentes de un EDM, no está de más hacer un pequeño repaso de los mismos. Como ya comenté en el post anterior, una de las ideas claves de la nueva versión de ADO.NET es ahorrar tiempo a los desarrolladores a través de reducir la cantidad de código necesario para acceder a los datos, reducir el mantenimiento, facilitar la persistencia de los datos, etc. Todo ello es posible a través de la definición del correspondiente EDM, el cuál podemos consultar de las tres formas comentadas. Como siempre, una imagen vale más que 1000 palabras:

Como veis, la clave de la realización de operaciones contra el EDM mediante cualquiera de los tres métodos está en un nuevo proveedor de datos: el Entity Client. Este proveedor permite interactuar contra el EDM mediante eSQL, que como veremos se trata de un nuevo lenguaje muy similar a T-SQL (sólo que las sentencias se ejecutan contra el EDM), Entity Services o LINQ To SQL que en este caso interactúan con el EDM a través de un objeto ObjectQuery (que representa una consulta que devuelve un cierto objeto con los datos).

Como nos comentaba Jorge Serrano, para entender como se realizan las operaciones contra el EDM es necesario conocer los componentes claves del mismo en la forma de tres capas:

Conceptual, definida mediante un archivo .CSDL (Conceptual Schema Definition Language, o en otras palabras un archivo XML con información relativa a las entidades del modelo), el cuál incluye las entidades y las relaciones tal y como la capa de negocio de la aplicación las conoce.
De asignación, definida con MSL (Mapping Schema Language, de nuevo otro XML con la información de mapeo entre la capa conceptual y la capa lógica), establece el mapeo entre las entidades del modelo conceptual y sus correspondencias con la BD.
Lógica, definida con SSDL (Store Schema Definition Language), y representa el esquema de la BD

Realizando consultas con eSQL

Como hemos comentado, este nuevo lenguaje similar a T-SQL nos permite interactuar con el EDM de manera similar a como estábamos acostumbrados a realizar operaciones contra una cierta BD en ADO.NET 2.0: define objetos específicos para la conexión al EDM, objeto EntityConnection, para devolver los datos en una consulta de selección, objeto DBDataReader, o ejecutar comandos eSQL contra el modelo...todas las clases que siguen estos objetos están definidas en el System.Data.EntityClient. Por lo tanto, el primer paso para realizar operaciones contra el EDM vía eSQL es instanciar la clase EntityConnection especificando la correspondiente cadena de conexión, que por cierto no es nada trivial:

EntityConnection ecConexion = new EntityConnection( @"metadata=.\CLIENTES_EDM.csdl|.\CLIENTES_EDM.ssdl|.\CLIENTES_EDM.msl;provider=System.Data.SqlClient;" + "provider connection string='Data Source=.\\SQLEXPRESS;" + "AttachDbFilename=\"C:\\Documents and Settings\\Administrator\\Desktop\\Labs LINQ\\Soluciones & Demos\\BD\\CLIENTES.mdf\";" + "Integrated Security=True;Connect Timeout=30;User Instance=True;MultipleActiveResultSets=True'" );

ecConexion.Open();

Como se observa, en la cadena de conexión es necesario especificar los distintos archivos de metadatos que configuran las distintas capas del EDM, así como la cadena de conexión para la BD. Una vez que hemos definido la cadena de conexión para el objeto EntityConnection, abrimos la conexión...esto se parece mucho al clásico ADO.NET...el siguiente paso es definir un comando eSQL mediante un objeto de tipo EntityCommand...dicho y hecho:

EntityCommand ecComando =
new EntityCommand("SELECT clientes.ID_Cliente,clientes.DireccionCliente," +
"clientes.CiudadCliente FROM Entidades_BD_Clientes.Md_Clientes as clientes", ecConexion);

Lo que hemos hecho es definir una sentencia eSQL, que parece T-SQL, pero que no lo es porque estamos realizando las consultas contra una entidad del EDM (en este caso Md_Clientes que pertenece al EDM Entidades_BD_Clientes)...¿y cómo ejecutamos este comando? Pues a través del método ExecuteReader (para este caso en el que estamos realizando una Select) del objeto EntityCommand anterior. Lógicamente los resultados los recogeremos para su procesado en un objeto de tipo DbDataReader:

using (DbDataReader dbdrReader =
    ecComando.ExecuteReader(CommandBehavior.SequentialAccess))
{
    while (dbdrReader.Read())
    {
        Console.WriteLine(dbdrReader["ID_Cliente"] + ", " +
            dbdrReader["DireccionCliente"] + " " +
            dbdrReader["CiudadCliente"]);
    }
}

Sin duda espectacular...y la salida por pantalla correspondiente es la siguiente:

Realizando consultas con Entity Services (u Object Services)

Finalmente, y para concluir el post, vamos a ver la tercera opción para realizar operaciones contra un EDM: los Entity Services (u Object Services). Esta alternativa permite devolver estructuras de información del EDM a través del método CreateQuery asociado al objeto ObjectContext (y que implementa una interfaz de tipo ObjectQuery<T>), que acepta una instrucción eSQL o LINQ To Entities con parámetros que define una consulta que recuperará una cierta lista de entidades. Así, un ejemplo de ejecutar una sentencia eSQL con Entity Services sería:

Console.WriteLine("Entity Services");
string sCiudad = "Santander";
//ObjectQuery
ObjectQuery<ClientesModel.Md_Clientes> esQuery =
    ModeloClientes.CreateQuery<ClientesModel.Md_Clientes>
    ("SELECT VALUE c FROM Md_Clientes AS c WHERE c.CiudadCliente=@CiudadCliente",
    new ObjectParameter("CiudadCliente",sCiudad));

foreach (var c in esQuery)
{
Console.WriteLine(c.ID_Cliente);
}

Y la correspondiente salida por pantalla sería la siguiente:

Y hasta aquí la segunda entrega de la serie de posts sobre ADO.NET Entity Framework. En el siguiente post os presentaré una utilidad muy interesante para realizar operaciones contra el modelo. Espero que el post os haya resultado interesante.

Novedades en C# 3.0: Propiedades automáticas...¿Se permiten propiedades automáticas Read-Only o Write-Only?

Juan Carlos González Martín — Mon, 04 Feb 2008 12:15:34 GMT

Hace unas semanas José M. Alarcón nos hablaba de una de las innovaciones en el lenguaje que aparecen en C# 3.0: las propiedades automáticas. En ese post, nos explicaba como de manera muy sencilla, rápida e intuitiva podemos definir una propiedad de manera automática utilizando una sintaxis como la siguiente:

public string Nombre { get; set; }

De manera que es el compilador el que generará todo el resto de elementos que constituyen la variable privada. Ahora bien, (y esta cuestión surgió en el último seminario que sobre Visual Studio 2008 hemos impartido en el CIIN) una pregunta que nos pueden hacer es la siguiente: ¿Es posible definir propiedades automáticas que sean Read-Only o Write-Only? La respuesta es que no, de hecho en esta entrada ya se adelantaba que en las propiedades automáticas es obligatorio tener declarado un "getter" y un "setter", es decir, no se permiten propiedades automáticas Read-Only o Write-Only...y como una imagen a veces vale más que mil palabras, aquí tenéis la correspondiente prueba:

Dynamic LINQ o como construir consultas dinámicas con LINQ!

Juan Carlos González Martín — Tue, 29 Jan 2008 16:35:00 GMT

Una de las preguntas más típicas que surgen cuando he impartido algún seminario en el que se trata algún tema de LINQ es como se pueden construir consultas dinámicas con LINQ, porque aparentemente LINQ no parece admitir este escenario puesto que la idea es escribir lo que el genial (uno de los grandes "culpables" de el diseño y creación de LINQ) Scott Guthrie denomina consultas "type-safe", es decir, consultas en las que tenemos soporte para intellisense, refactoring y comprobación de tipos en tiempo de compilación...pero, que pasa (escenario bastante habitual) si necesito una cierta flexibilidad que implique poder construir consultas más o menos dinámicas (por ejemplo, realizar consultas cambiantes en función de los datos de negocio seleccionados por el usuario de una cierta aplicación)...la clave está en la palabra "aparentemente", puesto que como viene siendo habitual en los últimos tiempos, LINQ y las innovaciones en el lenguaje proporcionan los elementos adecuados para construir estas consultas dinámicas. En este caso estamos hablando de la LINQ Dynamic Query Library (System.Linq.Dynamic), de la que tenemos ejemplos de uso en la página de ejemplos descargables de VS 2008, o bien:

Si nos bajamos cualquiera de los archivos de los vínculos anteriores, veremos que se trata de un conjunto de ejemplos sobre LINQ, siendo uno de los mismos el de Dynamic Query. Al abrir la solución, podremos ver que aparte de hacer referencia a la librería comentada (y que es una clase del proyecto de ejemplo que podemos usar), la construcción de una consulta LINQ dinámica tendría la siguiente forma:

Northwind db = new Northwind(connString);
db.Log = Console.Out;

var query =
    db.Customers.Where("City == @0 and Orders.Count >= @1", "London", 10).
    OrderBy("CompanyName").
    Select("New(CompanyName as Name, Phone)");

Como vemos, la clave está basada en la definición de expresiones tipo cadena, en lugar de código...¿y cómo es posible esto? Pues a través de una serie de métodos de extensión que permiten construir consultas en base a expresiones en cadena en lugar de las habituales expresiones lambda. Junto con el ejemplo de uso e la Dynamic Query Library viene algo de documentación sobre como utilizarla. Finalmente, comentaros que se puede utilizar para cualquier extensión de LINQ: LiNQ To Objects, LINQ To SQL, LINQ To XML, ...

ADO.NET Entity Framework: LINQ To Entities, Entity SQL y Entity Services (I)

Juan Carlos González Martín — Fri, 25 Jan 2008 00:26:24 GMT

Para complementar la serie de post que sobre LINQ To Entities y Visual Basic 2008 ha iniciado Jorge Serrano, en este primer post sobre ADO.NET Entity Framework os daré el punto de vista análogo a lo que Jorge ha explicado pero aplicado a la nueva versión de C # que aparece como una de las grandes novedades de Visual Studio 2008: C # 3.0. Antes de entrar en materia, la primera pregunta que se nos puede venir para los profanos en la materia es ¿Qué es ADo.NET Entity Framework? Como se describe en este artículo, una de las metas principales de la nueva versión de ADO.NET es elevar el nivel de abstracción de la programación contra fuentes de datos a través de la eliminación del "vacío" existente entre los modelos de datos y los lenguajes de programación. Y ¿Cómo es posible esto? A través de dos innovaciones claves de las que ya se ha hablado mucho en Geek.Ms: LINQ y ADO.NET Entity Framework. Precisamente éste último (Entity Framework) es un nuevo componente que aparece en familia de tecnologías ADO.NET, que habilitará acceso a datos mediante LINQ utilizando: LINQ To SQL, LINQ To DataSet y/o LINQ To Entities. Si tuviésemos que resumir las características de este Entity Framework, sin duda destacaríamos los siguientes puntos:

Se trata de un Framework que permite manipular y acceder a los datos como clases .NET.
Permite realizar un modelado de datos a nivel conceptual, es decir, habilita la separación de las aplicaciones y los esquemas de BD.
Permite una mejor interactuación de los datos con el entorno .NET: Se interactúa con objetos, frente a hacerlo con filas y columnas.
Proporciona una serie de servicios en tiempo de ejecución y en tiempo de diseño que permite a los desarrolladores describir los datos de la aplicación e interactuar con ellos a un nivel de abstracción conceptual claramente alineado con el concepto de implementación de aplicaciones de negocio, y que además ayuda a aislar la aplicación respecto a los esquemas de base de datos (BD) sobre los que se ha definido.
Como comentó Jorge en su post, se apoya en LINQ para definir las consultas a objetos del esquema EDM (Entity Data Model).
Supone una capa más, pero independiza las aplicaciones de el esquema de BD subyacente, independientemente de la tecnología de BD que se esté utilizando.

¿En qué se traduce esta independencia con el esquema de BD y la tecnología de BD? Pues básicamente en una arquitectura dividida en dos partes diferenciadas, Modelo de datos y Modelo Conceptual (EDM), en la que el paso de una parte a otra se realiza a través del correspondiente mapeo. Para realizar este mapeo se utilizan proveedores .NET que permiten interactuar con los datos en cada uno de las partes:

La idea es que el provider .NET de la capa de datos se encarga de traducir las operaciones de datos realizadas en la capa conceptual a un lenguaje entendible por la BD (lógicamente T-SQL). Por su parte, el proveedor .NET (EntitySQL) de la capa conceptual traduce las consultas LINQ realizadas en las aplicaciones a las correspondientes instrucciones que interactúen con el modelo conceptual definido mediante el proceso de mapeo.

Una vez repasadas las principales ideas y conceptos que hay bajo ADO.NET Entity Framework, vamos a ver en la práctica en que consiste trabajar en un nivel de abstracción superior. Los requisitos para poder probar ADO.NET Entity Framework ya los comentamos en este post.

Definiendo el EDM

Cómo comentó Jorge en su post, el primer paso para trabajar con ADO.NET Entity Framework pasa por crear un modelo de entidades a partir de un cierto esquema de BD. Para ello añadimos al proyecto un elemento de tipo ADO.NET Entity Data Model con lo que se iniciará un asistente que nos guiará en la creación del modelo a partir de:

Especificar la opción de generación del EDM (a partir de una BD o bien un EDM vacío.
Especificar la cadena de conexión a la BD (que como siempre, puede ser un archivo físico o bien una instancia de SQL Server).
Especificar que objetos de la BD queremos que formen de nuestro EDM (en este caso, tablas y procedimientos almacenados).

Tras pulsar Finish en la última pantalla del asistente, ya tendremos creado el modelo de entidades que en esencia es un fichero .edmx que contiene toda la definición del modelo. Si inspeccionamos el modelo veremos:

Se han generado tantas entidades como tablas de la BD relacional.
Al seleccionar cada entidad, podremos ver los detalles de la misma en cuanto a miembros y la correspondencia de los campos de la entidad con sus equivalentes en la tabla de la BD.
El explorador del modelo nos permitirá ir navegando por los componentes del mismo: entidades, asociaciones entre entidades, funciones, etc.
Finalmente, para tener una idea del código generado por el asistente, basta con que nos vayamos al Class Viewer o al Object Browser e inspeccionemos los distintos elementos generados.

Consultando Entidades

Como ya comentó Jorge, una de las formas que tenemos para definir consultas contra el EDM es a través de LINQ To Entities que nos dota de toda la potencia y capacidades de LINQ sobre ADO.NET Entity Framework, así como funcionalidad de ORM (Object Relational Model), de manera que los desarrolladores pueden materializar sus entidades en tipos del CLR y programar de forma más sencilla contra el EDM y la base de datos. Lo primero que tenemos que hacer es añadir a nuestra aplicación las sentencias using necesarias:

using System.Data.EntityClient;
using System.Data.Common;
using System.Data;

El siguiente paso consiste en instanciar el modelo EDM creado y definir la correspondiente consulta LINQ. Por ejemplo:

//Instancia del modelo de entidades creado

ClientesModel.Entidades_BD_Clientes ModeloClientes=

new ClientesModel.Entidades_BD_Clientes();

//Consulta de entidades!

var clientes =

(from c in ModeloClientes.Md_Clientes

from v in ModeloClientes.Md_Vehiculos

where c.ID_Cliente==v.ID_Cliente

select c).Distinct();

Console.WriteLine("***********Consulta LINQ To Entities***********");

foreach (var c in clientes)

{

Console.WriteLine("NIF={0}, Direccion={1}",

c.ID_Cliente, c.DireccionCliente + " " + c.CiudadCliente);

}

Console.ReadLine();

Como vemos, lo primero que hacemos es crear un objeto denominado ClientesModel que es una instacia de ClientesModel.Entidades_BD_Clientes(). La primera parte se corresponde a nuestro EDM, y la segunda (Entidades_BD_Clientes) es un objeto que ha sido añadida al modelo en el momento de su creación y que hereda de ObjectContext, clase que se encarga de mantener la conexión e información de los metadatos necesaria para leer, escribir, actualizar o borrar entidades en la BD. Además, también referencia la clase ObjectStateManager que se encarga de aspectos relacionados con el tracking de cambios y la resolución de identidades...esto ya lo vimos con LINQ To SQL: si una consulta nos devuelve un objeto del modelo, este es persistido a través de otras consultas mientras que exista el objeto de contexto correspondiente. Sin más, la salida por pantalla que se obtiene de la consulta anterior es:

Operaciones de actualización, insercción y borrado de entidades

Como ocurría con LINQ To SQL, ADO.NET Entity Framework a través de LINQ To Entities nos permite realizar de manera sencilla operaciones de actualización, inserción o borrado a través de la interactuación con las entidades del modelo. Para actualizar una entidad, basta con crear una instancia de la misma a partir de realizar una consulta a la BD de los resultados a actualizar (consulta con C # plano o mediante query expression):

//Actualización

Console.WriteLine("***********Actualizando las Entidades***********");

ClientesModel.Md_Clientes ClienteToUpdate =

ModeloClientes.Md_Clientes.First(

c => c.ID_Cliente == "71505286B");

ClienteToUpdate.CiudadCliente="Torrelavega";

ModeloClientes.SaveChanges();

foreach (var c in clientes)

{

Console.WriteLine("NIF={0}, Direccion={1}",

c.ID_Cliente, c.DireccionCliente + " " + c.CiudadCliente);

}

Como vemos, la clave para llevar los datos a la BD está en el método SaveChanges(). Por otro lado, tal y como sucede con el caso de la primera consulta, gracias a que el objeto ObjectStateManager de encarga del tracking de los datos, los antiguos y nuevos valores se mantienen en el contexto de la aplicación y los cambios se pueden guardar en la BD. La salida por pantalla de la operación de actualización es:

Para añadir una entidad nueva basta con crear una nueva instancia de la entidad deseada, especificar sus propiedades y añadirla al modelo:

//Insercción

Console.ReadLine();

Console.WriteLine("***********Añadiendo nuevas Entidades***********");

ClientesModel.Md_Clientes ClienteToAdd =

new ClientesModel.Md_Clientes();

ClienteToAdd.ID_Cliente = "72678934C";

ClienteToAdd.DireccionCliente = "C/ Ordoño II";

ClienteToAdd.CiudadCliente = "León";

ModeloClientes.AddToMd_Clientes(ClienteToAdd);

ModeloClientes.SaveChanges();

var AllClients =

(from c in ModeloClientes.Md_Clientes

select c);

foreach (var c in AllClients)

{

Console.WriteLine("NIF={0}, Direccion={1}",

c.ID_Cliente, c.DireccionCliente + " " + c.CiudadCliente);

}

Console.ReadLine();

En este caso la clave para preservar los datos en la BD está en el método AddToMd_Clientes() que es generado automáticamente en el modelo de creación del EDM y que recibe un objeto del tipo de la entidada a añadir, así cómo en el método SaveChanges(). La correspondiente salida por pantalla es:

Para realizar el borrado de una entidad, se sigue la misma filosofía que para el caso de la actualización e insercción, sólo que en este caso se utiliza el método DeleteObject() y a continuación SaveChanges() para poder llevar los datos a la BD:

//Borrado

Console.WriteLine("***********Borrado de clientes***********");

ClientesModel.Md_Clientes ClienteToDelete =

ModeloClientes.Md_Clientes.First(

c => c.ID_Cliente == "72678934C");

ModeloClientes.DeleteObject(ClienteToDelete);

ModeloClientes.SaveChanges();

Console.WriteLine("Clientes después de borrar");

foreach (var c in AllClients)

{

Console.WriteLine("NIF={0}, Direccion={1}",

c.ID_Cliente, c.DireccionCliente + " " + c.CiudadCliente);

}

Console.ReadLine();

La correspondiente salida por pantalla es:

Y hasta aquí este primer post sobre ADO.NET Entity Framework en la práctica. En el próximo post os introduciré el concepto de Entity SQL y Entity Services, y os mostraré una interesante herramienta que tenemos disponible para facilitar la construcción de consultas contra un EDM. Espero que el post os haya resultado interesante.

ADO.NET Entity Framework: Lo que necesitas para empezar!

Juan Carlos González Martín — Wed, 16 Jan 2008 12:01:53 GMT

Si has oído hablar de ADO.NET Framework (por cierto, no esperes que aparezca como parte de .NET Framework 3.5) y estás pensando en probarlo (en ello estoy...), lo primero que necesitas es instalarte en tu entorno los elementos necesarios:

ADO.NET Entity Framework, del que actualmente tenemos la versión Beta3 (liberada en diciembre como nos comentó Bruno). El enlace de descarga de la Beta 3 es este.
Las Tools para ADO.NET Framework, pero antes de instalárselas y para que no te pase lo que me pasó a mí, tienes que instalarte el siguiente parche para VS 2008.

En cuanto al enlace de las Tools para ADO.NET Entity Framework, el enlace de descarga es este.

Ejemplos de ADO.NET Entity Framework disponibles en la correspondiente sección habilitada en Codeplex.

Y con esto ya puedes empezar a darle caña a ADO.NET Entity Framework.

LINQ To SQL: Object Identitity y múltiples objetos DataContext

Juan Carlos González Martín — Wed, 16 Jan 2008 08:16:37 GMT

Una de las grandes características de LINQ To SQL es la capacidad de preservar la identidad y consistencia de objetos al realizar consultas LINQ, incluso en el caso en el que existan varios objetos DataContext. Si dos consultas contienen resultados que se solapan, LINQ To SQL nos devuelve la misma entidad en cada conjunto de resultados de manera que la lógica de la aplicación se simplifica, pues se puede asumir que estos objetos son únicos y de hecho consistentes. Sin embargo, con las API’s tradicionales de acceso a datos, el desarrollador se ve forzado a capturar estos solapes para poder prevenir la creación de múltiples copias idénticas de resultados no únicas. ¿Cómo se gestiona la consistencia de estos objetos? A través del objeto DataContext que asegura la consistencia y unicidad de dichos objetos. Además, en el caso en el que en nuestra aplicación tengamos más de un objeto DataContext, cada uno de esos mantendrá su propia copia individual de objetos.

Un ejemplo de la preservación de la identidad de objetos en LINQ es el siguiente:

//Preservación de objetos

Console.WriteLine("Ejemplo de preservación de objetos");

CLIENTES_ORMDataContext DB_New_DataContext =

new CLIENTES_ORMDataContext();

var c1 = DB_New_DataContext.Md_Clientes.First();

var c2 = DB_New_DataContext.Md_Clientes.First();

Console.WriteLine("Nombre Nº1 = {0}, Nombre Nº2={1}\n c1==c2 es {2}",

c1.NombreCliente,c2.NombreCliente,

object.ReferenceEquals(c1,c2));

Console.WriteLine("El tipo de c1 es {0}, y el de c2 es {1}",

c1.GetType().ToString(), c2.GetType().ToString());

Console.ReadLine();

La correspondiente salida por pantalla es:

Luego efectivamente, los objetos c1 y c2 son idénticos y hacen referencia al mismo objeto con los resultados tal y como atestigua el hecho de que tengan el mismo valor para la propiedad NombreCliente, y sobre todo porque la comparación mediante el método ReferenceEquals devuelve True como era de esperar. Por otro lado, evaluando el tipo de cada uno de los objetos (qué es resuelto dinámicamente por el compilador a partir de la característica de definir tipos implícitamente de C# 3.0) vemos que es el mismo como cabía esperar.

Como hemos comentado, esta idea de preservación de objetos en cuanto a identidad y consistencia se mantiene aún cuando tengamos múltiples objetos DataContext en nuestra aplicación. En este caso, el código que demuestra esta idea sería el siguiente:

//Preservación de objetos

Console.WriteLine("Ejemplo de preservación de objetos");

CLIENTES_ORMDataContext DB_New_DataContext =

new CLIENTES_ORMDataContext();

var c1 = DB_New_DataContext.Md_Clientes.First();

var c2 = DB_New_DataContext.Md_Clientes.First();

Console.WriteLine("Nombre Nº1 = {0}, Nombre Nº2={1}\n c1==c2 es {2}",

c1.NombreCliente,c2.NombreCliente,

object.ReferenceEquals(c1,c2));

Console.WriteLine("El tipo de c1 es {0}, y el de c2 es {1}",

c1.GetType().ToString(), c2.GetType().ToString());

Console.ReadLine();

La correspondiente salida por pantalla es:

Luego vemos que efectivamente, los objetos c3 y c4 se refieren a la misma fila de resultado (consistencia), son idénticos en cuanto a tipo, pero al aplicar el método ReferenceEquals vemos que la comparación devuelve False debido a que c3 y c4 ya no se refieren al mismo objeto de resultados, sino que cada uno se refiere a un objeto distinto, ya que en cada caso tenemos un objeto DataContext diferente.

Finalmente, lo visto aplica si realizamos consultas que para un mismo DataContext devuelvan el mismo resultado: sólo se creará un objeto con los resultados. Así:

//Preservación de objetos con varios DataContext

Console.WriteLine("Ejemplo de preservación con una query");

CLIENTES_ORMDataContext DB_New_DataContext3 =

new CLIENTES_ORMDataContext();

var query1 = DB_New_DataContext3.Md_Clientes.First(

q1 => q1.ID_Cliente == "71505286B");

var query2 =

(from q2 in DB_New_DataContext3.Md_Clientes

where q2.ID_Cliente == "71505286B"

select q2).First();

Console.WriteLine("Nombre Nº1 = {0}, Nombre Nº2={1}\n query1==query2 es {2}",

query1.NombreCliente, query2.NombreCliente,

object.ReferenceEquals(query1, query2));

Console.WriteLine("El tipo de query1 es {0}, y el de query2 es {1}",

query1.GetType().ToString(), query2.GetType().ToString());

Console.ReadLine();

La correspondiente salida por pantalla es:

Como conclusión, esta igualdad entre objetos es realmente importante para un framework de objectos relacionales como es LINQ To SQL puesto que asegura que ante una actualización del estado de una entidad, el cambio se propagará de manera consistente a lo largo de toda la aplicación.

Espero que el post os haya resultado interesante...seguiremos escribiendo sobre otras características de LINQ que estamos descubriendo y que son espectaculares.

LINQPad: ¿Adios a SQL Server Management Studio?...Creo que no, pero...

Juan Carlos González Martín — Mon, 17 Dec 2007 22:54:17 GMT

Varios meses después de la última vez que escribimos sobre LINQ, hacía tiempo que tenía ganas de escribir sobre una utilidad (gratuita!) relacionada con LINQ y que no había podido probar hasta la semana pasada durante un descanso de uno de los seminarios del CIIN...y esta utilidad no es otra que LINQPad, el equivalente a SQL Server Management Studio para bases de datos de datos SQL Server Express, pero para LINQ To SQL puesto que esta utilidad solo funciona con bases de datos SQL Server. Según la página de su creador, además de permitirnos definir y probar nuestras consultas LINQ contra BD's SQL Server, también podremos hacerlo contra objetos (LINQ To Objects) o archivos XML (LINQ To XML). En este post os mostraré como de sencillo resulta probar nuestras consultas LINQ To SQL mediante LINQPad. Empecemos.

Conectándonos a una BD SQL Server

Nada más iniciar la aplicación (por cierto, es un simple archivo ejecutable que no tiene ningún requisito de instalación y que es autoactualizable...yo lo estoy ejecutando con una máquina virtual con Visual Studio 2008 RTM instalado y también con WSS 3.0), lo primero que podemos hacer es añadir una nueva conexión (al estilo de lo que ya conocemos de SQL Server Management Studio) para la que especificamos el servidor de BD, el modo de visualización, si vamos a atachar un archivo físico de base de datos, el tipo de autenticación,...vamos lo normal y conocido:

Creando una consulta LINQ

Una vez conectados a la BD, a través de la correspondiente editor de consulta, podremos definir la correspondiente consulta LINQ. En este caso yo voy a definir una consulta LINQ sencilla sobre una BD compuesta únicamente por tres tablas (podéis ver el diagrama de base de datos correspondiente), de manera que al ejecutarla obtenemos el resultado esperado...

Nota: La consulta LINQ ejecutada es la siguiente (bastante sencilla como ya os comenté):

from c in MD_Clientes
    join ve in MD_ClienteVehiculos on
    c.ID_Cliente equals ve.ID_Cliente
    join v in MD_Vehiculos on
    ve.ID_Vehiculo equals v.ID_Vehiculo
    orderby c.ID_Cliente descending
    select new{NIF=c.ID_Cliente,Nombre=c.SNombre + " " + c.SApellidos,
        Dieccion=c.SDireccion, Coche=v.SMarca + " " + v.SModelo}

Como veis, en la consulta LINQ estoy utilizando algunas de las novedades en el lenguaje C# 3.0 que ya vimos en este post:

Inicializadores de objetos.
Operadores estándar de consulta.

Analizando la información que nos da LINQPad

Además de comprobar que la consulta LINQ definida devuelve los resultados esperados, LINQPad adicionalmente nos permite:

Visualizar las expresiones lambda sobre las que se asienta la consulta, y que en este caso genera el siguiente listado lleno de estas expresiones, inicializadores de objetos y métodos de extensión (los propios operadores estándar de consulta)

MD_Clientes
   .Join (
      MD_ClienteVehiculos,
      c => c.ID_Cliente,
      ve => ve.ID_Cliente,
      (c, ve) =>
         new
         {
            c = c,
            ve = ve
         }
   )
   .Join (
      MD_Vehiculos,
      temp0 => temp0.ve.ID_Vehiculo,
      v => v.ID_Vehiculo,
      (temp0, v) =>
         new
         {
            <>h__TransparentIdentifier0 = temp0,
            v = v
         }
   )
   .OrderByDescending (temp1 => temp1.<>h__TransparentIdentifier0.c.ID_Cliente)
   .Select (
      temp1 =>
         new
         {
            NIF = temp1.<>h__TransparentIdentifier0.c.ID_Cliente,
            Nombre = ((temp1.<>h__TransparentIdentifier0.c.SNombre + " ") +
                  temp1.<>h__TransparentIdentifier0.c.SApellidos
               ),
            Dieccion = temp1.<>h__TransparentIdentifier0.c.SDireccion,
            Coche = ((temp1.v.SMarca + " ") + temp1.v.SModelo)
         }
   )

La consulta T-SQL que es enviada a la BD, y que como vimos en este post, es generada por el objeto data context, que es el auténtico interprete y traductor de las consultas LINQ a las correspondiente sintaxis T-SQL. En este caso, el correspondiente objeto data context ha generado la siguiente consulta:

SELECT [t0].[ID_Cliente] AS [NIF], ([t0].[sNombre] + @p0) +
[t0].[sApellidos] AS [Nombre], [t0].[sDireccion] AS [Dieccion],
([t2].[sMarca] + @p1) + [t2].[sModelo] AS [Coche]
FROM [MD_Clientes] AS [t0]
INNER JOIN [MD_ClienteVehiculo] AS [t1] ON
[t0].[ID_Cliente] = [t1].[ID_Cliente]
INNER JOIN [MD_Vehiculos] AS [t2] ON
[t1].[ID_Vehiculo] = [t2].[ID_Vehiculo]
ORDER BY [t0].[ID_Cliente] DESC

-- @p0: Input NVarChar (Size = 1; Prec = 0; Scale = 0) [ ]
-- @p1: Input NVarChar (Size = 1; Prec = 0; Scale = 0) [ ]
-- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.21022.8

¿Y que más...?

Además de servirnos como herramienta de pruebas para nuestras consultas LINQ, LINQPad viene con un montón de ejemplos precargados (más de 200) que aparecen en el libro C# 3.0 in a Nutshell de Joseph y Ben Albahari, autores de esta interesantísima herramienta. En la propia página de la herramienta tenéis disponible todos los listados de código que aparecen en dicho libro (me parece que habrá que echarle un vistazo profundo), así como un pequeño Quiz para demostrar lo que sabemos de C# 3.0.

Sin más, esto es lo que os quería contar sobre LINQPad...os animo a probarla, es realmente chula y pude darnos mucho juego para probar nuestras consultas LINQ.

Visual Studio 2008 Beta2: Realizando Consultas con LINQ (I)

Juan Carlos González Martín — Fri, 07 Sep 2007 10:18:28 GMT

Hacía unos meses que tenía un poco olvidado a LINQ (en concreto a LINQ To SQL) y también la máquina virtual de Visual Studio 2008 Beta2 (en este caso ha estadp en el olvidomenos tiempo), asique ayer después de verme un video de como interactuar con una BD SQL Server mediante LINQ To SQL y con VB.NET me decidí a comenzar una serie de posts en las que mostrar aspectos de LINQ que ya comenté en un post prevío, y ya de paso refrescar algunas de las novedades que habréis leido / experimentado (sobre todo en el blog de Bruno) con Visual Studio 2008. También y siguiendo con el llamamiento de Miguel LLopis, os animo a que experimentéis y probéis LINQ y las innovaciones en el lenguaje que vendrán con las nuevas versiones de C# y VB.NET.

En este post os voy a mostrar como de manera sencilla podemos definir un modelo de entidades con el OR Designer de LINQ sin más que arrastrar las tablas que nos interesen de una BD SQL Server a la superficie de diseño típica de Visual Studio. Esta funcionalidad ya la teníamos con la primera preview de LINQ (mayo del año pasado) tal y como vimos en este post. Algunos cambios que aparecen en el OR Designer son referentes a los archivos que se generan: un archivo .layout que es justo el modelo creado que estamos visualizando y el típico archivo .designer.cs en el que encontraremos todo el código que Visual Studio autogenera para crear el modelo de entidades. Empecemos

Inspeccionando el modelo /fuente de datos subyacente

El primer paso antes de abrir Visual Studio 2008 Beta2 es tener claro cómo es el modelo de datos con el que vamos a operar. LINQ cambia la forma en que hasta ahora accediamos a los datos, pasamos de crear consultas SQL "peagadas" en código o en procedimientos almacenados a definir consultas integradas e el lenguaje. Sin embargo, a la hora de crear una aplicación de acceso a datos con o sin LINQ, lo primero es tener claro el modelo de datos que hay por debajo. Para este primer ejemplo he creado una sencilla base de datos (BD) con tres tablas relacionadas. El diagrama entidad relación es el siguiente:

Creando el proyecto de demo de LINQ To SQL

Una vez que tenemos claro como es el modelo de datos, ya podemos irnos a Visual Studio 2008. Como siempre en un proyecto de Visual Studio, lo primero es crear nuestro proyecto. En este caso he optado por una aplicación Windows Forms, y en este primer punto ya tenemos una de las novedades de Visual Studio 2008: framework multitargeting, es decir, podemos escoger en base a que versión de .NET Framework implementar nuestras aplicaciones:

Cómo véis, las versiones de .NET Framework soportadas son la 2.0, la 3.0 y la 3.5, pero no las previas (seguro que es una pregunta que nos van a hacer mucho). También cuanto más alta es la versión, más plantillas de proyecto vamos a tener puesto que la filosifía que se sigue es continuar con lo anterior y añadir lo nuevo (así, en la versión 3.5 tenemos plantillas para crear actividades WCF para utilizar en nuestros workflows). En este caso, la versión de framework que hemos de utilizar es la 3.5 pues es la que incluye la infraestructura de LINQ.

Inspeccionando los elementos del proyecto

Una vez creado el proyecto de Windows Forms para .NET Framework 3.0, resulta interesante inspeccionar que "añadidos" tenemos en cuanto a referencias y espacios de nombres utilizados por el archivo .cs asociado al formulario.

Como vemos, en el archivo .cs ya se añade directamente el espacio System.Linq que nos da el acceso a toda la infraestructura de LINQ para definir consultas integradas en el lenguaje. En cuanto a referencias "novedosas" añadidas al proyecto se ha añadido las siguientes: System.Xml, y System.Xml.Linq con el objeto de poder utilizar la nueva forma de trabajar con XML que también ha venido con el proyecto LINQ.

Creando el modelo de entidades

El sigueinte paso (fundamental) es definir el modelo de entidades. Para ello, añadimos al proyecto un nuevo elemento de tipo LINQ To SQL Classes (novedad) de manera que se visualizará la típica superficie de diseño (este es el OR Designer) en la que vamos a definir el modelo de entidades a partir de arrastrar las tablas que nos interesen de la BD con la que vamos a trabajar:

Para los que estáis acostumbrados a trabajar con ADO.NET y datasets tipados, el resultado final os resultará familiar puesto que lo que estamos teniendo es una representación de nuestro modelo de datos a través de las correspondientes entidades y con las mismas relaciones que tengamos a nivel de la BD. Si inspeccionamos el archivo .designer.cs que se genera a partir del modelo, veremos que tenemos toda la infraestructura necesaria para trabaja con él y realizar la interactuación con la BD subyacente:

La clase DataContext, que como vimos es el que se encarga, entre otras funciones, de realizar la conexión a la BD subyacente y realizar el proceso de "traducción" de las consultas integradas en el lenguaje a las correspondientes instrucciones T-SQL
Una clase por cada una de las entidades que hemos "pintado" en el modelo. Para cada clase se generarán los atributos correspondientes a partir de realizar el correspondiente mapeo con las columnas y relaciones que tenemos a nivel de la BD.
Para interactúar con cada entidad, se generarán los correspondientes métodos de insercción, borrado, y actualización de datos.
...

Diseño del formulario

Esta paso es, para este ejemplo, el más sencillo. El formulario a diseñar mostrará un listado de datos recogidos de las tres tablas de nuestra BD y permitirá navegar por los mismos. Por lo tanto, necesitaremos un control de tipo DataGridView, un control de tipo BindingNavigator y su correspondiente BindingSource...con seleccionar, arrastrar y soltar listo:

Programando la lógica del formulario

Una vez completados los pasos anteriores, ya estamos listos para definir la lógica asociada al formulario. Lo primero es instanciar un objeto DataContext de acuerdo a nuestro modelo de entidades para poder realizar operaciones contra la BD:

ModeloObjetosDataContext BD = new ModeloObjetosDataContext();

Una vez que ya tenemos establecido el contexto de datos, ya podemos emepezar a crear consultas utilizando LINQ. En este caso, la consulta que vamos a realizar se debería corresponder con la siguiente sentencia T-SQL:

select c.sNombreCliente,c.sApellidosCliente,c.sCiudadCliente,
    v.sMarca,v.sModelo,ve.iKilometros
    from MD_Clientes C
    inner join MD_ClienteVehiculo ve on
    ve.ID_Cliente = c.ID_Cliente
    inner join MD_Vehiculos v on
    v.ID_Vehiculo=ve.ID_Vehiculo
    order by c.sCiudadCliente asc

A partir de esta consulta, empezamos la traducción a LINQ. Lo primero es definirnos un tipo var en el que volcaremos la estructura de datos devuelta. Ya comentamos que es una innovación en el lenguaje que nos permite declarar tipos de manera ímplicita, es decir, sin especificarlo (siendo el compilador el que en tiempo de ejecución se encargue de determinar el tipo). A este tipo le asignamos la consulta a realizar...algo con lo que ya viene LINQ en Visual Studio 2008 Beta2 y que no teníamos con la preview de mayo de 2006 es el soporte de intellisense tanto para definir tipos ímplictios como para crear las consultas integradas en el lenguaje:

Con estas facilidades y conociendo como se definen las consultas integradas en el lenguaje con LINQ, "traducir" la consulta T-SQL anterior es bastante sencillo:

var clientes =
    from c in BD.MD_Clientes
    join ve in BD.MD_ClienteVehiculos on
    c.ID_Cliente equals ve.ID_Cliente
    join v in BD.MD_Vehiculos on
    ve.ID_Vehiculo equals v.ID_Vehiculo
    orderby c.sCiudadCliente ascending
    select new {c.sNombreCliente,c.sApellidosCliente,c.sCiudadCliente, v.sMarca, v.sModelo, ve.iKilometros};

Sin más, no tenemos más que forzar a que la consulta se ejecute vinculanto el tipo var con el control de datos que queramos (en este caso el BindingSource), configurar el resto de controles para que utilien este último, y añadir a nuestro código BD.Log= Console.Out para ver que comandos T-SQL se están enviando a la BD a través del objeto DataContext:

this.bindingSource1.DataSource = clientes;
this.dataGridView1.DataSource = this.bindingSource1;
this.bindingNavigator1.BindingSource = this.bindingSource1;

Bueno, pues como cabía el resultado es el mismo y la sentencia T-SQL que se envía a la BD es muy similar (con un estilo más depurado diria yo) a la que nos planteamos inicialmente.

Entendiendo la ejecución de la consulta LINQ

Finalmente, y aunque ya lo comenté en el primer post que hicimos sobre LINQ, vamos a ver cuál es el punto en que se ejecuta realmente la consulta. A primera vista, cabe pensar que esta se ejecuta en el momento en el que se define. Sin embargo, esto no es así. La consulta se ejecuta realmente contra la BD en el momento en el que se va a utilizar su resultado, es decir, en el momento en el que vinculamos el tipo var con el control BindingSource. Veamos que esto sucede de esta forma ejecutando el código paso a paso y comprobando que salida tenemos en la consola de salida de Visual Studio:

Luego, cuando llegamos al punto de ruptura y ejecutamos el paso siguiente es el momento en el que la sentencia T-SQL se envía la BD y el resultado se vincula con el control BindingSource. Se está utilizando lo que en LINQ se conoce como ejecución diferida de consultas, es decir, estas se ejecutan en el momento en el que se va a hacer uso efectivo de las mismas.

Y hasta aquí llega el primer post de LINQ en Visual Studio 2008. Espero que os haya parecido interesante y que os animéis a creaer consultas con LINQ. Desde luego, para alguien acostrumbrado a escribir consultas en T-SQL, traducirlas a LINQ es realmente sencillo

LINQ To SQL: Query Visualizer!

Juan Carlos González Martín — Sun, 29 Apr 2007 20:50:00 GMT

El otro día me comentaba Rodrigo Corral que le parecían interesantes muchos de los posts que tenemos publicados en el blog del CIIN, y que estaría bien que aparecieran también en Geeks, por lo que dicho y hecho, este es el primero de los posts que rescatamos de nuestro blog para republicarlo en Geeks, y en el futuro lo que haremos será crossposting entre ambos blogs (primero tendremos que averiguar cómo hacer Crossposting entre nuestro blog basado en WSS 3.0 y el blog del CIIN en Geeks).

Sin más preámbulos, pasemos a la acción. En un post previo introducimos LINQ To SQL. Vimos como podíamos crear consultas integradas en el lenguaje para obtener información de un origen de datos relacional SQL Server, estas consultas se realizaban contra objetos de un modelo de objetos en el que mapeábamos elementos de un esquema relacional (tablas, columnas de las tablas y procedimientos almacenados). También comentamos que LINQ se apoya en muchas de las innovaciones del lenguaje que vendrán con C# 3.0 y VB 9.0 y en características propias como la evaluación diferida de consultas, es decir, la consulta que he creado no se ejecuta hasta que itero con ella. En la práctica, este mecanismo de evaluación diferida de consultas nos da la ventaja de que podamos evaluar una consulta múltiples veces puesto que su definición permanece en memoria.

Además de estas características clave, LINQ To SQL nos ofrece herramientas interesantes para facilitar en tiempo de depuración algo tan típico como comprobar que consulta T-SQL se está enviando a la BD y probarla sin tener que irnos a SQL Server Management Studio o a la ventana de comandos de Visual Studio. Esta herramienta es el LINQ To SQL Query Visualizer, que el IDE de Visual Studio nos ofrece en tiempo de depuración al posicionar el puntero del ratón sobre el tipo que va a almacenar el resultado de la ejecución de la consulta realizada:

var ClientesMarcaCoche =

from c in BD2.Customers

join ve in BD2.Vehicles on

c.ID_Cliente equals ve.ID_Cliente

orderby c.CiudadCliente ascending

select new{NIF=c.ID_Cliente,

Nombre=c.NombreCliente,Coche=ve.MarcaVehiculo};

Para iniciar el Query Visualizer, no tenemos más que iniciar la ejecución del programa de LINQ To SQL en modo depuración y situar un punto de ruptura justo después de construir la consulta integrada en el lenguaje. Las capacidades del Visualizer aparecerán en el momento que pasamos el ratón sobre el tipo que almacena la consulta.

Si pulsamos sobre la pestaña asociada al icono de la lupa, podremos ver el LINQ To SQL Visualizer, en el que se nos mostrará:

· La definición completa de la consulta que hemos definido en código, es decir, mostrando la llamada a los operadores estándar de consulta como métodos de extensión y las expresiones lambda que se están utilizando para luego generar la correspondiente sentencia T-SQL.

La sentencia T-SQL que se envía a la BD.

Como vemos, en el visualizador se muestra la consulta definida en un formato en el que no estamos utilizando Query Syntax y mostrando las expresiones lambda y otras innovaciones (tipos anónimos, inicialización de objeto, y uso de métodos de extensión a través de los operadores estándar de consulta) en el lenguaje que necesita para poder realizar la consulta.

Sin más, al pulsar el botón ejecutar podremos ver el resultado que nos devuelve la query T-SQL que LINQ genera a partir de la consulta definida en el lenguaje:

Como veis, esta herramienta es realmente útil (de hecho, ha causado sensación en el primer seminario que sobre LINQ impartimos en el CIIN) para comprobar que las consultas devuelven los resultados esperados sin abandonar el entorno de depuración de Visual Studio 2005. Y hasta aquí el primer post que rescatamos del blog del CIIN, comentaros también que el sábado por la mañana me instalé la Beta 1 de Orcas y por fin integra plenamente LINQ en el IDE, espero pronto poneros algún ejemplo chulo de LINQ en Visual Studio Orcas.

LINQ To XML: Integración de XML!

Juan Carlos González Martín — Wed, 07 Mar 2007 16:39:00 GMT

Como no podía ser de otra forma, y después de hablar de las bases de LINQ y de LINQ To SQL, desde el CIIN nos faltaba comentar la “tercera pata” del proyecto LINQ: LINQ To XML. Lo de tercera pata va entrecomillado, porque ya tenemos a la vista nuevas capacidades (como LINQ To XSD) y nuevas siglas que integran las siglas LINQ (CLINQ, para habilitar el uso de parte de las características de LINQ en C++/CLI, PLINQ, para definir una implementación de LINQ que permita la ejecución de código LINQ en múltiples CPU’s, y seguro que algún componente más de LINQ sobre el que alguien ya está trabajando) y de las que espero poder comentaros cosas interesantes próximamente (especialmente de BLINQ). Empecemos pues con LINQ To XML.

¿Qué es LINQ To XML?

Según la documentación oficial sobre LINQ, LINQ To XML es el componente específico de LINQ pensado para trabajar con información en formato XML cacheada en memoria, aprovechando las ventajas de los operadores estándar de consulta, y que además expone y añade nuevas funcionalidades para crear y manipular (a través de la integración en .NET Framework de toda la potencia que dan las transformaciones XPath y XQuery) de manera sencilla tanto documentos XML completos como porciones o fragmentos de una estructura XML. Por supuesto, como sucedía con LINQ To SQL, LINQ To XML va a permitir combinar consultas y transformaciones de documentos o fragmentos XML con consultas de otros orígenes de datos (relacionales o no). Estas prestaciones de LINQ To XML se apoyan en las siguientes características clave:

· Las innovaciones del lenguaje (C# 3.0 y VB 9.0) que vimos en un post previo, así como en las características propias de LINQ (consultas integradas en el lenguaje).

· Consultas a estructuras XML integradas en el lenguaje, es decir, tenemos la potencia de XPath y XQuery dentro de C# y VB.

· Se sigue manteniendo la experiencia de DOM, pero se utiliza de un modo más sencillo:

o Visión centrada en los elementos particulares de una estructura XML, frente a la visión anterior centrada en el documento.

o Construcción funcional y a medida de estructuras XML. No necesito construir un documento XML completo, y puedo trabajar directamente con elementos XML al estilo XPath.

· Las estructuras XML se crean de un modo dinámico, lo que simplifica su tratamiento.

· Supone una representación en memoria más eficiente, que se integra con la infraestructura de lectura/escritura de System.Xml.

· Se pueden cargar documentos XML existentes desde múltiples orígenes: XmlReader, TextReder, o un simple String.

Siguiendo la misma referencia de otros post, en la traducción de El Proyecto LINQ de Octavio Hernández, LINQ To XML define tres tipos de objetos en los que se basa la mayor parte de la integración de consulta contra estructuras XML.

· XName, que habilita los mecanismos para trabajar de manera sencilla con los identificadores de espacios de nombres (QNames) utilizados en los nombres de elementos y atributos.

· XElement, que viene a representar un elemento o nodo de una estructura / documento XML.

· XAttribute, que es la representación de un atributo de un elemento.

Aunque estos tres tipos son las piezas claves de LINQ To XML, hay muchas más clases definidas en su jerarquía de clases (hasta la Preview de Mayo de 2006).

Después de esta introducción a lo que es LINQ To XML, en los siguientes apartados trataré de cubrir aspectos relativos a la construcción de estructuras XML, la integración con datos precedentes de fuentes no XML, y operaciones de manipulación y transformación de estructuras XML con LINQ To XML. Empecemos.

Nota: Los requisitos necesarios para probar LINQ To SQL son los que ya comentamos en el primer post de LINQ.

Creación y consulta de información en estructuras XML

Lo primero que vamos a ver es como de un modo sencillo podemos crear un sencillo documento XML (utilizando lo que LINQ To XML denomina Construcción Funcional, que permite crear un estructura XML, completa o no, en una única sentencia), y como también es realmente sencillo definir una consulta sobre dicha estructura (que no deja de ser un objeto en memoria fácilmente consultable con LINQ). El código necesario para crear el documento XML es el siguiente:

XDocument DocXML= new XDocument(

new XDeclaration("1.0","utf-8","yes"),

new XComment("Ejemplo de doc. generado con LINQ To XML"),

new XElement("Agenda",

new XElement("Contactos",

new XElement("Contacto",new XAttribute("Categoría","Particular"),

new XElement("Nombre","José González")),

new XElement("Contacto",new XAttribute("Categoría","Particular"),

new XElement("Nombre","María Méndez")),

new XElement("Contacto",new XAttribute("Categoría","Trabajo"),

new XElement("Nombre","Antonio Muñoz")))));

Console.WriteLine(DocXML);

Con el código anterior, estamos creando un documento XML a partir de instanciar el objeto XDocument a través de una de las cuatro sobrecargas que tiene definidas. En concreto, la sobrecarga utilizada permite especificar mediante XDeclaration los valores utilizados para la versión, codificación y si el documento es standalone, y luego una lista de parámetros con los elementos que forman parte del documento XML y que en este caso son unos comentarios (especificados a través de XComment) y una jerarquía de elementos XML especificados mediante XElement. Finalmente, para visualizar por pantalla el documento vemos que no se necesita ningún tipo de factoría DOM, sino que es directamente visualizable sin hacer ningún tratamiento previo (lo que es una gran ventaja, ya que estamos creando un documento XML de un modo realmente sencillo con LINQ To XML). La salida por pantalla es la siguiente:

Al esquema anterior le podemos añadir de manera sencilla un nombre XML utilizando el objeto XNameSpace, que encapsula un espacio de nombres XML. Además, este documento no solo lo podemos visualizar de manera sencilla, sino que también guardarlo en disco realmente fácil utilizando el método Save() del objeto XDocument.

XNamespace miEspacioNombres="http://www.ciin.es/esquemas";

XDocument DocXML= new XDocument(

new XDeclaration("1.0","utf-8","yes"),

new XComment("Ejemplo de doc. generado con LINQ To XML"),

new XElement(miEspacioNombres + "Agenda",

new XElement(miEspacioNombres + "Contactos",

new XElement(miEspacioNombres + "Contacto",

new XAttribute("Categoría","Particular"),

new XElement(miEspacioNombres + "Nombre","José González")),

new XElement(miEspacioNombres + "Contacto",

new XAttribute("Categoría","Particular"),

new XElement(miEspacioNombres + "Nombre","María Méndez")),

new XElement(miEspacioNombres + "Contacto",

new XAttribute("Categoría","Trabajo"),

new XElement(miEspacioNombres + "Nombre","Antonio Muñoz")))));

Console.WriteLine(DocXML.ToString());

DocXML.Save("Contactos.xml");

En este caso, el documento XML guardado en disco tendría este aspecto:

Nota: Igual que con el método Save() podemos guardar una estructura XML en disco, el método Load() de XDocument nos permite cargar un documento que está guardado en disco y manipularlo del mismo modo en que estamos trabajando con estructuras XML creadas en memoria.

Definir consultas sobre un documento XML como el anterior es bastante sencillo a través del uso de los operadores estándar de consulta. A modo de ejemplo, el siguiente código nos permite obtener todos los contactos de tipo Particular en el documento XML creado anteriormente:

Console.WriteLine("****Definiendo una consulta contra una estructura XML****");

var ContactosParticulares=

from c in DocXML.Descendants(miEspacioNombres + "Contacto")

where (string)c.Attribute("Categoría")=="Particular"

orderby (string)c.Element(miEspacioNombres + "Nombre")

select c;

//Hacemos efectiva la consulta

foreach (var contacto in ContactosParticulares)

{

Console.WriteLine("{0}",contacto);

}

Del código anterior, hay que destacar un par de cosas:

· EL método Descendant que nos permite obtener todos los elementos descendientes del tipo especificado (en este caso Contacto).

· El hecho que tanto en la condición de la cláusula where como en la de la cláusula orderby estamos indicado que de manera específica se trabaja con elementos del documento XML de tipo cadena. Y la razón de este modo de trabajo hay que buscarla en el hecho de que LINQ To XML permite tratar los valores contenidos en elementos y atributos respetando sus tipos sin más que hacer un simple cast (aquí tenemos otra ventaja de LINTO To XML, frente al W3C DOM que siempre trata los nodos XML como textos).

La correspondiente salida por pantalla es la siguiente:

En esta salida vemos como efectivamente LINQ To XML no obliga a trabajar a nivel de documento XML completo, sino que podemos quedarnos a nivel de elementos XML.

Integración con datos no XML

Hasta ahora hemos visto como es bastante sencillo construir estructuras XML utilizando la Construcción Funcional de LINQ To XML. Sin embargo, las estructuras que hemos construido se basan en ir añadiendo de manera estática elementos de tipo string al árbol. Como comentamos, se podrían añadir otros tipos de datos, y por supuesto, podemos utilizar variables en la construcción en lugar de valores. Pero, ¿Cómo hacemos más dinámica esta construcción funcional? La respuesta está de nuevo en utilizar el tipo IEnumerable<T> aplicada a objetos de tipo XElement, lo que nos permitirá construir estructuras XML a partir de objetos de memoria, resultados procedentes de hacer una consulta a una BD, etc. Para explicar este tipo de construcción, vamos a ver cómo podemos crear una estructura XML a partir de definir una consulta sobre un array de objetos de un cierto tipo:

· Lo primero es definir la clase a partir de la cuál crearemos los objetos contenidos en el array.

class Contacto

{

public string Nombre;

public string Telefono;

}

· Lo siguiente que haremos es construir el arreglo de objetos aprovechándonos de algunas de las innovaciones en el lenguaje que ya vimos (en concreto, declaración implícita de tipos, tipos anónimos e inicializadores de objetos):

var contactos_agenda=new[]{

new Contacto{Nombre="José González",Telefono="11111"},

new Contacto{Nombre="Luis García", Telefono="22222"},

};

· Sin más, ya podemos construir una estructura XML (en este caso no vamos a construir un documento completo, sino sólo una serie de elementos XML) a partir de definir una consulta XML sobre el array de objetos creado:

XElement Contactos=

new XElement(miEspacioNombres + "Contactos",

from c in contactos_agenda

select new XElement(miEspacioNombres + "Contacto",

new XElement(miEspacioNombres + "Nombre",c.Nombre),

new XElement(miEspacioNombres + "Telefono",c.Telefono)));

Console.WriteLine(Contactos.ToString());

La clave del código anterior está en que dentro de la cláusula Select podemos construir objetos de tipo XElement, y en que los objetos de tipo XElement pueden ser construidos a partir del resultado de una consulta a un objeto de memoria. La salida por pantalla generada es la siguiente:

Igual que hemos construido una estructura XML a partir de definir una consulta contra un objeto de memoria, se aplicaría la misma filosofía y método para generar estructuras / documentos XML a partir de datos de una BD relacional y apoyándonos en LINQ To SQL como ya vimos.

Operación y manipulación de estructuras XML

Como comentábamos, otra característica relevante de LINQ To XML es que permite realizar de un modo sencillo operaciones con estructura XML. Vamos a ver algunas de ellas:

· Operaciones de Transformación, que nos permiten transformar y extender estructuras XML ya definidas. A partir de los elementos de una estructura XML existente, es posible crear nuevos elementos:

Console.WriteLine("***********Operaciones de Transformación***********");

XElement ElementoTransformado =

new XElement (miEspacioNombres + "Amigos",

from c in ContactosParticulares

select new XElement(miEspacioNombres + "Amigo",

new XAttribute("NombreCompleto",(string)c.Element(miEspacioNombres +

"Nombre"))));

Console.WriteLine("\n\n {0}",ElementoTransformado);

Lo que hemos hecho en el código anterior de la consulta de los contactos particulares del documento original XML para generar una estructura XML distinta, pero aprovechando datos de la consulta. La salida por pantalla obtenida es la siguiente:

· Añadir, eliminar y actualizar elementos, LINQ To XML permite añadir, eliminar o modificar contenidos en una estructura XML a partir de los métodos Add(), Remove() y ReplaceContent() del objeto XElement. Así, para modificar la estructura anterior el código necesario sería:

Console.WriteLine("***********Añadir, Borrar, Modificar elementos**********");

XElement Telefono=new XElement(miEspacioNombres + "Telefono","111111");

ElementoTransformado.Element(miEspacioNombres + "Amigo").Add(Telefono);

Console.WriteLine("\n Añadir");

Console.WriteLine("\n {0}",ElementoTransformado);

Console.WriteLine("\n Modificar");

ElementoTransformado.Element(miEspacioNombres +

"Amigo").Element(miEspacioNombres +

"Telefono").ReplaceContent("22222");

Console.WriteLine("\n {0}",ElementoTransformado);

Console.WriteLine("Borrar");

ElementoTransformado.Element(miEspacioNombres +

"Amigo").Element(miEspacioNombres + "Telefono").Remove();

Console.WriteLine("\n {0}",ElementoTransformado);

Y la salida por pantalla correspondiente es la siguiente:

· Navegar por los nodos de una estructura XML, LINQ To XML habilita varios mecanismos para navegar por los nodos de una estructura XML a través de los métodos Nodes() y Descendant() del objeto XElement. Estos métodos nos facilitan la tarea de poder trabajar con elementos concretos de nuestra estructura XML. Un ejemplo de uso de ambos es el siguiente:

Console.WriteLine("****Navegando por los nodos de un elemento XML****");

Console.WriteLine("\n Con Descendants()");

foreach(var x in ElementoTransformado.Descendants(miEspacioNombres + "Amigo")){

Console.WriteLine(x);

}

Console.WriteLine("\n Con Nodes()");

foreach(var x in ElementoTransformado.Nodes()){

Console.WriteLine(x);

}

La salida por pantalla que se obtiene es la siguiente:

Como vemos, la salida que producen ambos métodos es la misma para el caso de una estructura XML sencilla. Para estructuras más complicadas, el resultado será distinto puesto que Descendants() siempre nos devolverá todos los elementos por debajo de un elemento especificado, mientras que Nodes() siempre nos va a devolver los nodos por debajo del primer elemento en la jerarquía de la estructura XML en cuestión.

Nota: En el caso de trabajar con atributos, sólo es posible realizar operaciones de borrado de los mismos a través de los método Remove() o SetAttribute() del objeto XAttribute.

Finalmente, y para concluir el post os dejo una recopilación de las extensiones específicas de LINQ To XML que proporcionan la capacidad para realizar ciertas operaciones que tienen sentido al trabajar con estructuras XML (algunas de ellas las hemos visto en las operaciones de manipulación y transformación de estructuras XML).

Operadores	Descripción
Elements()	Devuelve todos los elementos hijos para cada XElement de una secuencia de XElements (IEnumerable <XElement>).
Descendants() y Ancestors()	Nos permiten consultar respectivamente los elementos situados por encima y por debajo (en la jerarquía) del elemento especificado (sin incluirlo).
Attributes()	Es una extensión llamada en IEnumerable<XElement> que devuelve una secuencia de atributos (IEnumerable<Attributes>).
ElementsBeforeThis, ElementsAftherThis	Permiten devolver todos los elementos hijos o contenidos que aparecen, respectivamente, antes y después de un elemento particular. En ambos casos devuelven un tipo IEnumerable<XElement>.
NodesBeforeThis, NodesAfterThis	Se comportan igual que ElementsBeforeThis y ElementsAfterThis, salvo que en este caso se devuelve un tipo IEnumerabe<XNode>.

Y hasta aquí lo que os quería contar de LINQ To XML. En la próxima me gustaría comentaros otras iniciativas que están surgiendo en torno a LINQ, y enseñaros con ejemplos de que va BLINQ. Espero que el post os haya resultado de interés. Como en el post anterior, os dejo aquí el zip con la solución del proyecto de LINQ To XML.

LINQ To SQL: Definiendo un Modelo de Entidades y operando con él!

Juan Carlos González Martín — Wed, 21 Feb 2007 11:38:00 GMT

Después de unos días ajetreados preparando el seminario sobre LINQ que próximamente impartiremos en el CIIN (de hecho justo hoy hemos acabado de hacer las últimas pruebas con LINQ To XML), en este post os voy a comentar algunos aspectos interesantes que hemos aprendido sobre LINQ To SQL. Pero, ¿Qué es LINQ To SQL? Según la documentación disponible en el sitio oficial del proyecto de LINQ, LINQ To SQL es el componente específico de LINQ que proporciona la infraestructura de runtime necesaria para utilizar datos relacionales como objetos y poder definir consultas sobre dichos objetos, es decir, habilita la consulta de contenedores de datos relacionales sin tener que abandonar la sintaxis o el entorno de tiempo de compilación. Para hacer posible esto, LINQ To SQL se apoya en las siguientes características clave:

· Las innovaciones del lenguaje (C# 3.0 y VB 9.0) que vimos en un post previo, así como en las características propias de LINQ (consultas integradas en el lenguaje).

· Mapping del esquema de la BD en clases, propiedades, métodos, etc. De hecho, la correspondencia que LINQ To SQL hace entre los elementos de un esquema de una BD y los elementos correspondientes a nivel del CLR es el siguiente:

· Persistencia, que habilita el control automático de cambios en la BD, y la actualización de datos a través de sentencias T-SQL.

· Integración de la información del esquema de la BD en metadatos del CLR:las tablas se tratan como colecciones, los datos (columnas) son descritos en clases, la conexión a la BD y los resultados están tipados, etc. Cómo se comenta en el artículo El Proyecto LINQ (traducción de Octavio Hernández), esta integración es la que permite compilar las definiciones de tablas y vistas SQL en tipos del CLR para que puedan ser accedidas desde cualquier lenguaje.

En la práctica, LINQ To SQL provee de los mecanismos necesarios para encapsular y utilizar en nuestras aplicaciones la definición (completa o no) de un cierto esquema relacional, y poder definir consultas LINQ sobre las clases mapeadas. El esquema de la arquitectura de LINQ To SQL nos permitirá comprender mejor las ideas expuestas:

Como se puede deducir, los puntos clave de la arquitectura de LINQ To SQL son los siguientes:

Consultas a nivel de aplicación integradas en el lenguaje.

Base de datos tipada en objetos: mapeo a través de atributos, devuelve objetos al realizar consultas SQL.

LINQ To SQL garantiza la persistencia, control de cambios y control de concurrencia.

LINQ To SQL traduce las consultas en SQL que se envía a la BD: las consultas no se ejecutan en memoria y no se transmiten como IL al servidor BD.

Bueno, después de esta introducción “tan teórica”, es el momento de pasar a la acción. En los siguientes apartados trataré de cubrir aspectos relativos al mapeado de objetos de acuerdo a un esquema relacional existente, y como definir operaciones sobre dichos objetos que luego se traducirán en la BD a las correspondientes sentencias T-SQL. Empecemos.

Nota: Los requisitos necesarios para probar LINQ To SQL son los que ya comentamos en el primer post de LINQ.

Creación del modelo de objetos

El modelo de objetos creado se basa en una sencilla base de datos formada por dos tablas relacionadas: Md_Clientes y Md_Vehiculos.

Como hemos comentado, el mapeo de elementos de la BD se basa en definir las clases, propiedades y métodos necesarios para poder interactuar con ellos del mismo modo que con otros tipos del CLR. LINQ To SQL nos da tres posibilidades para realizar este mapeo:

(i) Utilizando la herramienta SQL Metal la cuál a partir del archivo .mdf de nuestra BD genera un archivo .cs con todos los elementos de la BD mapeados.

Utilizando LINQ To SQL OR Designer que es integrado en VS 2005 después de instalar el LINQ Preview. En este caso, el mapeo es todavía más sencillo puesto que sólo tenemos que arrastrar las tablas que nos interesen de nuestro esquema de datos a la superficie de diseño (seguro que esto le suena a más de uno). Si nos vamos a la vista de código (después de grabar :P), veremos que se nos han generado todos los elementos de la BD que hemos situado en la superficie de diseño.

(i) Hacer el mapeo “a mano”, es decir, definir adecuadamente en código las clases y propiedades que representan las tablas y campos a mapear.

¿Qué método es más adecuado para definir el modelo de objetos? Pues básicamente, y desde mi punto de vista, está claro que las opciones (i) e (ii) son más rápidas, pues hacen todo el trabajo por nosotros (aparte de que no se dejan cosas en el tintero) y nos mapean todas las tablas con sus columnas en un archivo .cs. Sin embargo, perdemos un poco de flexibilidad puesto que el modelo de objetos se define de acuerdo a la descripción fiel de la BD y no con respecto a necesidades de negocio concretas. En cambio, el método (iii) es más flexible ya que nos permite definir “entidades” de acuerdo al proceso de negocio concreto, de manera que nuestras clases estarán formadas por aquellas propiedades que realmente son interesantes para nosotros (y no por todas las columnas de la correspondiente tabla en la BD). Evidentemente el método (iii) implica más esfuerzo de desarrollo y conocer en mayor detalle como mapear tablas en objetos en LINQ. Nosotros vamos a ir por la opción (iii) para tener un mayor control de lo que estamos haciendo.

Dentro del proyecto de LINQ que hayamos creado, vamos a definir una clase que represente a la entidad Clientes. La definición de esta clase la vamos a basar en la tabla Md_Clientes de nuestro esquema relaciona. Esta clase es una representación lógica y tipada de la tabla en la BD física, y actúa a todos los efectos como un proxy para realizar consultas fuertemente tipadas.

[Table(Name="Md_Clientes")]

public class Clientes

{

[Column (Id=true, DBType="varchar")]

public string ID_Cliente;

private string _NombreCliente;

[Column(Storage="_NombreCliente", DBType="varchar")]

public string NombreCliente

{

get {return this._NombreCliente;}

set {this._NombreCliente=value;}

}

private string _CiudadCliente;

[Column(Storage="_CiudadCliente", DBType="varchar")]

public string CiudadCliente

{

get {return this._CiudadCliente;}

set {this._CiudadCliente=value;}

}

Como vemos en el código anterior, el mapeo de la entidad Clientes a la tabla Md_Clientes se basa en utilizar los atributos adecuados:

· El atributo Table que define cuál es la tabla de la BD con la que se encuentra vinculada la entidad Clientes. Este atributo prese

· El atributo Column que permite especificar la correspondencia de los miembros de la clase con las correspondientes columnas de la tabla física. Además, este atributo lleva asociados una serie de parámetros que nos permiten especificar si el miembro de la clase se corresponde con la primary key de la tabla de la BD (parámetro Id), el tipo de dato parámetro (DBType, si el campo es autogenerado (parámetro autogen), etc.

Una vez que hemos creado la primera entidad del modelo de objetos, nos falta definir el canal que nos permita traer objetos desde la BD y enviar cambios a la BD. Este canal es lo que en LINQ se conoce como DataContext, que se encarga de traducir las peticiones de objetos en consultas SQL (ver el esquema de la arquitectura de LINQ) y devolver los resultados como objetos. El objeto DataContext se puede especificar de dos formas:

· Definiendo una instancia del mismo y pasando como parámetro la cadena de conexión de la BD. Este método implica que para definir consultas contra la BD tengamos que utilizar el método GetTable.

DataContext BD=new DataContext(@"C:\Program Files\LINQ Preview\Data\CLIENTES.mdf");

Table<Clientes> Customers=BD.GetTable<Clientes>();

Nota: Como vemos, como cadena de conexión estamos especificando un path físico en el que tenemos almacenada la BD. DataContext admite otras tres sobrecargas (una de ellas es la típica cadena de conexión de ADO.NET) en la definición de la cadena de conexión.

· Definiendo el objeto DataContext de modo fuertemente tipado, lo que facilita la definición de las consultas en la BD puesto que no necesitamos utilizar GetTable tras crear una instancia de dicho objeto. Esta es la opción que vamos a utilizar. Para ello, tenemos que crear una clase que herede de DataContext.

class Program

{

//BD CLIENTES

public class CLIENTES: DataContext

{

public Table<Clientes> Customers;

public CLIENTES(string connection): base(connection){}

}

Una vez que hemos definido la primera entidad del modelo y tipado el correspondiente DataContext, ya podemos empezar a realizar consultas contra el modelo de objetos.

Realizando consultas contra el modelo de objetos definido

La filosofía de la realización de consultas es la que ya vimos cuando se definen consultas sobre objetos de memoria.

//Conexión Fuertemente Tipada

CLIENTES BD2=new CLIENTES(@"C:\Program Files\LINQ Preview\Data\CLIENTES.mdf");

//Clientes de Madrid

BD2.Log=Console.Out;

var MisClientes =

from c in BD2.Customers

where c.CiudadCliente=="Madrid"

select c;

Console.WriteLine("*********************Consulta estándar*********************");

foreach (var cliente in MisClientes)

{

Console.WriteLine("ID: {0},Nombre: {1},Ciudad: {2}",

cliente.ID_Cliente,cliente.NombreCliente,cliente.CiudadCliente);

}

Console.ReadLine();

La salida por pantalla que se obtiene nos muestra la sentencia T-SQL que LINQ To SQL envía a la BD (esta sentencia se captura mediante BD2.Log=Console.Out) y el resultado de la consulta, que se ejecuta en el momento en que se define la correspondiente iteración.

Vamos a definir ahora una consulta más compleja que permita incluir el uso de Joins a partir de que conocemos que Md_Clientes y Md_Vehicles están relacionadas mediante a través del campo ID_Cliente. Antes de realizar la consulta, tendríamos que definir una clase Vehiculos que realice el mapeo correspondiente con la tabla Md_Vehiculos. La filosofía es la misma explicada para la clase Clientes, por lo que no os reproduzco el código. Si nos centramos en la definición de la consulta, supongamos que queremos obtener para cada cliente de la BD la marca de su coche, tendríamos que definir una consulta como la siguiente:

var ClientesMarcaCoche=

from c in BD2.Customers

join ve in BD2.Vehicles on

c.ID_Cliente equals ve.ID_Cliente

orderby c.CiudadCliente ascending

select new{NIF=c.ID_Cliente,

Nombre=c.NombreCliente,Coche=ve.MarcaVehiculo};

Console.WriteLine("*********************Consulta con joins*********************");

Console.WriteLine("\n");

foreach(var cliente in ClientesMarcaCoche)

{

Console.WriteLine("NIF: {0}, Nombre: {1},Coche: {2} ",

cliente.NIF,cliente.Nombre,cliente.Coche);

}

Console.ReadLine();

Aparte del uso del join, en la consulta anterior es destacable el uso del operador orderby para obtener los resultados ordenados según un cierto criterio y el hecho de que en lugar de devolver un objeto completo como hicimos en la consulta anterior estemos devolviendo una colección arbitraria utilizando para ello un tipo anónimo. La salida que se obtiene por pantalla es la siguiente:

Hasta ahora hemos visto como definir un modelo de objetos a partir del esquema de una BD y como realizar consultas contra ese modelo de objetos, consultas que LINQ To SQL traduce a sentencias T-SQL que se envían a la BD. En los siguientes puntos comentaré como realizar operaciones habituales contra una BD: inserción de registros, actualización de datos, borrado de registros y ejecución de sentencias T-SQL (incluidos procedimientos almacenados).

Realizando operaciones contra la BD

Lo primero que vamos a hacer es añadir un registro en la tabla Md_Clientes de la BD. La clave de creación de registros está en crear una instancia de la entidad Clientes (con el operador new()) que mapea la correspondiente tabla de la BD y en el método Add() que nos permite añadir la instancia creada al objeto equivalente del DataContext que a su vez se encargará de generar la correspondiente sentencia SQL de inserción para poder reflejar el registro en la BD. Así, para crear un nuevo cliente en la BD el código necesario es el siguiente:

Console.WriteLine("******************Operando con Entidades******************");

//Nuevo registro

Console.WriteLine("Insercción");

Clientes nuevoCliente= new Clientes();

nuevoCliente.ID_Cliente="72678934C";

nuevoCliente.NombreCliente="Ángel Álvarez";

nuevoCliente.CiudadCliente="Ponferrada";

//Añadimos el registro

BD2.Customers.Add(nuevoCliente);

//Forzamos que los datos se vuelquen en la BD

BD2.SubmitChanges();

//Comprobamos que el registro se ha añadido

var ClienteAñadido=

(from c in BD2.Customers

where c.ID_Cliente=="72678934C"

select c).First();

Console.WriteLine("El cliente con NIF {0}, Nombre {1} ha sido añadido",

ClienteAñadido.ID_Cliente,ClienteAñadido.NombreCliente);

Console.ReadLine();

Como vemos, añadir un nuevo registro es realmente sencillo. Basta con crear una nueva instancia de la entidad Clientes, completar sus propiedades y añadir la instancia en el DataContext para que los datos se vuelquen en memoria. Además, para que los cambios sean efectivos tenemos que llamar al método SubmitChanges() que se encarga de iniciar una transacción (por defecto las transacciones en LINQ To SQL son de tipo implicitico para las operaciones de inserción y borrado de datos, la actualización de datos en cambio es automática y no se hace en el contexto de una transacción). Después de llevar los cambios a la BD, comprobamos que estos son efectivos definiendo una consulta en la que filtremos por ID_Cliente y a la que le aplicamos el método First() que retorna un objeto en lugar de una colección de objetos. La salida por pantalla que se obtiene es la siguiente:

Actualizar o borrar un registro es igualmente sencillo en la BD con LINQ es también bastante sencillo. Para actualizar un registro basta con recuperar el registro o registros a actualizar, cambiar sus propiedades y registrar los cambios en la BD con SubmitChanges(). Y para borrar el registro, utilizamos el método Remove() para borrar el registro o registros recuperados desde la BD y que nos interesa eliminar. El código que permite actualizar y borrar el cliente que hemos añadido antes es el siguiente:

//Actualización del registro

Console.WriteLine("Actualización");

ClienteAñadido.NombreCliente="Ángel Fernández";

ClienteAñadido.CiudadCliente="La Bañeza";

Console.WriteLine("El cliente con NIF {0}, ha sido actualizado con los siguientes datos:\n

Nombre {1} y Ciuad {2}", ClienteAñadido.ID_Cliente,

ClienteAñadido.NombreCliente, ClienteAñadido.CiudadCliente);

Console.ReadLine();

//Borrado de registro

Console.WriteLine("Borrado");

BD2.Customers.Remove(ClienteAñadido);

BD2.SubmitChanges();

foreach(var cliente in BD2.Customers)

{

Console.WriteLine("NIF: {0}, Nombre: {1},Coche: {2} ",

cliente.ID_Cliente,cliente.NombreCliente,cliente.CiudadCliente);

}

Console.ReadLine();

La salida por pantalla correspondiente es la siguiente:

Utilizando comandos T-SQL en LINQ To SQL

Para acabar con este post, os voy a mostrar como LINQ To SQL permite definir y utilizar comandos SQL o procedimientos almacenados (SP’s) en el modelo de entidades definido. Como os podréis imaginar, el uso de estos comandos y/o procedimientos almacenados pasa por definir los correspondientes métodos en la clase que definir nuestro DataContext y decorarlos de manera adecuada. Lo primero que vamos a hacer es definir estos métodos en la clase comentada. Como veréis en el código, he añadido dos:

· El método Actualizar que nos permitirá actualizar un registro de la BD. Como veis, la clave de este método está en decorarlo con el atributo Update y luego definir en su cuerpo el uso del método ExecuteCommand (propio de la clase DataContext). Como se ve en el código, este método recibe como argumentos la sentencia T-SQL y los parámetros necesarios para ejecutarla de manera adecuada.

· El método ExtraerClientesVehiculosByCiudad, que devuelve el resultado de ejecutar un cierto SP. La clave de este método está en decorarlo con el atributo StoreProcedure, en definir adecuadamente el tipo de dato a devolver, y en pasarle adecuadamente los parámetros que se necesiten para ejecutar el SP. Como veis, utilizar SP’s en nuestro modelo de entidades es más complicado que utilizar simples sentencias T-SQL, veamos el código necesario para definir los dos métodos.

//Método que ejecuta un comando T-SQL

[UpdateMethod]

public void Actualizar(Clientes Cliente)

{

Console.WriteLine("Actualización de datos");

ExecuteCommand("UPDATE [Md_Clientes] set [CiudadCliente]={0} WHERE ID_Cliente={1}",

Cliente.CiudadCliente,Cliente.ID_Cliente);

}

//Método que ejecuta un SP complejo

[StoredProcedure (Name="ExtraerClientesVehiculosByCiudad")]

public StoredProcedureResult<ClientesVehiculos>

ExtraerClientesVehiculosByCiudad(

[Parameter(Name="CiudadCliente",DBType="NVarChar(50)")] string CiudadCliente)

{

return this.ExecuteStoredProcedure<ClientesVehiculos>(

((MethodInfo)(MethodInfo.GetCurrentMethod())),CiudadCliente);

}

Como vemos en el código anterior, utilizar un SP es más complejo, por lo que merece la pena explicar un poco más en detalle cómo se define el método:

· Decorar el método con el atributo StoredProcedure, además especificaremos el parámetro Name en el que indicamos el nombre del SP a ejecutar.

CREATE PROCEDURE ExtraerClientesVehiculosByCiudad

@CiudadCliente NVARCHAR(50)

select C.ID_Cliente, C.CiudadCliente, V.MarcaVehiculo

from Md_Clientes C

left join Md_Vehiculos V on

C.ID_Cliente=V.ID_Cliente

where CiudadCliente=@CiudadCliente

order by C.CiudadCliente

· En la declaración del método, vemos que es de un tipo especial: StoredProcedureResult<T>, que hereda de las clases IEnumerable<T> y StoredProcedureResult. Por lo tanto, implementa una interfaz de tipo IEnumerable y necesitaremos definir la correspondiente clase que nos de la descripción de la colección. Lógicamente, la clase que implementemos se tendrá que corresponder con lo que esperamos que nos devuelva el SP.

public class ClientesVehiculos

{

private string _ID_Cliente;

public string ID_Cliente

{

get {return this._ID_Cliente;}

set {this._ID_Cliente=value;}

}

private string _CiudadCliente;

public string CiudadCliente

{

get {return this._CiudadCliente;}

set {this._CiudadCliente=value;}

}

private string _MarcaVehiculo;

public string MarcaVehiculo

{

get {return this._MarcaVehiculo;}

set {this._MarcaVehiculo=value;}

}

Cómo parámetros del método, definiremos justamente los parámetros que espera el SP y decorándolos adecuadamente para que sean del tipo que esperado. En nuestro caso, el SP necesita un único parámetro, @CiudadCliente, por lo que en código lo especificamos mediante el parámetro CiudadCliente convenientemente decorado con el atriburo parameter:

( [Parameter(Name="CiudadCliente",DBType="NVarChar(50)")] string CiudadCliente)

· Lo siguiente que hacemos es ejecutar el procedimiento y devolver el resultado de la ejecución. Para ello llamamos al método ExecuteStoredProcedure de la clase DataContext, el cuál recibe como parámetros un tipo MethodInfo y el parámetro o parámetros que necesita el SP para ser ejecutado correctamente.

Nota: Por supuesto, se pueden definir métodos que ejecuten un procedimiento almacenado y devuelvan tipos simples (como un entero) o tipos más complejos en los que a priori no sepamos el formato (en cuanto a número de columnas) que nos devuelva el SP (en este caso se utiliza un tipo shape).

Una vez que hemos definido los métodos necesarios para habilitar el uso de sentencias T-SQL y SP’s en nuestro código, utilizarlos es sencillo. El código necesario para utilizar los métodos anteriores es el siguiente:

Console.WriteLine("****************Uso de Comandos T-SQL****************");

Console.WriteLine("Sentencia T-SQL");

var ClienteExistente=

(from c in BD2.Customers

where c.ID_Cliente=="71505286B"

select c).First();

Console.WriteLine("Datos antes de actualizar ID={0},Ciudad={1}",

ClienteExistente.ID_Cliente,ClienteExistente.CiudadCliente);

ClienteExistente.CiudadCliente="Oviedo";

BD2.Actualizar(ClienteExistente);

Console.WriteLine("Datos después de actualizar ID={0},Ciudad={1}",

ClienteExistente.ID_Cliente,ClienteExistente.CiudadCliente);

Console.WriteLine("\n");

Console.WriteLine("****************Procedimiento almacenado****************");

StoredProcedureResult<ClientesVehiculos> resultados =

BD2.ExtraerClientesVehiculosByCiudad("Madrid");

foreach(ClientesVehiculos resultado in resultados)

{

Console.WriteLine("ID Cliente: {0},Ciudad Cliente: {1},Marca Vehiculo:

{2}",resultado.ID_Cliente,resultado.CiudadCliente,resultado.MarcaVehiculo);

}

Console.ReadLine();

La salida por pantalla para este caso es la siguiente:

Y hasta aquí (que no es poco), lo que os quería contar sobre LINQ To SQL. Espero vuestros comentarios y que os hayan resultado interesantes los aspectos cubiertos en el post. Os dejo para que os podáis descargar y probar el código del proyecto con todas las funcionalidades de LINQ To SQL y el script de creación de la BD (tablas, datos y procedimientos almacenados incluidos) que he usado para las pruebas. Os animo a que probéis LINQ , a mi me ha impresionado bastante y resulta muy natural utilizarlo si estás familiarizado con T-SQL. En otro post os contaré de que va LINQ To XML.

Comenzando con LINQ: Bases y Consulta de Datos en Memoria!

Juan Carlos González Martín — Tue, 13 Feb 2007 11:25:00 GMT

Como os comentaba en un post previo, uno de los cometidos como integrantes de un centro de innovación de Microsoft es estar al día de las últimas novedades en las que Microsoft está trabajando, conocer en detalle dichas novedades, cacharrear con ellas, etc, siempre teniendo en mente que resulta realmente complicado seguir el ritmo de creación de Microsoft. Por este motivo, nos planteamos mes a mes que tecnologías sería interesante conocer para transmitir el conocimiento a las empresas de Cantabria y ponerlas en la parrilla de salida hacía las futuras tendencias tecnológicas. Pues bien, una de las últimas tecnologías que hemos estado probando es LINQ, y francamente estoy sorprendido tanto por sus características (construida sobre las innovaciones de lenguaje de C# y VB 9.0) como por sus prestaciones: habilitar el uso de consultas a objetos de memoria, orígenes de datos, XML o cualquier otro “ente” que se nos ocurra (a partir de la capacidad de extensibilidad de LINQ).

Para los nuevos en la materia, LINQ o Language Integrated Query es un framework de consultas que habilita el uso de órdenes tipo SQL integradas en el lenguaje de programación a partir de una serie de operadores estándar de consulta que permiten realizar consultas sobre cualquier colección de tipo IEnumerable<T>. La arquitectura de LINQ es la siguiente:

¿Qué proporciona LINQ?

Antes de entrar en materia, no está de más tener claro que ventajas o características nos da LINQ. Destacaría las siguientes:

· Un framework unificado de acceso a objetos, datos y XML. Y que además es completamente extensible.

· Consultas tipo SQL en código C# y VB:

o Sintaxis potente, similar a T-SQL.

o La curva de aprendizaje es reducida.

· Comprobación de tipos e intellisense.

· Modelo de proveedores extensible, ya se han definido extensiones hacia SQL (LINQ To SQL) y XML (LINQ to XML).

· Una serie de operadores estándar de consulta out-of-the-box, que permiten definir operaciones de recorrido, filtro y proyección de modo declarativo en el lenguaje.

· ¿Se os ocurren más?

Bueno, después de esta pequeña introducción a LINQ (para más información, os recomiendo que vayáis al sitio oficial del proyecto LINQ), es hora de pasar a la acción. También es recomendable la información y ejemplos que en el sitio de El Guille han colgado tanto Guillermo Som como Octavio Hernández En este post comentaré algunas de las innovaciones del lenguaje (para C#) conocidas, así como el modo de definir consultas integradas en el lenguaje contra un objeto de memoria.

C# 3.0: Innovaciones en el lenguaje

Como comentábamos, LINQ se basa en muchas de las innovaciones del lenguaje que viene con C# 3.0 y VB 9.0. Antes de empezar con las innovaciones, seguro que alguno os está preguntando que se necesita para poder probarlas:

· Evidentemente, Visual Studio 2005 (No necesitáis bajaros la última CTP de Orcas).

· LINQ Preview para VB y C# de Mayo de 2006 (no he encontrado una versión posterior para poder utilizarla con VS 2005, pero para el propósito de este post es suficiente), que os podéis descargar en este enlace. Al instalar esta Preview, veréis que además de las correspondientes plantillas de proyecto, se instalarán un montón de ejemplos y HandOn labs tanto para VB como C#.

Una vez instalada la preview, si os vais a VS 2005 veréis que aparece una nueva entrada en los tipos de proyectos: LINQ Preview con las correspondientes plantillas añadidas.

Tras pulsar OK, nos saldrá un mensaje advirtiéndonos que este tipo de proyecto se refiere a una versión no soportada de C# 3.0 y que ciertas funcionalidades podrían no funcionar de manera correcta. Corremos el riesgo, y ya estamos listos para empezar a ver las innovaciones en el lenguaje, las cuales están disponibles (no tenéis más que examinar las referencias que se añaden al proyecto) a través de los siguientes espacios de nombres:

· using System.Query;

· using System.Xml.XLinq;

· using System.Data.DLinq;

· using System.Expressions; (está la tenemos que añadir para poder crear árboles de expresión como luego veremos).

Entre estas innovaciones son destacables las siguientes

· Declaración implícita de tipos, lo que implica que cuando declaramos un objeto no es necesario que especifiquemos su tipo, sino que el compilador es capaz de inferirlo de manera dinámica en tiempo de compilación a partir del valor estático asignado. La clave de la declaración de tipos implícitos está en el uso de la palabra reservada var. En la práctica, esta innovación facilita poder referenciar en nuestro código instancias de tipos anónimos. Veamos un ejemplo de declaración implícita de tipos.

//Declaración ímplicita de tipos

var numero=2;

var cadena="Hola mundo desde LINQ!";

Console.WriteLine("numero es de tipo " + numero.GetType()

+ ".El valor de numero es " + numero);

Console.WriteLine("cadena es de tipo " + cadena.GetType()

+ ".El valor de cadena es " + cadena);

Console.ReadLine();

La salida por pantalla que obtendríamos para este caso es:

La ventaja que nos aporta esta innovación es que libera al desarrollador de tener que definir de manera explícita los tipos que necesite al programar una aplicación. Esta característica es clave para LINQ, puesto que el desarrollador no necesita definir los tipos que va a devolver una consulta, sino que es el compilador quien dinámicamente va a realizar esta tarea.

· Tipos anónimos, esta característica permite crear objetos de tipo anónimo, es decir, de nuevo podemos omitir el tipo cuando instanciamos un objeto y este es construido de manera dinámica en tiempo de compilación. Además de poder definir un objeto de manera anónima, es posible definir propiedades asociadas al mismo. Un ejemplo de esta innovación es el siguiente:

var Santander=new {NombreCiudad="Santander", PoblacionCiudad=180000};

Console.WriteLine("La ciudad de " + Santander.NombreCiudad + " tiene una población de " +

Santander.PoblacionCiudad + " habitantes");

Console.ReadLine();

Console.WriteLine("Santander es de tipo " + Santander.GetType());

Console.ReadLine();

En este caso, la salida por pantalla es la siguiente:

Como vemos, aunque hemos declarado un tipo anónimo, el compilador es capaz de inferir el tipo correspondiente y sacar por pantalla los valores de sus propiedades. También vemos que el tipo devuelto es <Projection>f __0 que es el que se infiere en tiempo de compilación. Si miramos el ensamblado a través de la utilidad reflector, tendremos más información respecto al tipo generado en tiempo de compilación.

· Inicializadores de objetos, esta innovación ya la vimos en la anterior. Lo que permite es inicializar objetos (anónimos o no) en el momento en que los instanciamos.

public class Ciudad

{

public string NombreCiudad;

public int PoblacionCiudad;

}

static void Main(string[] args)

{

Var Santander=new Ciudad{NombreCiudad="Santander",

PoblacionCiudad=180000};

Console.WriteLine("La ciudad de " + Santander.NombreCiudad +

" tiene una población de " +

Santander.PoblacionCiudad + " habitantes");

Console.ReadLine();

Console.WriteLine("Santander es de tipo " + Santander.GetType());

Console.ReadLine();

}

En este caso, en el código estamos combinando la declaración implícita de tipos y la inicialización de objetos. Por lo que ahora, el tipo devuelto es Ciudad.

· Métodos de extensión, o dicho de otra forma: mecanismos que habilitan la extensión de objetos. La base de esta innovación consiste en crear clases de extensión que nos permitan extender la funcionalidad de tipos existentes a partir de crear nuevos métodos. Los métodos de extensión son métodos estáticos que son habilitados como métodos de extensión a través de la palabra reservada this.

static class ExtensionDeTipos

{

public static string Saludar(this string nombre)

{

return ("Hola " + nombre + "!");

}

static void Main(string[] args)

{

string nombre = "Mundo";

Console.WriteLine(nombre.Saludar());

Console.ReadLine();

}

Mediante el código anterior, hemos definido una clase estática dentro de la cuál definiremos nuestros métodos de extensión. En este caso, estamos extendiendo nombre que es de tipo cadena mediante el método Saludar y como vemos la clave de esta extensibilidad es la palabra reservada this.

Una característica interesante de los métodos de extensión es que se pueden añadir a cualquier tipo, incluyendo tipos genéricos como List <T> y Dictionary <T>.

· Expresiones lambda, que habilitan el uso de condiciones sin tener que especificar el tipo. En la práctica, las expresiones lambda permiten definir de un modo más claro y directo los métodos anónimos de C # 2.0 (quizás esta es una de las innovaciones más destacadas de C# 3.0 y una de las bases de LINQ junto con los métodos de extensión). Para entender esta innovación, no está de más recordar que es un método anónimo en C# 2.0:

List <string> NombresLongitudMayor5=nombres.FindAll(delegate(string s)

{return(s.Length)>=5;});

Pues bien, la expresión anterior se puede escribir de manera más directa en C# 3.0 utilizando una expresión lambda, que unida a otras innovaciones simplifica mucho el código anterior

var NombresLongitudMayor5=nombres.FindAll(s => s.Length>=5);

Como vemos, una expression lamba consta de tres elementos:

o Un parámetro de lista (s), que puede ser tipado de manera explícita o implícita. En el ejemplo, de nuevo estamos utilizando tipado implícito.

o El token =>.

o La expresión a aplicar (la longitud sea 10).

Un ejemplo completo de uso de expresiones lambda sería el siguiente:

var nombres=new List<string>();

nombres.Add("Luis");

nombres.Add("Juan Carlos");

nombres.Add("Pepe");

nombres.Add("Ramón");

var NombresLongitudMayor5=nombres.FindAll(s => s.Length>=5);

foreach(string nombre in NombresLongitudMayor5)

{

Console.WriteLine(nombre);

}

Console.ReadLine();

· Árboles de expresión, que son representaciones más eficientes en memoria de una expresión lambda. La idea de los árboles de expresión es dar una visión más transparente e implícita que el código IL, además de habilitar la utilización de expresiones lambda como datos en tiempo de ejecución. La clave de la definición de árboles de expresión está en un nuevo tipo: Expression <T>. Veamos un ejemplo:

Expression<Func<string,bool>> NombresLongitudMayor5= s => s.Length>=5;

Console.WriteLine(NombresLongitudMayor5);

Console.ReadLine();

Código que produce la siguiente salida:

Como vemos, el árbol de expresión nos permite traducir la expresión lambda a datos que son manipulables. Pero, ¿Para qué nos sirven los árboles de expresión? Pues, y como se comenta en la documentación disponible del proyecto LINQ, para una implementación de acceso a base de datos, nos permitiría traducir los árboles a sentencias apropiadas para un tipo particular de BD. De hecho, esto es lo que se hace en LINQ to SQL (anteriormente DLinq), en el que los árboles de expresión son traducidos a sentencias T-SQL que puedan ser evaluadas en la BD.

LINQ to Objetcs: Consultas a objetos de memoria

Después de haber introducido algunas de las novedades del lenguaje que vendrán con C# 3.0 y de modo equivalente con VB y sobre las que se apoya LINQ, ya es hora de ver las posibilidades de LINQ en la práctica. Básicamente, LINQ utiliza estas innovaciones para definir habilitar el uso de consultas integradas en el lenguaje de programación. Para ello define una serie de operadores estándares de consulta que son métodos de extensión definidos sobre IEnumerable <T>, y cuyas características más relevantes son las siguientes:

· Están construidos a partir de las innovaciones en el lenguaje vistas.

· Permiten trabajar con datos en memoria. Esto es especialmente interesante para cuando trabajemos contra datos de una BD, de un archivo XML o cualquier otro origen de datos.

· Las operaciones siempre se realizan en memoria.

Aquí os dejo el listado de los operadores estándar de consulta. Para conocer en detalle dichos operadores, os recomiendo la lectura de la traducción por Octavio Hernández del documento The LINQ Proyect. Este documento junto con otros también traducidos al castellano lo podéis encontrar aquí.

*Tipo de Operador*	*Operador*
*Restricción*	*Where*
*Proyección*	*Select, SelectMany*
*Ordenación*	*OrderBy, ThenBy*
*Agrupamiento*	*GroupBy, Reverse, GroupJoin*
*Cuantificadores*	*Any, All*
*Particionado*	*Take, Skip, TakeWhile, SkipWhile*
*Conjuntos*	*Distinct, Union, Intersect, Except*
*Elementos*	*First, FirstOrDefault, ElementAt*
*Agregación*	*Aggregate,Count, Sum, Min, Max, Average*
*Conversión*	*ToArray, ToList, ToDictionary*
*Casting*	*OfType<T>*
*Join*	*Join, GroupJoin, On*

Además del uso de los operadores estándar de consultas, LINQ utiliza otra innovación conocida como la evaluación diferida de consultas, que implica que una consulta no es realmente evaluada hasta el momento en que se itera con ella. La ventaja de esta técnica es que las consultas van a poder ser evaluadas múltiples veces.

Sin más, vamos a ver un ejemplo de LINQ contra objetos. El código sería el siguiente:

//Clase a partir de la cuál definiremos el objeto en memoria a consultar

public class Ciudad

{

public string NombreCiudad;

public int PoblacionCiudad;

}

static void Main(string[] args)

{

//Objeto en memoria sobre el que vamos a habiltiar la consulta

var ciudades=new List<Ciudad>{

{NombreCiudad="Santander",PoblacionCiudad=180000},

{NombreCiudad="León",PoblacionCiudad=150000},

{NombreCiudad="Ponferrada",PoblacionCiudad=75000},

{NombreCiudad="Madrid",PoblacionCiudad=4000000}

};

//Consulta...

var consulta=

from c in ciudades

where c.PoblacionCiudad>150000

select new {c.NombreCiudad,c.PoblacionCiudad};

Console.WriteLine("Ciudades con más de 150000 habitantes: ");

//Aquí es dónde realmente se evalua la consulta...

foreach(var c in consulta)

{

Console.WriteLine("Ciudad: {0}, Población {1}",

c.NombreCiudad,c.PoblacionCiudad);

}

Console.ReadLine();

En el código anterior hemos utilizado varias de las innovaciones vistas, a ver quién me las dice a partir de leer el post (así podré medir si me explico bien o no :P). La salida por pantalla sería la siguiente:

Bueno, pues hasta aquí el primer post que desde el CIIN hacemos de LINQ. Espero vuestros comentarios y respuestas a la dudilla planteada.