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

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:

Post_LINQ_VisualStudio2008_B2 

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:

Post_LINQ_VisualStudio2008_B2_2

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.

Post_LINQ_VisualStudio2008_B2_3_1

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:

Post_LINQ_VisualStudioOrcas_3_2 Post_LINQ_VisualStudioOrcas_4

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.
  •  …

Post_LINQ_VisualStudioOrcas_8

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:

Post_LINQ_VisualStudioOrcas_9

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

Post_LINQ_VisualStudioOrcas_9_1

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:

Post_LINQ_VisualStudioOrcas_9_2 Post_LINQ_VisualStudioOrcas_9_3

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; 
     

Post_LINQ_VisualStudio2008_B2_10

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:

Post_LINQ_VisualStudio2008_B2_11

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

Publicado por

Juan Carlos González

Juan Carlos es Ingeniero de Telecomunicaciones por la Universidad de Valladolid y Diplomado en Ciencias Empresariales por la Universidad Oberta de Catalunya (UOC). Cuenta con más de 12 años de experiencia en tecnologías y plataformas de Microsoft diversas (SQL Server, Visual Studio, .NET Framework, etc.), aunque su trabajo diario gira en torno a SharePoint & Office 365. Juan Carlos es MVP de Office Servers & Services desde 2015 (anteriormente fue reconocido por Microsoft como MVP de Office 365 y MVP de SharePoint Server desde 2008 hasta 2015), coordinador del grupo de usuarios .NET de Cantabria (Nuberos.Net, www.nuberos.es), co-fundador y coordinador del Grupo de Usuarios de SharePoint de España (SUGES, www.suges.es), así como co-director de la revista gratuita en castellano sobre SharePoint CompartiMOSS (www.compartimoss.com). Hasta la fecha, ha publicado 8 libros sobre SharePoint & Office 365 y varios artículos en castellano y en inglés sobre ambas plataformas.

5 comentarios en “Visual Studio 2008 Beta2: Realizando Consultas con LINQ (I)”

  1. Con este codigo se puede ejecutar consultas sin problemas sobre la capa logica de nuestras aplicaciones.

    System.Linq;

    IEnumerable NombreMetodo;
    NombreMetodo = from v in listaDatos where v.Campo_ID== item.LlaveForanea_ID select v;

    //Filtra los datos de una lista frente a un objeto entidad.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *