Alfonso Moure Ortega - SEO Team Leader Relevant Traffic Span - Consultor SEO
Moure Profesional

Archivo

Entradas Etiquetadas ‘asp.net’

Pasando variables entre callbacks en ASP.NET: ViewState

Lunes, 25 de agosto de 2008 1 comentario

Desde pasar variables en campos ocultos (hidden fields) hasta guardarlas como variables de sesión, pasando por enviar QueryStrings absurdamente largos. Estas son algunas de las salidas que muchos programadores utilizan para poder pasarse información entre diferentes callbacks en ASP.NET, para conservar valores de variables o datos de los usuarios. ¿Os imagináis guardar datos personales de los usuarios en campos ocultos HTML? Aberrante.

Algunas personas utilizarán otros métodos, pero yo os voy a sugerir mi preferido y el que más uso normalmente. Es recomendable no usarlo en situaciones donde la seguridad sea extremadamente importante, pese a que decodificar la cadena del ViewState en el resultado renderizado de la página sea un acto casi faraónico.

Mi propuesta es la siguiente: muchos queremos poder mantener el estado y contenido de nuestras variables entre un callback y el siguiente, de manera sencilla y cómoda. Para ello vamos a usar el ViewState.

Para los profanos: ¿qué es el ViewState?

Cuando uno programa en ASP.NET, comunmente utiliza eventos para controlar la interacción de los usuarios clientes en la página. Estos eventos nos permiten detectar, por ejemplo, cuándo un usuario selecciona una opción de un desplegable DropDownList. Cuando el cliente hace ésto, por arte de magia el código de lado de servidor recibe un mensaje que lanza un método señalado como capturador del evento. Por ejemplo:

Código ASP.NET:

<asp:DropDownList runat=”server” ID=”dropdownPrueba” OnSelectedIndexChanged=”procesarCambio”>
<asp:ListItem Text=”Opción 1″ Value=”1″></asp:ListItem>
<asp:ListItem Text=”Opción 2″ Value=”1″></asp:ListItem>
</asp:DropDownList>

Código C#

protected void procesarCambio(object sender, EventArgs e)
{
Response.Write(this.dropdownPrueba.SelectedItem.Text);
}

Fijaros bien en algo. En la función C# anterior, estoy recogiendo el texto contenido en el item seleccionado en el desplegable. ¿Cómo sabe ASP.NET lo que está seleccionado? ¿Cómo sabe los items que había antes en el desplegable? La pregunta tiene fácil respuesta: el ViewState.

El ViewState es el modo en que ASP.NET guarda el estado general de una aplicación web dentro del ámbito de una misma página y sus consecuentes callbacks. Automáticamente, guarda el estado de todas las variables de los controles de usuario ASP.NET (siempre y cuando tengamos activada la opción EnableViewState en el control), de manera que se conservan y son accesibles en cada callback de la página.

Pero, ¿cómo puede esto servirnos para guardar datos entre una llamada a servidor y otra? Los chicos de Redmon nos han dejado una pequeña puerta trasera para acceder al ViewState e introducir y recuperar información.

Su uso es bien sencillo: podemos acceder al ViewState como una variable estática global, de la siguiente manera y desde cualquier punto de nuestro proyecto web:

Código C#

//Introducimos un dato en el ViewState…

ViewState["midato"] = “vamos a guardar esto en el ViewState de la página”;

//y ahora lo recuperamos

string este_era_el_dato = ViewState["midato"];

Por supuesto, podéis probar esto y añadir cada línea en callbacks diferentes para poder comprobar su correcto funcionamiento.

Mi sugerencia

Cada desarrollador tiene sus propias manías, y yo no soy una excepción. Por ello, conservo determinados valores entre diferentes llamadas del servidor cuando es necesario y apropiado. Aquí os dejo un ejemplo:

private string __variable;

public string Variable
{
get { if (ViewState["variable"] != null) return ViewState["variable"].ToString(); else return this.__variable; }
set { ViewState["variable"] = value; this.__variable = value; }
}

De esta manera, si haceis uso de la propiedad llamada Variable en cualquier punto de la clase, ésta se conservará entre callbacks. Recordad que, aunque la propiedad Variable, aunque la haya definido como pública, podeis usarla como prefiráis (private, protected…). No useis la variable __variable, pues será sobreescrita por la propiedad cada vez que la llaméis, no es más que un punto de control.

Como nota personal, siempre tiendo a encerrar este tipo de composiciones en una misma región, quedando mucho más organizado y ordenado.

Connection pooling ASP.NET 2.0

Sábado, 21 de junio de 2008 1 comentario

En mi post anterior dedicado a las conexiones a base de datos desde ASP.NET comenté algunos de los problemas más comunes durante el diseño de arquitecturas software en ASP.NET y la gestión de conexiones con bases de datos, especialmente con Microsoft SQL Server.

Vimos que la solución final necesaria para poder utilizar conexiones en ASP.NET sin meternos en lios de memoria o conexiones compartidas, debíamos abrir y cerrar la conexión con la base de datos para cada consulta, pese a que pudiera parecer redundante o molesto.

Pero, si aplicais lo planteado en un proyecto a gran escala y con un buen tráfico de usuarios, notareis que no se sufre un impácto demasiado grande en el rendimiento de la aplicación pese a utilizar esta técnica, y esto se debe a una gran capacidad con la que cuenta SQL Server: el connection pooling: cuando llamamos a Close() para cerrar la conexión a la base de datos, ésta no se cierra, sino que queda almacenada en un listado de conexiones inactivas a las que puede recurrirse en cualquier momento.

Más adelante en nuestra misma aplicación, cuando llamemos a Open() para volver a conectarnos, ASP.NET y SQL Server colaborarán para localizar una conexión marcada como inactiva pero cuyo connection string coincida con la conexión que intentamos crear y activar. En el momento en que es localizada, esta es invocada y reactivada, evidanto de esta manera un malgasto de recursos extra al crear y abrir una conexión.

Una cosa debe quedarnos bien clara en cualquier caso: cualquier tipo de movimiento o trabajo con la base de datos, apertura o cierre de conexión con un proveedor, petición o inserción de datos, consume recursos temporales y de memoria del sistema, por lo que es de vital importancia el localizar nuevas vias de trabajo con datos y mejoras  en sus algoritmos como puntos clave para potenciar la eficiencia de nuestras aplicaciones.

Conexiones a base de datos en ASP.NET 2.0

Miércoles, 18 de junio de 2008 2 comentarios

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.

Gestión de errores en ASP.NET 2.0

Lunes, 16 de junio de 2008 5 comentarios

Uno de los grandes retos a la hora de abordar el desarrollo de una aplicación software es la gestión de los errores que puedan producirse durante su explotación o incluso durante la fase de desarrollo.

Podemos diferenciar varios tipos de errores:

  1. Errores sintácticos de programación. Estos son detectados por el compilador como situaciones que violan las reglas de implementación del lenguaje que estemos utilizando.
  2. Errores conceptuales de programación. Errores cometidos en la definición de algoritmos que llevan a situaciones no previstas.
  3. Errores en tiempo de ejecución. Derivados de los errores conceptuales, son los que nacen de resultados no previstos.
  4. Errores de planificación. Suceden cuando se pone poco empeño durante la fase de análisis y definición de un proyecto, y es especialmente visible en proyectos web, donde (generalmente) el número de archivos de código es mayor que en una aplicación de escritorio y son más dificiles de depurar.

Por suerte, hoy en día cualquier lenguaje que utilicemos cuenta con las herramientas necesarias para poder detectar los errores de los puntos 1, 2 y 3.

El más clásico es, por supuesto, la estructura try. Un ejemplo en C#:

try
{ /* Código que está siendo probado */ }
catch (Exception ex)
{ /* Código ejecutado si se produce una excepción */ }

Ahora bien, cuando estamos trabajando en una aplicación web con ASP.NET 2.0, puede que queramos realizar una gestión de errores a nivel de aplicación sin necesidad de tener que controlar cada zona del código mediante estructuras de control de excepciones.

Aquí voy a presentar el modo que yo prefiero utilizar, y que bajo mi experiencia, es el más cómodo y útil.

Para capturar los errores que se produzcan dentro de nuestr apalicación, utilizaremos el fichero Global.asax, que si no lo teneis en vuestro proyecto, podeis añadirlo en el propio directorio raíz. En él, si no lo tenemos ya, añadiremos una función de la siguiente forma:

void Application_Error(object sender, EventArgs e)   { }

Cada vez que se produce una excepción no controlada dentro de nuestra aplicación web se llama a este evento de manera automática. Hay que tener en cuenta que si bien de esta manera capturamos el momento en que se produce un error, no tenemos una manera directa de acceder a la información del mismo, por lo que usaremos esta otra secuencia para recoger el objeto de excepción:

Exception ex = Server.GetLastError().GetBaseException();

Como podeis ver, ahora ya podemos acceder a toda la información que nos trae el objeto de excepción en su instancia, que hemos llamado ex.

Ahora podemos tomar varios caminos:

  1. Mostrar un mensaje de error al usuario.
    1. Genérico: configurable desde el fichero web.config, como veremos a continuación.
    2. Detallado con el error: no es recomendable, pero podemos imprimir en pantalla los datos del error (procedencia, mensaje, seguimiento de pila de llamadas…)
  2. Registrar el error en Windows.
  3. Enviar un correo electrónico al administrador.

Primero veamos el caso 1. Para poder activar una página genérica donde acudan los navegadores de nuestros usuarios cuando se produzca un error, modificaremos una serie de parámetros en el fichero web.config, en concreto los referentes a la etiqueta customErrors:

<customErrors mode=”RemoteOnly” defaultRedirect=”~/pagina-no-encontrada.aspx”>
<error statusCode=”404″ redirect=”~/pagina-no-encontrada.aspx”/>
<error statusCode=”500″ redirect=”~/error.aspx”/>
</customErrors>

El este pequeño ejemplo, estamos indicando al servidor IIS el modo en que debe atender las diferentes situaciones que puedan darse, concretamente para dos casos muy comunes: no localizar una dirección (código 404) o detectar un error en tiempo de ejecución (código 500).

  • customErrors: permite configurar el modo en que se atiende un error.
    • mode: modo en que debe comportarse el servidor de cara al error a la hora de mostrarlo
      • on: mostrar una página de error genérica (o la indicada como por defecto para el error sucedido)
      • off: mostrar cascada de error completa (PELIGRO DE SEGURIDAD, usar solo durante depuración y desarrollo), donde veremos una descripción detallada de lo sucedido
      • RemoteOnly: mostrará una página de error genérica (o la indicada)
    • defaultRedirect: lugar al que será enviado el usuario si no se indica nada para el suceso acontecido
  • error: condición para un error concreto
    • statuCode: código del error acontecido (po ejemplo… 200=OK; 301=movido; 404=no encontrado; 500=error de ejecución)
    • redirect: página donde deberá ser llevado el usuario cuando suceda ese tipo de error

Ahora bien, si lo que queremos es poder realizar un tratamiento propio del error desde el fichero global, debemos tener en cuenta que lo anteriormente explicado, es decir, las instrucciones insertadas en el fichero de configuración web.config, se ejecutarán inmediatamente después de lo indicado en la función Application_Error salvo que le indiquemos lo contrario con la llamada a Server.ClearError(); , que retirará el error de la aplicación e ignorará lo aparecido en el fichero de configuración.

Tratemos ahora los otros dos casos: registro en Windows y envío por email.

Para registrar una excepción en el registro de Windows, podemos usar: (comprobando antes de nada que hayamos añadido al fichero System.Diagnostics)

EventLog.WriteEntry(“Test Web”,
“MESSAGE: ” + ex.Message +
“\nSOURCE: ” + ex.Source +
“\nFORM: ” + Request.Form.ToString() +
“\nQUERYSTRING: ” + Request.QueryString.ToString() +
“\nTARGETSITE: ” + ex.TargetSite +
“\nSTACKTRACE: ” + ex.StackTrace,
EventLogEntryType.Error);

Pero una cosa nos debe quedar muy clara: tras usar esto, la función en la que estamos será anulada instantáneamente, por lo que si queremos realizar cualquier otro tipo de atención a la excepción en la función Application_Error deberemos de hacerlo antes de llamar a EventLog.WriteEntry.

Si lo que deseamos es enviarnos el error por email, cosa que yo personalmente encuentro soberanamente útil, podremos usar: (haciendo uso de System.Net y System.Net.Mail)

string origen = “direccion@origen-de-aplicacion.com”;
string destino = “correo@electronicodedestino.com”;
string titulo = “Error de ejecución”;

string cuerpo = “<h2>Informe de error</h2>Fecha-hora: ” + DateTime.Now.ToString(“dd/MM/yyyy – HH:mm:ss”);

cuerpo += “<h3>Mensaje</h3>” + ex.Message + “<h3>StackTrace:</h3>” + ex.StackTrace + “<h3>TargetSite:</h3>” + ex.TargetSite;

MailMessage mensaje = new MailMessage(origen, destino, titulo, cuerpo);
mensaje.IsBodyHtml = true;   //Si hemos añadido etiquetas HTML
SmtpClient smtp = new SmtpClient(“mismtp.midireccion.com”);
smtp.Timeout = 6000;
smtp.Send(mensaje);

Si teneis alguna duda o pega, no dudeis en comunicarmelo. Intentaré extender más este tipo de minitutoriales de ASP.NET y C#.

Alfonso Moure Ortega ghostmou http://www.moure.es Muchoviaje Madrid SEO Head Manager Grupo Muchoviaje - SEO, GEO, SMO, .NET developer
Alfonso Moure Ortega