400380103. LINQ a Web 2.0

En el sentido más amplio, Web 2.0 se refiere a la próxima generación de aplicaciones web. Un ejemplo es el registro social de páginas. Para la mayoría de la gente, el registro social (bookmarking) implica el uso de sitios como del.icio.us y digg.com, en donde los usuarios encuentran contenido interesante y lo registran en el sitio de registro social que elijan. No sólo pueden los usuarios volver a esos sitios para ver sus registros de página almacenados en un centro, sino que toda la comunidad que se mueve entorno al sitio puede navegar los registros públicos mediante breves palabras clave o etiquetas.
Si bien este modelo funciona bien para Internet en general, el registro social a nivel de empresa tiene un conjunto de reglas y objetivos totalmente diferente. El personal de una empresa usa el registro social para organizar documentación y recursos a compartir con personas, grupos distintos y toda la organización. Dicho esto, la gente no va a usar del.icio.us para registrar las investigaciones de proyectos internos de la compañía, ni lo usarán para registrar documentos creados por personas dentro de la organización. Para que el registro social en una empresa sea efectivo necesitamos un modelo nuevo que atienda las necesidades y deseos del registro social de la empresa.

Cuando empezamos a evaluar la eficacia del registro social en una empresa, empezamos con Scuttle (sourceforge.net/projects/scuttle/), una aplicación open-source, escrita en PHP y que se ejecuta en MySQL. Scuttle comparte su diseño con del.icio.us y digg.com y es una plataforma de registro para consumo del público en general. Aunque esto cumple con algunas de las necesidades de la empresa, no se encarga de la seguridad adicional y la simplicidad de mantenimiento y mejora que desearíamos para nuestra plataforma de Registro Social Para Empresas (Enterprise Social Bookmarking -ESB). El alcance y volumen de datos de una empresa que tiene interés para los consumidores públicos puede diferir en gran medida del de consumidores de la plataforma ESB. Si se intenta satisfacer ambas audiencias con la misma herramienta no se lograría satisfacer completamente a ninguna.

Sabiendo que necesitábamos algo construido específicamente para el registro social en la empresa, decidimos comprobar la calidad de ASP.NET 2.0 para ver si podía ofrecer la plataforma base sobre la que podríamos construir nuestra nueva herramienta ESB. En el presente artículo, doy una visión desde dentro de las aplicaciones que hemos producido y lo que hemos logrado discernir mientras las creábamos.

Controles ASP.NET y el Zen del diseño CSS

En los albores del diseño HTML y del diseño web, la gente creía que las etiquetas

Listado número 1
La anterior producción HTML era par un control de GridView que fue autoformateado a “azucar moreno”, uno de los formatos más simples. No hay aquí ni un solo uso de hoja de estilo, ni hay una forma sencilla de hacer que los elementos de GridView se atengan a un diseño puro de CSS (me han dicho que es posible, pero que requiere mucho más trabajo de lo que debería ser necesario.

¿Le habría resultado tan difícil a Microsoft producir una rejilla div/span que correspondiera a una suite base de clases CSS y dejar que los desarrolladores hicieran caso omiso del estilo de la rejilla y usaran CSS? Necesito ahora justificar por qué no pude usar divs y spans antes de registrar una página .aspx que reproduce tablas. ASP.NET –y más concretamente Web 2.0- sería un sitio mejor si todos siguieran la misma regla. Para ilustrarlo, echemos una ojeada al HTML del ejemplo 1, que muestra un único registro de forma que permite el uso fácil de CSS.

Ejemplo 1: HTML que permite el uso fácil de CSS.

Podemos después aplicar cualquier hoja de estilo para crear millones de distintos look-and-feels para este output. Además de que el output que permite el uso de CSS es más fácil de leer, más flexible y más dúctil para los diseñadores de web profesionales, también descarga con más rapidez y ofrece una página que es más ligera que otra en la que cada aspecto de cada hilera de estilo de los datos está insertado directamente en esa hilera de datos. Un posible aspecto para el HTML precedente se ve en la figura 1, en la que el HTML precedente se reprodujo mediante la hoja de estilo Scuttle.

Figura 1: Ejemplo reproducido mediante la hoja de estilos Scuttle.

En general, se puede enredar con los controles que nos permiten suministrar plantillas de output para producir un output que permite el uso de CSS. Sin embargo, controles como DataList realmente envuelven plantillas individuales de hilera dentro de las hileras y células de la tabla – convirtiendo así ese control en algo totalmente inútil. Además, hay que tener cuidado con el control GridView y muchos de los controles base de Web Part; tienden a abusar de las tablas y van acumulando muy mal karma CSS.

Lo que yo he visto es que el tiempo empleado en convertir algunos de los controles base (como GridView) para que produzcan output que permita el uso de CSS es dos veces más que lo que se tarda en producir un output propio que permite el uso de CSS (incluida la funcionalidad de la rejilla, especialmente si utilizamos Atlas para la edición dentro de la red) en un Repetidor.

¿Son los Typed DataSets una fila de datos viable?

Es más fácil trabajar con Typed DataSets en ADO.NET 2.0 y son más sencillos de usar que Typed DataSets en ADO.NET 1.0/1.1. La premisa básica tras un Typed DataSet es que se crea un fichero XSD (Definición de Esquema XML) que modela un esquema de base de datos o una sub-sección del esquema de base de datos. Este XSD es después convertido en una clase C# en el momento de la construcción, se puede usar en runtime y ofrece miembros conscientes de IntelliSence. Además, creímos que podríamos estar obteniendo un gran beneficio con miembros muy “typed”. Por desgracia, los miembros muy “typed” no son más que una fachada. Bajo la caperuza, el Typed DataSet sigue siendo simplemente DataSet que almacena todo en términos de objetos. La cantidad de asignación innecesaria que se produce con Typed DataSets era inaceptable.

Para poner datos en un DataSet normalmente empleamos un DataAdapter. En el caso de un Typed DataSet hay TableAdapters especializados que son responsables de consultar la base de datos, completar tablas y persistir en cambios de vuelta a la base de datos tales como inserciones, actualizaciones y eliminaciones. En el listado número 2, que puebla un Typed DataSet , no hay pista inline, indicación o ligera referencia a qué datos se están poblando aparte del nombre de método. Como yo escribí el código, sé que GetAllBookmarksWrtUser en la clase BookmarksTableAdapter realmente se refiere a un procedimiento almacenado en mi base de datos denominado moniker_GetAllBookmarksWrtUser. Por suerte tenía unas convenciones para los nombres que facilitaban el descifrado. Pero ¿qué pasaría si yo estuviera examinando este código y no fuera el autor? O ¿qué pasaría si no tuviera acceso directo a la base de datos? Tendría que pasar un tiempo considerable “excavando” por los contenidos de Typed DataSet para averiguar todo lo que ocurra. Preferiría mejor poder ver la consulta desde la misma perspectiva que el código que liga los resultados de la consulta a la GUI. Mi costumbre habitual de pinchar con el botón derecho en un método confuso (como GetPopularTags) y elegir “Ir a definición” no me sirve aquí. ¿Por qué? Porque todo lo que hace es llevarme a la definición en el Typed DataSet, que simplemente crea más código spaghetti, crea un adaptador genérico de datos y completa basándose en parámetros. No hay información útil. Tengo que abrir el XSD para que el Typed DataSet averigüe qué es lo que realmente está pasando.


BookmarksDataSetTableAdapters.BookmarksTableAdapter bookTA =
new BookmarksDataSetTableAdapters.BookmarksTableAdapter();
BookmarkList1.DataSource =
bookTA.GetAllBookmarksWrtUser( User.Identity.Name, pageIndex,
numRows, ref totalBookmarks);
TagDataSetTableAdapters.TagsTableAdapter tagTA =
new TagDataSetTableAdapters.TagsTableAdapter();
TagList1.DataSource =
tagTA.GetPopularTags(DateTime.Now.AddDays(-30), User.Identity.Name);
recentTagsList.DataSource =
tagTA.GetRecentTags( DateTime.Now.AddDays(-30), User.Identity.Name);


Listado número 2

El código a actualizar mediante Typed DataSet es sencillo: Hacemos los cambios al objeto. El TableAdapter puede después convertir esos cambios a una ejecución SQL (SQL inline o procedimiento almacenado) y enviarlo al servidor. Los Typed DataSets son tremendamente poderosos, pero en cualquier fila de datos que tengo pensado utilizar con una cierta regularidad dentro de la empresa, quiero que haya miembros auténticos y legítimos en las clases (¡no simples envoltorios de asignación!) Quiero modelar la abstracción de capas. Quiero auténticos tipos de datos en lugar de asignaciones, y lo que es más importante, no me gusta el hecho de que la información que se extrae resulta tan difícil de encontrar. Hay que excavar muy profundamente en el XML del DataSet (que no se puede ni tan siquiera ver en la versión 2005 sin pedírselo explícitamente al editor de XML) para ver las consultas que se están ejecutando contra el servidor. Incluso después de encontrar las consultas, se encuentran en una sintaxis que es realmente difícil de leer. Toda esta infraestructura hace difícil la tarea de revisar el código, analizar las consultas e incluso inferir qué datos están fluyendo y hacia dónde.

Aquí llega LINQ-to-SQL

Tras evaluar Typed DataSets, decidí que vienen bien para demos rápidas de mecanismos de vinculación de datos, pero no tienen nada que se asemeje al conjunto de características robustas que yo quiero de una fila de acceso de datos. Mi fila de acceso de datos ha de ser extensible, flexible, elegante, eficiente y tiene que crear un código que sea fácil de leer y de mantener. Typed DataSets cumplen algunos de estos criterios, pero no todos. El código de Typed DataSet para el proyecto original (al que habíamos llamado «Moniker») fue descartado y empezamos con otro proyecto nuevo: «Moniqer.»

La siguiente evolución por encima de Typed DataSets es LINQ-to-SQL. Language Integrated Query (LINQ) es una actualización a C# que ofrece muchas y nuevas funcionalidades. Esta funcionalidad está disponible para todos, independientemente de que utilicemos LINQ o no, e incluye la capacidad de ampliar actuales clases selladas con nuestras propias clases estáticas de extensión de lenguaje. Estas extensiones de lenguaje son la base en la se construyen LINQ y LINQ-to-SQL. Trabajemos con bases de datos o con simples matrices, LINQ aumentará ostensiblemente nuestra productividad y reducirá la complejidad del código que escribimos. Las consultas LINQ están escritas en C# o en VB.NET (actualmente no hay soporte LINQ para otros lenguajes) y sigue una sintaxis que es similar a la sintaxis de XQuery FLWR (For-Let-Where-Return) y que tiene el siguiente aspecto:


var query = from (variable) in (source set)
group (group syntax)
where (criteria)
orderby (column syntax)
select (variable | projection)


El (source set) puede ser cualquier cosa desde una matriz o una colección a una clase generada por la herramienta de esquemas de línea de comandos SQLmetal.exe que representa una base de datos que encabeza un almacén de datos relacional de back-end, como SQL Server 2005. Por ejemplo, la siguiente consulta retorna el título y URL de cada uno de los registros de la base de datos, ordenado por título, proyectado a una clase anónima generada de forma dinámica:


var bookmarks = from bookmark in Database.Bookmarks
orderby bookmark.Title
select new bookmark.Title, bookmark.Url ;


La variable bookmarks no contiene realmente ningún resultado en este punto. Los resultados no son extraídos hasta que el código de algún cliente intenta atravesar los resultados invocando GetEnumerator(), que ocurre de forma automática durante un bucle foreach como este:


foreach ( var bookMark in bookmarks )

Console.WriteLine("1",
bookMark.Url, bookMark.Title);



Hay mucho más poder embotellado en LINQ y en LINQ-to-SQL y conviene que empecemos a trabajar con esta nueva tecnología lo antes que podamos. La otra potente característica de LINQ que mencioné era las extensiones de lenguaje, que nos permiten extender de forma dinámica cualquier clase con sólo añadir nuevos miembros. Echemos ahora una ojeada a la siguiente extensión de lenguaje escrita par una herramienta que consume alimentación RSS que a veces contiene elementos que estaban perdidos:


public static class LanguageExtender

public static string SafeValue(this XElement input)

return (input == null) ? string.Empty : (string)input.Value;

public static DateTime SafeDateValue(this XElement input)

return (input == null) ? DateTime.MinValue : DateTime.Parse(input.Value);




Lo que hace el código precedente es extender el XElement de clase LINQ-to-XML añadiendo dos métodos—SafeValue and SafeDateValue—para que así solo tengamos que teclear myElement.SafeValue() y automáticamente se encarga de la condición valor nulo.

Podemos incluso hacer cosas más potentes como extraer un conjunto de filas padre e iterar a continuación por ellas, extrayendo de forma dinámica las filas hijo al atravesar una clave foránea:


public static class LanguageExtender

public static string SafeValue(this XElement input)

return (input == null) ? string.Empty : (string)input.Value;

public static DateTime SafeDateValue(this XElement input)

return (input == null) ? DateTime.MinValue : DateTime.Parse(input.Value);




¡Lo que CSS Zen es capaz de hacer para contribuir a la elegancia, flexibilidad y belleza de nuestro HTML, lo puede hacer LINQ-to-SQL para nuestra capa de acceso de datos en C# ! Me gusta pensar en LINQ-to-SQL como «Datos Zen.»
LINQ-to-XML

Lo que hace LINQ-to-SQL en el mundo de la integración relacional de bases de datos, lo hace LINQ-to-XML en el mundo del acceso y la manipulación de datos XML. Con la misma sintaxis estilo LINQ que funciona con las bases de datos, podemos crear consultas potentes que analizan sintácticamente los documentos XML y extraen datos en la forma exacta que queremos – quiera que esa forma sea como clases C# generadas de forma dinámica o simplemente otro esquema XML.

LINQ-to-XML incluye un nuevo conjunto de clases relacionadas con XML tales como XDocument, XElement, and XAttribute. Lo maravilloso de estas clases es que sus constructores toman instancias de clases hijo aplicables. Ello nos permite crear elementos on-the-fly en formato de constructor anidado como este:


XElement newElement =
new XElement( "data", new XAttribute("value", "12"));


Lo que crea un elemento que tiene el siguiente aspecto:

Esta es una sintaxis más intuitiva y fácil de usar que las clases DOM actuales en la Plataforma .NET par cuando estamos encargándonos de la consulta y producción dinámicas de datos XML. En el proyecto Moniqer, hemos utilizado LINQ-to-XML par crear de forma dinámica alimentaciones RSS a partir de los resultados de las consultas LINQ-to-SQL en la misma línea de código. Cuando el código mismo se transforma en algo bello, sabemos que vamos por el buen camino. El listado número 3, por ejemplo, toma registros que se encontraban en el parámetro bookmarkList, que es de tipo IQueryable y lo envuelve en un paquete XML totalmente a media que viene en un formato legible par la inmensa mayoría de los lectores RSS.


Response.ContentType = "text/xml";
XElement rssRoot = new XElement("rss",
new XAttribute("version", "2.0"),
new XElement("channel",
new XElement("title", feedTitle),
new XElement("link", "http://(my server)/moniqer/default.aspx/"),
new XElement("description", feedDescription),
new XElement("ttl", "360"),
from bookMark in bookmarkList.Take(rowLimit)
select new XElement("item",
new XElement("title", bookMark.Bookmark.Title),
new XElement("link", bookMark.Bookmark.Address),
new XElement("pubDate", bookMark.Tags.Last().

CreatedOn.ToString()+ " GMT"),
new XElement("Creator", bookMark.Tags.Last().UserID),
new XElement("author", bookMark.Tags.Last().UserID),
new XElement("description", bookMark.Bookmark.Description),
from tag in bookMark.Tags
select new XElement("category", tag.Title)));
Response.Write(rssRoot.ToString());
Response.End();


Listado número 3

El futuro de ADO.NET

El futuro de ADO.NET está ligado a ADO.NET vNext, que utiliza LINQ par dar soporte a la Plataforma de Entidades ADO.NET —un modelo de abstracción que nos permite definir un modelo de entidad en un fichero XML. Debajo hay un fichero XML de definición de esquemas que corresponde directamente a la estructura de la tabla de nuestra base de datos. Hay también un fichero de mapeado que relaciona el Entity Model con el esquema físico. Este emparejamiento de abstracción y bucle proporciona una plataforma sorprendente que da soporte a cosas como Herencia de Entidades y Composición de Entidades (creando una sola clase/entidad de objeto C# que lee y escribe para múltiples tablas. En lo que a mi respecta, el equipo de ADO.NET ha hecho un gran trabajo con las mejores ideas que guiaban a ObjectSpaces, WinFS, y LINQ-to-SQL, puliéndolas en lo que considero es un vislumbre al futuro del acceso a datos para las aplicaciones empresariales.

El futuro de Moniqer

La versión actual de Moniqer se aloja en CodePlex (www.codeplex.com/Wiki/View .aspx?ProjectName=Moniqer). Estamos trabajando en la re-escritura de la fila de datos Moniqer en la Plataforma de Entidad para suministrar la gran riqueza de la escalabilidad, flexibilidad y rendimiento a nuestras aplicaciones empresariales. Una vez se haya completado, podremos añadir con facilidad características para cambiar esquemas, tales como soporte para mencionados grupos y ámbito de los registros, mezcla de etiquetas (controlando la etiqueta de otra persona dentro de la tuda) discusiones entorno a registros individuales, y más cosas.

Para resumir, si se siguen patrones de diseño CSS mediante la plataforma de aplicaciones web ASP.NET y se apoyan con SQL Server 2005 y LINQ-to-SQL, ello nos proporciona una base ponderosa en la que construir un registro social para la empresa y otras aplicaciones similares. Si el lector está planeando compilar una aplicación dirigida a datos con ASP.NET, le conviene echar una ojeada a LINQ-to-SQL y a ADO.NET vNext y comprobar el código fuente para Moniqer.