SharePoint 2010: Trabajo con LINQ To SharePoint (I)!

Otra de las novedades más esperadas dentro de la plataforma SharePoint es el soporte de LINQ para realizar consultas de listas de SharePoint. En SharePoint 2010 aparece LINQ To SharePoint, que permite realizar consultas LINQ de información almacenada en la plataforma de una forma más clara, sencilla de comprender, acceso a datos fuertemente tipado y a un nivel de abstracción superior. Como sabéis, si trabajamos con LINQ To SQL o ADO.NET Entity Framework, al realizar una consulta LINQ por debajo tendremos un objeto (DataContext y ObjectContext) respectivamente que se encarga de enviar el correspondiente T-SQL a la BD subyacente. En el caso de SharePoint el objeto DataContext correspondiente es el que se encarga de generar y realizar la consulta CAML que se corresponde con la consulta LINQ definida. En este primer post sobre LINQ To SharePoint, vamos a realizar una sencilla consulta LINQ  a una lista personalizada de SharePoint. Empecemos. (Nota: Todo lo que veáis aquí de SharePoint 2010 tiene que ver con la CTP de julio. La versión de Visual Studio 2010 utilizada es la Ultimate Beta2).

Generación de la clase proxy de LINQ To SharePoint para acceder a los datos

En el ejemplo que voy a realizar, vamos a acceder a una lista personalizada denominada Products que tiene dos únicas columnas. Para acceder a los datos de la lista vía LINQ To SharePoint, lo primero que tenemos que hacer es generar la correspondiente clase proxy que nos permita conectarnos a la misma. Para ello, y con la CTP de julio de SharePoint 2010 tenemos que utilizar la utilidad SPMetal que se encuentra en la siguiente ruta:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\bin

Una vez situados en dicho path, para generar la clase proxy para poder acceder a los datos de una lista de un sitio…y en general a todo el sitio, ejecutamos el siguiente comando:

spmetal /web:http://win-lpgjegdoo6f /namespace:Intranet /code:Intranet.cs

Cómo veis, en la sintaxis de spmetal:

• En primer lugar especificamos la url del sitio de SharePoint en el que vamos a generar la clase proxy. Para ello utilizamos el parámetro web.
• A continuación mediante el parámetro namespace especificamos el espacio de nombres a usar en la clase proxy a generar.
• Finalmente el parámetro code nos permite especificar el nombre del archivo de C# generado.

Si ejecutamos el comando anterior, transcurridos unos segundos tendremos la clase proxy lista para ser utilizada en VS 2010 Beta2. Si queréis ver las opciones de ejecución de SPMetal, basta conque lo ejecutéis tal cual para ver los parámetros de que dispone y algunos ejemplos de sintaxis.

Creación de la WebPart de visualización

Para mostrar los datos devueltos por la consulta LINQ To SharePoint que voy a definir, voy a utilizar las Visual Studio Tools para SharePoint 2010, y en concreto la posibilidad que nos brinda de crear Web Parts visuales para facilitar su desarrollo:

• Arrancamos Visual Studio 2010 Beta 2, y nos vamos a crear un proyecto para SharePoint 2010 de tipo Visual Web Part.
• Tras pulsar OK, nos llevamos la primera en la frente: aparece un mensaje de error diciéndonos que no es posible crear el proyecto porque se necesita SharePoint Server instalado en el servidor…toma ya…lógicamente me quedo sorprendido porque en mi máquina virtual tengo instalada la CTP de julio de SharePoint Foundation 2010 y desde luego no me esperaba este resultado. Aunque he de decir que no me sorprende, recuerdo que algo parecido sucedió con la plantilla de creación de workflows para SharePoint 2007 que apareció con Visual Studio 2008. Seguro que en breve a alguien se le ocurre como solucionar esta cag…digo este problemilla.

Por suerte, parece que los proyectos creados para SharePoint 2010 con la Beta1 de las Visual Studio Tools para SharePoint 2010 funcionan con la Beta2 y me las arreglé para conseguir el resultado esperado. Si no hubiera sido por el inconveniente anterior, al pulsar OK en le proyecto se inicia un asistente en el que se nos pie el sitio de SharePoint que se va a utilizar para depurar la solución y el modo de despliegue de la misma (que para una Web Part visual es Full Trust al menos en la CTP de julio de SharePoint 2010):

Como os decía, para superar el inconveniente anterior probé a abrir un proyecto ya creado con la Beta 1 de Visual Studio 2010 y esta vez, para mi sorpresas, no hubo ningún problema. En VS 2010, la estructura típica de un proyecto para SharePoint 2010 se caracteriza por los siguientes elementos:

• El grupo de ítems particulares correspondientes a la plantilla elegida. En este caso se trata de una Web Part Visual que no es más que está representado por tres elementos:
  • El primero de ellos tiene la extensión .WebPart y nos permitirá parametrizar ciertas configuraciones de la Web Part Visual como su título, descripción. 
  • El segundo de los elementos es un archivo .cs en el que se definen los métodos clásicos (este trabajo lo hace Visual Studio) para renderizar la Web Part en la UI de SharePoint: CreateChildControls() y Render().
  • Finalmente, el último de los elementos es un user control (extensión .ascx) y es el que nos permite modelar visualmente la Web Part y añadirle la lógica correspondiente en el archivo de código asociado.
• Una sección Package o paquete en la que se “empaquetan” las distintas features o características que contiene la solución. En este caso concreto sólo tendremos una única feature. Como podéis ver, configurar un package se simplifica bastante gracias al nuevo diseñador que incluye las VS Tools. Comentaros que dado un proyecto de SharePoint 2010, sólo puede contener un único paquete.
• Una sección Features en la que tendremos todas las características del proyecto actual. En este caso tendremos una única característica, pero podríamos tener tantas como elementos de SharePoint añadamos al proyecto: manejadores de eventos, flujos de trabajo, etc. De nuevo, la gestión de las características se simplifica notablemente gracias al nuevo diseñador incorporado en VS 2010. A su vez, cada característica puede contener los elementos del proyecto que necesitemos.

Una vez explicados estos detalles generales de estructura de un proyecto de SharePoint, vamos al lío: a trabajar con la Web Part visual:

• Lo primero y más importante, podemos diseñar la Web Part de forma visual o a “pelo” trabajando con el markup. En mi caso he hecho uso de las dos cosas, porque por un lado voy a utilizar un control de SharePoint de tipo SPGridView y por otro lado una simple etiqueta.
• El markup necesario para una web part tan sencilla es el siguiente:

<%@ Assembly Name="$SharePoint.Project.AssemblyFullName$" %> <%@ Assembly Name="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Import Namespace="Microsoft.SharePoint" %> <%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Control Language="C#" AutoEventWireup="true" CodeBehind="VisualWebPart1UserControl.ascx.cs" Inherits="SPLinqDemo.VisualWebPart1.VisualWebPart1UserControl" %> <%@ Import Namespace="Microsoft.SharePoint.WebControls" %> <SharePoint:SPGridView ID="spGriedView" runat="server" AutoGenerateColumns="false">     <HeaderStyle HorizontalAlign="Left" ForeColor="Navy" Font-Bold="false" />     <Columns>         <SharePoint:SPBoundField DataField="Title" HeaderText="Title" HeaderStyle-HorizontalAlign="Center">         </SharePoint:SPBoundField>                 <SharePoint:SPBoundField DataField="Amount" HeaderText="Amount" HeaderStyle-HorizontalAlign="Center">         </SharePoint:SPBoundField> </Columns> </SharePoint:SPGridView> <asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>

• Visualmente podéis ver que el diseñador no es capaz de interpretar el control SPGridView ya que no forma parte de la paleta de controles disponible para SharePoint en el diseñador, aunque esto no supondrá problema alguno en la creación de la WebPart.
• Lo siguiente que tenemos que hacer es añadir a nuestro proyecto la clase proxy generada con SPMetal. Os recomiendo revisar lo que ha generado con SPMetal…aunque quizás hasta la RC o RTM es mejor no hacerle mucho caso porque seguramente falten elementos por generar (lo digo con conocimiento :P). Básicamente, la clave es que tendremos una clase que deriva Microsoft.SharePoint.Linq.DataContext y que es la que se encarga de gestionar las conexiones a las diferentes listas de SharePoint. Para cada lista, se habrá generado el correspondiente EntityList.
• Una vez hecho esto, añadimos una referencia al ensamblado Microsoft.SharePoint.dll ubicado en el path:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI

• Nos vamos a la vista de código del control de usuario vinculado a la Web Part Visual y añadimos las siguientes directivas using:

using System.Linq; using Intranet; using Microsoft.SharePoint; using Microsoft.SharePoint.Linq;

• En el evento Page_Load() del control añadimos el siguiente código:

try             {                 IntranetDataContext dc =                      new IntranetDataContext(SPContext.Current.Web.Url);                   var ListData = from an in dc.Products                                select new { an.Title, an.Amount };                   this.spGriedView.DataSource = ListData;                 this.spGriedView.DataBind();                 this.Label1.Text = "";               }             catch (Exception ex)             {                                 this.Label1.Text=ex.Message;             }

• Cómo veis, trabajar con LINQ To SharePoint es similar a como se trabaja con el resto de sabores de LINQ To “Algo”:
  • En primer lugar, tenemos que crear una instancia del objeto DataContext correspondiente y que se haya definido en la clase proxy generada por SPMetal.
  • A continuación, definimos la consulta LINQ correspondiente.
• Compilamos el código para asegurarnos que no hay errores.
• Para desplegar la Web Part, basta con hacer clic con el botón derecho del ratón en el nombre del proyecto y pulsar Deploy, con lo que ya la tenemos lista la Web Part para usar en SharePoint.

Despliegue de la Web Part en SharePoint

Finalmente, vamos a desplegar la Web Part en un sitio de SharePoint existente. En mi caso, la voy a desplegar en una página de Web Parts almacenada en una biblioteca de documentos:

• Navegamos hasta la página en cuestión.
• A través de la nueva Ribbon de SharePoint 2010, editamos la Web Part.
• Seleccionamos una zona de Web Parts en la que insertar la que acabamos de crear. De esta forma, aparece en la Ribbon una pestaña Insert.
• En la pestaña Insert, seleccionamos Web Part de manera que se muestra justo encima de nuestra página la nueva área de insercción de Web Parts que incorpora SharePoint 2010.
• Nos vamos a la categoría Custom dentro de listado de Web Parts disponibles y seleccionamos nuestra Web Part.

• Pulsamos Add y listo, ya tenemos la Web Part de LINQ To SharePoint operativa.

Y hasta aquí llega este primer post sobre LINQ To SharePoint. Espero que os haya resultado interesante.