moure.es – Alfonso Moure Ortega

A veces queremos utilizar palabras reservadas dentro de un listado de valores de un enumerado (enum) dentro de nuestro código C#. Hoy un compañero me ha preguntado cómo hacerlo, y tras repasar mis chuletas mentales, almacenadas en memoria secundaria en lo más profundo de mis sesos, recordé la forma: poniendo el modificador @ delante del valor igual a la palabra reservada. Por ejemplo:

enum Languages {es, @as, @in, en, zh};

Ya no hay excusas: no habrá que usar strings “a pelo” en nuestras serializaciones de datos (XmlSerialization).

Bookmark

Adiós al tradicional método de convertir un string en enum utilizando un eterno switch en C#… Viejos tiempos en los que debíamos hacer algo similar a…

switch(saludo)
{

case “hola”: return Saludos.Hola;
case “hello”: return Saludos.Hello;

}

¿Quién no ha hecho este tipo de aberración alguna vez durante su vida como desarrollador? Todos…

Afortunadamente me he topado con un sistema muy interesante, que prácticamente podemos definir como evidente (¿Cómo no se me pudo ocurrir antes?) para realizar la conversión sin tener que hacer uso de un switch del tamaño de 20 folios A4. Tan sencillo como ésto:

public Enum Saludos {Hola,Hello,Hi};

public Saludos GetSaludo(string saludo)
{

return (Saludos)Enum.Parse(typeof(Saludos), saludo);

}

De éste modo realizaremos la conversión de manera sencilla y práctica, con una única línea de código.

Bookmark

Existen muchos paradigmas diferentes que pueden ser aplicados a la hora de diseñar la arquitectura de un producto software, al igual que muchas maneras de afrontarlo y subsanar sus problemas. Igualmente, hay multiples modos de enfocar las diferentes fases del desarrollo.

Personalmente tiendo a clasificar a las empresas de desarrollo en determinados grupos:

1. Desarrollo heróico :: aunque el término ya existe, usado para denominar a aquel grupo de desarrollo que intenta solucionar los problemas informáticos de manera individual y sin un planteamiento previo claro, donde el hecho de alcanzar el éxito estará marcado por la calidad de sus programadores a nivel individual y no colectivo. Este tipo de equipos suelen, por estadistica, tener una vida relativamente corta y bien sufrida, muy posiblemente por despreciar la calidad del equipo como un conjunto capaz de colaborar y trabajar como un ente único.
2. Desarrollo organizado sin calidad :: empresas donde existe una buena organización y cohesión interna pero un nivel tecnológico o formativo demasiado bajo como para sacarle un buen rendimiento. En este tipo de mercados quedarse atrás es peor que letal.
3. Desarrollo organizado de calidad :: empresas que lo tienen todo, desde buena organización hasta profesionales capaces de explotarla y sacarla partido.

Esto desde luego es únicamente referente a su capacidad de organizarse y aprovechar sus recursos humanos. Pero, ¿qué hay de las empresas que no aprovechan en absoluto sus virtudes técnicas? ¿Qué sucede con las empresas que alardean de utilizar .NET Framework pero no aprovechan ninguna de sus capacidades únicas?

Bookmark

O más conocidos como Annonymous Methods. Los programadores de la vieja escuela siempre habráno notado la ausencia de esta opción, añadida en la versión 2.0 de C# y no demasiado conocida por los desarrolladores que aun no han cambiado totalmente el chip desde la versión 1.1 de .NET Framework (desgraciadamente, demasiados hoy en día).

¿Qué es un método anónimo? A veces hay situaciones donde debemos utilizar determinados pedazos de código que no vamos a usar más adelante en nuestro programa a modo de método o función, por lo que no es necesario realizar un esfuerzo extra para refactorizar nuestro código o crear zonas reutilizables. Una clara situación: el envío de un método delegado como parámetro para una función.

Tradicionalmente, para poder pasar un método como parámetro, debíamos primero definir un tipo de delegado, crear dicho método, y enviarlo como parámetro:

public delegate void MiDelegado(int x);

/* … */

public bool ProbarMetodo(MiDelegado metodo) { int i = 5; /* … */ return metodo(i); }

void MiFuncion(int x) { return x*2; }

/* ..  */

//Llamamos al método pasando como parámetro un delegado
this.ProbarMetodo(this.MiFuncion);

Vamos… un completo engorro. Es entonces cuando entran en juego nuestros amigos los métodos anónimos, donde en lugar de crear un tipo de delegado e ir pasandolo engorrosamente, introducimos la implementación del método directamente en la llamada:

this.ProbarMetodo(delegate (int x) { return x*2; });

Como veis, esto nos facilita mucho la existencia: es algo más complicado de leer y comprender (pese a que este ejemplo es bien sencillo) pero ganamos a la hora de simplificar la estructura de métodos de nuestra clase. Todo un logro de los creadores de C# 2.0, y un gran punto donde C# 3.0 tiene uno de sus pilares de soporte centrales para la creación de la API de LINQ y su nueva sintaxis, y muy útil para las nuevas funciones lambda que nos alegran la vida con la nueva versión del lenguaje.

Bookmark

La API de YouTube, al igual que muchas otras de Google, está basada en RSS y por tanto en XML, pudiendo así equipararlo con un servicio web pese a no existir una llamada RPC (para aquellos conservadores que aun consideran los web services como ejecuciones a distancia XML-RPC y no peticiones de datos XML como puede explicarse hoy en día utilizando algunas de las referencias más importantes de Internet).

Por lo tanto, para cualquier uso que queramos realizar de las API de YouTube para tomar datos de videos, usuarios y temáticas, podremos hacer uso de la gran colección de herramientas y clases del framework de Microsoft para comunicarnos con la aplicación de Google.

Como siempre, cada uno tiene su sistema, y yo tengo el mio propio. Como ya sabreis, soy una persona muy purista y tengo por tendencia utilizar sistemas del más bajo nivel siempre que está en mi mano, por lo que no es dificil intuir la manera en que consumo y exploto las API de Google basadas en XML.

Para empezar, comienzo por descargarme el mensaje XML desde su origen. Tomemos como ejemplo la petición de datos de un video concreto:

using System.Net;

/* ############ */

string url = “http://gdata.youtube.com/feeds/api/videos/[codigo youtube del video]“;
WebClient wc = new WebClient();
string xml_file_stream = wc.DownloadString(url);

XmlDocument xdoc = new XmlDocument();
xdoc.LoadXml(xml_file_stream);

De este modo descargamos el fichero XML que contiene la información referente al video del que queremos recuperar sus datos y lo cargamos en un objeto de tipo XmlDocument, estructura que podremos manipular a nuestro libre antojo.

En otro post, analizaré y mostraré los diferentes campos de la secuencia devuelta como XML y la utilidad que podemos sacarle para neustras aplicaciones tanto en ASP.NET como Windows Forms.

Personalmente, lo veo muy interesante para realizar integraciones de contenidos entre diferentes temas, usuarios o localizaciones geográficas, que podremos facilmente compartir en nuestras aplicaciones y dar servicios extra a neustros clientes y usuarios finales.

Pero, como siempre, el uso final estará en manos de todos nosotros: los desarrolladores, programadores y diseñadores software.

Bookmark

Existen muchas maneras de gestionar el acceso a bases de datos desde ASP.NET, unos mejores que otros, y sin duda cada uno tenemos nuestro propio sistema (“Cada maestrillo tiene su librillo“, como siempre me han dicho en mi casa). ¿Cuál creeis que puede ser el mejor?

Por supuesto a la hora de elegir el sistema más apropiado tendremos que tener en cuenta toda una serie de factores, ventajas y desventajas, de cada uno de los diferentes modos existentes:

1. Gestión centralizada :: las conexiones a la base de datos son administradas en una clase común accesible desde cualquier punto de la aplicación (ahorro de recursos a la hora de abrir y cerrar conexiones y realizar consultas ligeras o atómicas.
2. Gestión individual :: abrir y cerrar la conexión cada vez que sea necesario lanzar comandos hacia la base de datos.

Desde un punto de vista organizativo, no hay duda que la centralización es la mejor opción: atomización del control de base de datos, administración localizada en un punto de todo el tráfico de datos, y disminución de la complejidad del código. Ahora bien, el diseño de un sistema que permita este tipo de trabajo, aunque no imposible, es relativamente complicado: debemos tener en cuenta que toda aplicación web, al menos en la mayor parte de los casos, deberá soportar un cierto grado de concurrencia de usuarios de manera simultánea, por lo que podemos descartar el uso de variables static (o shared en VisualBasic), ya que estas son compartidas en todas las instancias de la aplicación web en ejecución.

Analicemos la posible solución como conexión común en una variable static:

class ClaseComun { private static SqlConnection __connection; }

Vemos que definimos una clase que contiene la variable privada estática que almacena una conexión de tipo SqlConnection (proveedor de conexión para SQL Server integrado en Microsoft .NET). Vamos a añadir una propiedad a la clase:

public static SqlConnection Connection
{

get { if (__connection == null) { __connection = new SqlConnection(connection_string); __connection.Open(); }

}

Como podemos apreciar, la propiedad creada es de solo lectura: queremos que la conexión quede solo definida por el interior de nuestra clase, aislandola del resto de la aplicación.

Por el momento, todo parece correcto, especialmente para aquellos que estén familiarizados con aplicaciones basadas en Windows Forms, donde este tipo de trabajo es oportuno y francamente útil.

El problema viene cuando lo utilizamos en una aplicación ASP.NET: imaginemos un usuario que entra por primera vez en la página. Al realizar su petición al servidor, ésta será ejecutada, y de no existir una instancia para la variable estática, se creará un objeto SqlConnection y se abrirá la conexión con la base de datos SQL Server.

Ahora bien… Otro usuario, casi de manera simultánea pero unos microsegundos después, solicita al servidor otro acceso. El código ASP.NET, volverá a comprobar la existencia de la variable de conexión, que ya estará instanciada y por tanto no realizará ninguna otra gestión sobre la conexión. Ahora bien… el código ejecutará sus consecuentes peticiones de datos y… ¡peligro! Dos usuarios están usando la misma conexión con la base de datos.

Pese a ser un modo bastante elegante de centralizar la gestión de conexiones, es mortalmente peligroso para aplicaciones web concurrentes. Por lo tanto, pasaremos a la siguiente opción.

Aunque pueda parecer una opción menos eficiente frente a la anterior, la mejor opción bajo mi punto de vista es crear una instancia de la conexión SqlConnection para cada consulta que vayamos a realizar, la abramos, ejecutemos la petición a la base de datos, y luego la cerremos:

SqlConnection cnx = new SqlConnection(connection_string);
cnx.Open();
SqlCommand cmd = new SqlCommand(“SELECT COUNT(*) FROM table_of_clients”, cnx);
object obj = cmd.ExecuteScalar();
/* … */
cnx.Close();

Como vemos, estamos creando una instancia de la conexión para realizar una consulta por lo demás simple, que se abre y se cierra para lanzar la petición a la base de datos. Puede parecer redundante y una pérdida letal de recursos, con una inclusión indiscriminada de líneas extra en el código fuente de nuestra aplicación.

Pero, en el caso de una aplicación web de cierta complejidad donde deban lanzarse varias consultas en una misma petición del usuario al servidor web, ¿es una buena práctica abrir y cerrar la conexión tantas veces? ¿es eficiente?

La respuesta es si. Gracias a las capacidades de connection pooling de ASP.NET y SQL Server ganaremos en eficacia y calidad sin perder recursos por el camino. ¿En qué consiste el connection pooling? Lo explicaré en el próximo post de mi blog, donde podreis comprobar su funcionamiento con algunos ejemplos sencillos que espero os sean de utilidad.

Una cosa os aseguro: ganareis, de lejos, numerosas ventajas frente a otros métodos tradicionales de trabajo.

Bookmark