jueves, 29 de abril de 2010

Codificación del Ticket de Autenticación en la Dirección URL

Las cookies son un medio natural para la inclusión de información sobre el navegador en cada solicitud a un sitio web concreto, por lo que la configuración de autenticación por defecto forms utilizar cookies cuando el dispositivo visitando las admite. Si las cookies no son compatibles, debemos usar una alternativa para pasar el Ticket de autenticación desde el cliente al servidor. Una solución común usada en ambientes sin cookies es codificar los datos de la cookie en la URL.

La mejor manera de ver cómo esa información puede ser embebido dentro de la URL y forzar el sitio para que utilice la autenticación sin cookies. Esto se puede lograr mediante el establecimiento de la configuración de cookieless configurado a UseUri, ejemplo:

<authentication mode="Forms">
      <forms
          cookieless="UseUri"
          slidingExpiration="true"
          timeout="60"/>
    </authentication>

Una vez realizado este cambio, cuando visitemos el sitio a través del navegador como usuario anónimo, por ejemplo la dirección URL de la página Default.aspx la barra de direcciones mostrará:

http://localhost/misitio/default.aspx

Sin embargo, al iniciar la sesión, el ticket de autenticación de formularios está incrustado en la URL. Por ejemplo, después de visitar la página de entrada e iniciar de sesión como un usuario valido, la dirección en esta ocasión es:

http://localhost/misitio/(F(jaIOIDTJxIr12xYS-VVgkqKCVAuIoW30Bu0diWi6flQC-FyMaLXJfow_Vd9GZkB2Cv-rfezq0gKadKX0YPZCkA2))/default.aspx

Entonces lo que tenemos aquí es que ahora el ticket de autenticación de formularios se ha incrustado en la URL. La cadena (F(jaIOIDTJxIr12xYS-VVgkqKCVAuIoW30Bu0diWi6flQC-FyMaLXJfow_Vd9GZkB2Cv-rfezq0gKadKX0YPZCkA2) representa la información de autenticación de codificado hexadecimal del ticket. Estos son los mismos datos que normalmente se almacenan en una cookie.

Saludos, Toby

martes, 20 de abril de 2010

Programación Orientada a Objetos (POO)

¿Qué es la Programación Orientada a Objetos?

La Programación Orientada a Objetos, POO (OOP, Object Oriented Programming, en ingles), es una técnica de programación cuyo soporte fundamental es el objeto. Un objeto es una extensión de un Tipo Abstracto de Datos (TAD). Un TAD es un tipo definido por el usuario, que encapsula un conjunto de datos y las operaciones sobre estos datos.

A la hora de definir TAD’s (u objetos) se usa un concepto que nos ayuda a representar la realidad mediante modelos informáticos, la abstracción, que es un proceso mental por el que se evitan los detalles para centrarse en las cosas más genéricas de manera que se facilite su comprensión. La diferencia entre el concepto de TAD y el de objeto radica en que además del proceso de abstracción que se utiliza para su definición, existen otros dos con los que se forma el núcleo principal de la programación orientada a objetos, estos son la herencia y el polimorfismo.

Entonces tenemos que:

1.- La programación orientada a objetos, utiliza objetos, no algorítmicos, como bloques de construcción lógicos (jerarquía de objetos).


2.- Cada objeto es una instancia de una clase.


3.- Las clases se relacionan unas con otras por medio de relaciones de herencia.

Un programa puede parecer orientado a objetos, pero si cualquiera de estos elementos no existe, no es un programa orientado a objetos.


Ventajas de la orientación a objetos

Las ventajas más importantes de la programación orientada a objetos son las siguientes:

• Mantenibilidad (facilidad de mantenimiento). Los programas que se diseñan utilizando el concepto de orientación a objetos son más fáciles de leer y comprender y el control de la complejidad del programa se consigue gracias a la ocultación de la información que permite dejar visibles sólo los detalles más relevantes.

• Modificabilidad (facilidad para modificar los programas). Se pueden realizar añadidos o supresiones a programas simplemente añadiendo, suprimiendo o modificando objetos.

• Resusabilidad. Los objetos, si han sido correctamente diseñados, se pueden usar numerosas veces y en distintos proyectos.

• Fiabilidad. Los programas orientados a objetos suelen ser más fiables ya que se basan en el uso de objetos ya definidos que están ampliamente testados.


Conceptos básicos de la orientación a objeto


Como ya hemos dicho la orientación a objetos se basa en conceptos como clase, objeto, herencia y polimorfismo, pero también en otros muchos.

• Clase: Es una descripción de un conjunto de objetos similares. Por ejemplo la clase Coches. Una clase contiene los atributos y las operaciones sobre esos atributos que hacen que una clase tenga la entidad que se desea.

• Objeto: Un objeto es una cosa, generalmente extraída del vocabulario del espacio del problema o del espacio de la solución. Todo objeto tiene un nombre (se le puede identificar), un estado (generalmente hay algunos datos asociados a él) y un comportamiento (se le pueden hacer cosas a objeto y él puede hacer cosas a otros objetos). Un objeto de la clase Coches puede ser un Ford Mustang.

• Atributo: Es una característica concreta de una clase. Por ejemplo atributos de la clase Coches pueden ser el Color, el Numero de Puertas.

• Método: Es una operación concreta de una determinada clase. Por ejemplo de la clase Coches podríamos tener un método arrancar() que lo que hace es poner en marcha el coche.

• Instancia: Es una manifestación concreta de una clase (un objeto con valores concretos). También se le suele llamar ocurrencia. Por ejemplo una instancia de la clase Coches puede ser: Un Ford Mustang, de color Gris con 3 puertas.

• Herencia: Es un mecanismo mediante el cual se puede crear una nueva clase partiendo de una existente, se dice entonces que la nueva clase hereda las características de la case existentes aunque se le puede añadir más capacidades (añadiendo datos o capacidades) o modificar las que tiene.

• Polimorfismo: Hace referencia a la posibilidad de que dos métodos implementen distintas acciones, aun teniendo el mismo nombre, dependiendo del objeto que lo ejecuta o de los parámetros que recibe.

viernes, 9 de abril de 2010

Solucion error AjaxControlToolkit - La colección de controles no puede modificarse porque el control contiene bloques de...

Ajax Control Toolkit en ASP.NET Ajax Library


Detalles de la Versión :(AspNetAjaxLibraryBeta0911.zip application, 6490K, uploaded Nov 18 2009 - 147484 downloads)

Al trabajar con esta versión de AJAX en “Visual Studio 2008 con Framework 3.5 SP1” , me arrojo el siguiente error:

“La colección de controles no puede modificarse porque el control contiene bloques de código (por ej. ).”

Las causas puede ser varias pero en mi caso solo era mover el bloque de código JavaScript fuera de la etiqueta "Head" del mi MasterPage. La MasterPage era usada por una pagina que contenía controles AJAX y un control de usuario que también tenía controles AJAX.

Dejo aquí la solución por si le pasa a alguien más. Solo era cambiar esto de la MasterPage:

<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
    <title>Prueba</title>
    <asp:ContentPlaceHolder id="head" runat="server">
    </asp:ContentPlaceHolder>
    <link rel="stylesheet" href="style.css" type="text/css" media="screen" />
    <script type="text/javascript" src=<%= ResolveUrl("JScript1.js") %>>
    </script>
</head>
<body>
...
</body>
</html>
Por esto otro:
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
    <title>Prueba</title>
    <asp:ContentPlaceHolder id="head" runat="server">
    </asp:ContentPlaceHolder>
    <link rel="stylesheet" href="style.css" type="text/css" media="screen" />
</head>
<body>
    <script type="text/javascript" src=<%= ResolveUrl("JScript1.js") %>>
    </script>
...
</body>
</html>

Si tienen otra solución me avisan.

Saludos
Toby

miércoles, 7 de abril de 2010

Solucion error AjaxControlToolkit requires ASP.NET Ajax 4.0 scripts

Ajax Control Toolkit en ASP.NET Ajax Library


Detalles de la Versión :(AspNetAjaxLibraryBeta0911.zip application, 6490K, uploaded Nov 18 2009 - 147484 downloads)

Al trabajar con esta versión de AJAX en “Visual Studio 2008 con Framework 3.5 SP1” , me arrojo el siguiente error:

“Microsoft JScript runtime error: AjaxControlToolkit requires ASP.NET Ajax 4.0 scripts. Ensure the correct version of the scripts are referenced. If you are using an ASP.NET ScriptManager, switch to the AjaxScriptManager in System.Web.Ajax.dll, or use the ToolkitScriptManager in AjaxControlToolkit.dll.”

Dejo aquí la solución por si le pasa a alguien más. Solo es cambiar esto:
<asp:ScriptManager ID="ScriptManager1" runat="server"/>
<asp:ScriptManager/>
Por esto otro:
<asp:ToolkitScriptManager ID="ScriptManager1" runat="server"/>
<asp:ToolkitScriptManager/>

Si tienen otra solución me avisan.

Saludos
Toby

domingo, 21 de febrero de 2010

Asignación implícita de tipos en Visual C#

En ocasiones nos podemos ver enfrentados a la problemática de no saber de qué tipo debemos declarar una variable, parece raro, pero no lo es y te diré porque. Primero revisemos el siguiente código:

protected void Button1_Click(object sender, EventArgs e)
        {
            Int32 departmentID = Convert.ToInt32(departmentList.SelectedValue);

            var courseInfo = from c in schoolContext.Course
                             where c.Department.DepartmentID == departmentID
                             select new
                             {
                                 CourseID = c.CourseID,
                                 CourseTitle = c.Title,
                                 CourseCredits = c.Credits
                             };
            
            foreach (var course in courseInfo)
            {
                Response.Write("<br>ID: " + course.CourseID + "<br>Title:" + course.CourseTitle + "<br>Credits:" + course.CourseCredits);
            }
        }

El resultado de courseInfo es una colección de tipos anónimos y solamente el compilador puede tener acceso al nombre de ese tipo y es aquí entonces en donde usaremos var y lógicamente la variable course en foreach también debe tener tipo implícito.

Ahora si revisamos este segundo ejemplo, inmediatamente podemos deducir que el tipo de la variable courseInfo para su resultado es IEnumerable, pero si usamos var también estará bien. La variable course en foreach también la definimos como string.

protected void Button2_Click(object sender, EventArgs e)
        {
            string[] Courses = { "Ingenieria", "Ingles", "Economia", "Matematicas" };
            IEnumerable<string> courseInfo = from name in Courses
                              where name[0] == 'I'
                              select name;

            foreach (string course in courseInfo)
            {
                Response.Write("<br>Course :" + course);
            }
        }

Entonces en resumen, a las variables locales se les puede asignar un "tipo" deducido var en lugar de un tipo explícito. La palabra clave var indica al compilador que deduzca el tipo de la variable a partir de la expresión que se encuentra en el lado derecho de la instrucción de inicialización. El tipo deducido puede ser un tipo integrado, un tipo anónimo, un tipo definido por el usuario o un tipo definido en la biblioteca de clases de .NET Framework.

Saludos, Toby

viernes, 19 de febrero de 2010

Como usar ViewState en ASP.NET con C#

El ViewState nos permite almacenar información de estado (la información se serializa en XML y luego se codifican en Base64) directamente en las páginas Web ASP.NET entre devoluciones de datos o Post Back. El PostBack es un reenvío de los datos del formulario de vuelta al servidor, el cual puede ser provocado por la acción de un evento click de un botón o el cambio de selección de un combobox, etc. Cuando se procesa la página, se codifica el estado actual de la página y de los controles, y la cadena que se obtiene se guarda en la página en forma de campo oculto, por lo tanto se pueden realizar cambios en el estado hasta el evento PreRenderComplete. Cuando la página se represente en el explorador, no se guardarán los cambios en el ViewState.

El ViewState proporciona información de estado para una página específica ASP.NET. Si se necesita utilizar esa información en más de una página o si se desea que la información permanezca para todas las visitas al sitio Web, se debe utilizar otro método para mantener el estado, como por ejemplo, estado de aplicación, estado de sesión o personalización.

Ya sabemos que el ViewState nos permite almacenar información, pero ¿qué tipo de información se puede almacenar?

Se puede almacenar objetos de tipo Cadenas, Enteros, Booleanos, Array, ArrayList, Tablas Hash, Convertidores de tipos personalizados y además puede almacenar otros tipos de datos en donde la clase debe compilarse con el atributo Serializable para que el ViewState pueda serializarlos en formato XML.

Como ya indiqué antes, la información del ViewState se serializa en XML y luego se codifica en Base64, lo cual en ocasiones nos puede generar grandes cantidades de información que puede afectar al rendimiento de la página y nos puede generar problemas con algunos proxy y firewall, por lo tanto, es recomendable probar el rendimiento de las páginas y si es necesario también deshabilitar el ViewState para los controles de datos como el GridView, DataList, Repeater, etc que pueden generar campos ocultos de gran tamaño.

Si se nos presentará el problema de mucha cantidad de datos almacenados en la propiedad ViewState y excede el valor especificado en la propiedad de la página MaxPageStateFieldLength, la página divide el ViewState en varios campos ocultos para reducir el tamaño de cada campo y evitando así ser rechazados por el firewall.

Ahora, otra solución a este problema es tratar de minimizar este traslado de información entre cliente y servidor no persistiendo el ViewState en un campo oculto de la página, sino que en otro lugar como por ejemplo en la memoria del servidor (siempre y cuando tengamos buenos servidores y se nos permita hacerlo) y para eso tenemos el SessionPageStatePersister. Para ello lo único que hay que hacer es sobreescribir la propiedad PageStatePesister de la página de modo que devuelva una referencia a un objeto de la clase que acabamos de mencionar, y eso se hace de la siguiente manera:

protected override PageStatePersister PageStatePersister
{
   get
   {
       return new SessionPageStatePersister(this);
   }
}

Si miras el código fuente de la página, notaras que la cantidad de información a disminuido considerablemente.

También podemos comprimir (System.IO.Compression) la información de los campos ocultos, pero eso es un tema que hay que tratar más en detalle en otra oportunidad, por mientras basta con que sepas que se puede hacer.

Entonces, en resumen tenemos que ViewState nos brinda las siguientes ventajas:

  • No se requieren recursos del servidor: Está incluido en una estructura dentro del código de la página.
  • Implementación sencilla: No requiere que se utilice una programación personalizada. Se habilita de forma predeterminada para mantener los datos de estado en los controles.
  • Características de seguridad mejorada: Los valores están fragmentados, comprimidos y codificados para implementaciones de Unicode, por lo que son más seguros que los campos ocultos.

Y las desventajas de utilizar el ViewState son:

  • Consideraciones sobre el rendimiento: Dado que el ViewState se almacena en la propia página, el almacenamiento de valores de gran tamaño puede hacer que la página se muestre y se envíe de forma más lenta para los usuarios. Esto es especialmente relevante para los dispositivos móviles, donde el ancho de banda constituye a menudo una limitación.
  • Limitaciones de dispositivos: Los dispositivos móviles pueden carecer de una capacidad de memoria suficiente para almacenar una gran cantidad de datos.
  • Posibles riesgos de seguridad: El ViewState se almacena en uno o varios campos ocultos de la página. Aunque se almacenan los datos fragmentados, se pueden ver y manipular si se obtiene acceso al código fuente de la página.

Como ya se señaló anteriormente, la información de un campo oculto de ViewState puede ser vista si se obtiene acceso al código fuente de la página, lo que nos puede generar un problema de seguridad si los datos son de cierta importancia, así que para aminorar este problema, se puede cifrar el ViewState cambiando el atributo viewStateEncryptionMode en la directiva @ Page al valor “Always”.

Creo que ya es suficiente con esta información, ahora pasemos a algo práctico. Lo primero que debemos saber es que para utilizar la propiedad ViewState, es que la página Web ASP.NET debe tener un elemento de formulario de servidor, ósea un Form:

<form id="form1" runat="server">
   ...
</form>

Acá les dejo el código de un ejemplo muy sencillo. Se trata de generar un arreglo con valores el cual se guarda en el ViewState y por cada envío de la página se incrementan lo valores de acuerdo al último valor generado, nada de otro mundo, pero lo importante de esto es que vean como se guarda la información y como la podemos recuperar.

Default.aspx

<%@ Page Language="C#" AutoEventWireup="true" ViewStateEncryptionMode="Always" CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
    </head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:Button ID="Button1" runat="server" Text="Enviar P&aacute;gina" />
    </div>
    <br />
    <div>
        <asp:GridView ID="GridView1" runat="server" CellPadding="4" ForeColor="#333333" 
            GridLines="None">
            <RowStyle BackColor="#EFF3FB" />
            <FooterStyle BackColor="#507CD1" Font-Bold="True" ForeColor="White" />
            <PagerStyle BackColor="#2461BF" ForeColor="White" HorizontalAlign="Center" />
            <SelectedRowStyle BackColor="#D1DDF1" Font-Bold="True" ForeColor="#333333" />
            <HeaderStyle BackColor="#507CD1" Font-Bold="True" ForeColor="White" />
            <EditRowStyle BackColor="#2461BF" />
            <AlternatingRowStyle BackColor="White" />
        </asp:GridView>
    </div>    
    </form>
</body>
</html>

Default.aspx.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

using System.Collections;   //para el ArrayList

public partial class _Default : System.Web.UI.Page 
{
    private ArrayList ArregloDeValores;
    private int UltimoValor;

    //protected override PageStatePersister PageStatePersister
    //{
    //    get
    //    {
    //        return new SessionPageStatePersister(this);
    //    }
    //}

    protected void Page_Load(object sender, EventArgs e)
    {
        //Si se intenta obtener un valor que no existe en el ViewState, no se iniciará ninguna excepción,         //por lo tanto es mejor asegurarse de que el valor existe, por lo tanto es recomendable primero 
        //comprobar la existencia del objeto
        if (ViewState["ARREGLO"] != null)
        {   //  rescato los ultimos valores guardados en ViewState
            ArregloDeValores = (ArrayList)ViewState["ARREGLO"];
            UltimoValor = Convert.ToInt32(ViewState["ULTIMO"]);
            
            for (int i = 0; i < 100; i++)
            {
                ArregloDeValores[i] = UltimoValor + i;
            }

            ViewState.Add("ARREGLO", ArregloDeValores); //  Guardo el arreglo en ViewState
            //ViewState["ARREGLO"] = ArregloDeValores;  //  También puedo guardar el arreglo así
            
            GridView1.DataSource = ArregloDeValores;
            GridView1.DataBind();
        }
        else
        {
            UltimoValor = 100;
            ArregloDeValores = NuevoArreglo(UltimoValor);   //  La primera vez crea el arreglo
            ViewState.Add("ARREGLO", ArregloDeValores);     //  Guardo el arreglo en ViewState
            GridView1.DataSource = ArregloDeValores;
            GridView1.DataBind();
        }
    }
 
    protected void Page_PreRenderComplete(object sender, EventArgs e)
    {
        //Se pueden realizar cambios en el ViewState hasta el evento PreRenderComplete.
        //Después del evento cuando la página se represente en el explorador, no se guardarán los 
        //cambios realizados en el ViewState.
        
        //ViewState.Add("ULTIMO", Convert.ToInt32(ViewState["ULTIMO"]) + 100);Puedo asignar de ambas formas
        ViewState["ULTIMO"] = Convert.ToInt32(ViewState["ULTIMO"]) + 100;
    }

    private ArrayList NuevoArreglo(int Ultimo)
    {
        ArrayList miArreglo = new ArrayList(100);
        for (int i = 0; i < Ultimo; i++)
        {
            miArreglo.Add(i);
        }
        return miArreglo;
    }
}

No olviden de revisar el código fuente resultante de la página y hacer pruebas con el ViewStateEncryptionMode spara ver la información codificada en Base64 encriptada.

Prueba también quitanto los comentaríos a SessionPageStatePersister y si miras el código fuente de la página, notaras que la cantidad de información a disminuido considerablemente de esto:


A tan solo esto:

Es todo por hoy, espero les sea de ayuda.

Saludos Toby

sábado, 30 de enero de 2010

Paso de parámetros por Valor o por Referencia (Ref, Out) en C#

Por Referencia

Una variable de tipo referencia no contiene directamente los datos, contiene una referencia a ellos. El paso de parámetros por referencia permite a los miembros de funciones, métodos, propiedades, indizadores, operadores y constructores, cambiar el valor de los parámetros y hacer que ese cambio persista.

Para pasar un parámetro por referencia, se debe usar una de las palabras clave Ref u Out. Por ejemplo:


static void Funcion1(Ref int dato)
{
    // codigo...
}
.
static void Funcion2(Out int dato)
{
    // codigo...
}

Para pasar un argumento a un parámetro Ref, primero debe inicializarse. Esto es diferente de Out, cuyo argumento no tiene que inicializarse explícitamente antes de pasarlo.

Aunque Ref y Out se tratan de manera diferente en tiempo de ejecución, se tratan de la misma manera en tiempo de compilación. Por consiguiente no se pueden sobrecargar los métodos si un método toma un argumento Ref y el otro toma un argumento Out.

El siguiente ejemplo muestra como trabajar con Ref:


class EjemploRef
{
    static void Funcion1(Ref int dato)
    {
        dato = 3;
    }
    static void Main()
    {
        int valor = 0; // Es necesario inicializar la variable
        Funcion1(Ref valor); // Variable pasada por referencia
        System.Console.WriteLine("El valor es: {0}", valor); // valor a cambiado a 3
    }
}

Como se dijo anteriormente, Out no requiere que se inicialice la variable antes de pasarla. Al utilizar un parámetro Out, la definición de método y el método de llamada deben utilizar explícitamente la palabra clave out.

El siguiente ejemplo muestra como trabajar con Out:


class EjemploOut
{
    static void Funcion2(Out int dato)
    {
        dato = 3;
    }
    static void Main()
    {
        int valor; // No es necesario inicializar la variable
        Funcion2(Out valor); // Variable pasada por referencia
        System.Console.WriteLine("El valor es: {0}", valor); // valor a cambiado a 3
    }
}

Por Valor

Una variable de tipo de valor contiene directamente los datos, a diferencia de una variable de tipo de referencia, que contiene una referencia a los datos. Por lo tanto, pasar una variable de tipo de valor a un método significa pasar una copia de la variable al método. Cualquier cambio en el parámetro que se produzca dentro del método no afectará a los datos originales almacenados en la variable.

El siguiente ejemplo muestra como trabajar pasando parámetros por valor:


class EjemploVal
{
    static void Funcion3(int dato)
    {
        dato = 3;
    }
    static void Main()
    {
        int valor = 0; // Variable inicializada en 0
        Funcion3(valor); // Variable pasada por valor
        System.Console.WriteLine("El valor es: {0}", valor); // valor sigue siendo 0
    }
}

Como pueden observar, la variable valor es inicializada en cero. Cuando se invoca a la Funcion3, el contenido de valor se copia en el parámetro dato, el cual se cambia dentro del método. Sin embargo, en Main, el valor de la variable valor es el mismo, antes y después de llamar al método Funcion3, es decir, el cambio que se produce dentro del método sólo afecta a la variable local dato.

Tal vez en ocaciones al usar el out tengan los siguientes errores:

Error del compilador CS0269
"Uso del parámetro out sin asignar 'parámetro'"

Error del compilador CS0177
"Es necesario asignar el parámetro 'parámetro' out antes de que el control abandone el método actual"

Bueno, esto se debe a que el compilador no pudo comprobar que al parámetro out se le hubiera asignado a un valor antes de utilizarlo, es decir, no se asignó un valor a un parámetro marcado con la palabra clave out en el cuerpo del método. Pero aquí se nos crearía un problema si lo que deseamos es primero leer el valor antes de cambiarlo, por lo tanto en estos casos no nos va a servir el uso de out, entonces la solución es utilizar un parámetro ref en su lugar.

Si necesitan más información, visiten la fuente: http://msdn.microsoft.com


Espero les sea de ayuda.

Saludos, Toby

miércoles, 27 de enero de 2010

Cuando usar Int32.Parse vs Convert.ToInt32 en C#

Int32.Parse lo vamos a utilizar cuando estamos completamente seguros que el texto corresponde a un valor numerico, por ejemplo, si tengo que convertir un valor proveniente de una caja de texto a un entero y hemos limitado a que sólo se ingresen números, no vamos a tener problemas con Int32.Parse.

Pero si el valor proviene de una base de datos, puede darse el caso que el valor que recibamos sea nulo, con lo cual obtendríamos una excepción por lo tanto vamos a tener que hacer try{} catch{}, entonces para evitarnos este problema usamos Convert.ToInt32, que nos devolvera un cero cuando nuestro valor a convertir sea Null.

Saludos, Toby

viernes, 22 de enero de 2010

Usar IsPostBack en ASP.NET

IsPostBack nos entrega un valor que indica si la página se está cargando como respuesta a un valor devuelto por el cliente, o si es la primera vez que se obtiene acceso a ella.

La forma de usar en Visual Basic es la siguiente:

Sub Page_Load
    If Not IsPostBack
        
    End If
End Sub

Y para C# sería así:

private void Page_Load()
{
    if (!IsPostBack)
    {
        
    }
}

Ahora quizás te preguntes ¿y cuando será bueno usar el IsPostBack?

La respuesta es simple, toda vez que no sea necesario ejecutar un código producto de un PostBack (un reenvio de los datos del formulario de vuelta al servidor) el cual puede ser provocado por la accion de un evento click de un boton o el cambio de selección de un combobox.

Por ejemplo, cuando cargas una pagina web y llenas una lista con información que rescatas de una base de datos, no es necesario que consultes la base de datos todas las veces que se hace el PostBack, ya que basta solo con la primera carga.

Saludos, Toby.

Entradas populares