me canse de usar strings en Session, QueryString, Cache, AppSettings, Application, etc

Como saben en todo desarrollo web vamos a hacer uso de variables de tipo Session, Cache, o Application. Si enviamos variables por URL debemos recuperar con Request.QueryString, las variables. Si tenemos variables de aplicación debemos leer el AppSettings del web.config.

Hasta aquí no hay problema, por ejemplo, quieremos asignar una variable al objeto Session:

   Session[«CodArea»] = 5;

Si vamos a pasar variables por la URL debemos hacer:

   Response.Redirect(«~/mostrarnoticiasportag.aspx?» +
             «CodArea=» + Session[«CodArea»].ToString() +
             «&TagNombre=» + ddlTags.SelectedValue,true);

Y si queremos recuperarlas tenemos que usar:

   Request.QueryString[«TagNombre»], o Request.QueryString[«CodArea»]

No fuera problema, si sólo tenemos una página con usando ese nombre, pero que pasa si varias páginas hacen uso de ese nombre, que pasa si cambiamos el nombre de la variable por alguna razón?, tenemos que ir a todas las páginas y cambiar el nombre. Sólo de pensar eso, nació la idea de evitar ese hard code, y tener alguna manera de tener la lista de elementos en el IntellSense, siempre el dedo puede jugar una mala pasada y tipeamos mal el nombre en string, y mientras descubrimos el porque de nuestro problema, perdemos unos minutos, si tenemos muchas páginas, un error o cambio, los minutos pueden aumentar y ya se siente el efecto de estos cambios.

Lo que se me ocurrió fue usar clases de la siguiente manera:

   public class NOTQuery
   {
     
public static string CodArea
      {
         get { return «CodArea»; }
      } 
      public static string TagNombre
      {
         get { return «TagNombre»; }
      } 
   }

   public class NOTSession
   {
      public static string CodArea
      {
         get { return «CodArea»; }
      }
   }

Y ahora nuestro código de envió, sería de la siguiente manera:

    Response.Redirect(«~/not_mostrarnoticiasportag.aspx?» +
          NOTQuery.CodArea + «=» + Session[NOTSession.CodArea].ToString() +
          «&» + NOTQuery.TagNombre + «=» + ddlTags.SelectedValue,true);

Ahora si, es difícil cometer un error al escribir el nombre, pero se ven unos casos *-), además que si quiero cambiar el nombre del parámetro sólo lo hago en la clase, y no en todas las páginas. Noten que estas variables se puede usar tanto para enviar, asignar, o recuperar.

Así también podemos hacer para Cache, Application, y AppSettings. Lo que se me estaba ocurriendo al redactar el post, es también crear una lista para las páginas aspx :), aunque que para estas, ya existe intellsense, el problema es con los cambios de nombres.

Saludos,

Post cruzado 3Dev Blogs

6 comentarios sobre “me canse de usar strings en Session, QueryString, Cache, AppSettings, Application, etc”

  1. Hola,

    SYo para las sesiones (y variables en cache) lo que hago es lo siguiente:

    1. Creo una clase tal que asi (no es c# exacto, escribo de memoria)

    public class SesionUsuario{
    public static string Nombre
    {
    get { return Session[«NombreUsuario»].ToString(); }
    set { Session[«NombreUsuario»] = value;}
    }

    public static boolean EsAdministrador
    {
    get { if (Session[«UsuarioAdmin»]!=null){
    return (bool)Session[«UsuarioAdmin»];
    }
    else{
    return false;
    }

    }

    set { Session[«UsuarioAdmin»]!= value;}
    }

    }

    2. La uso en cualquier página de esta forma

    if (SesionUsuario.EsAdministrador){
    //hacer cosas
    }
    else{
    //hacer otras cosas
    }
    Response.Write(SessionUsuario.Nombre);

    3. Ventajas: todas :P, intelsense, variables de sesion tipadas, si quieres cambiar el nombre de cualquier variable de sesion solo tienes que tocar en un punto, puedes cambiar de variables de sesion a cookies (por ejemplo) tocando una unica clase, etc. Ademas, una ventaja adicional. Fijate en la propiedad EsAdministrador. Devuelve un booleano teniendo la precaucion de comprobar si la variable de sesion ha sido iniciada o no, evitandonos tener que estar constantemente comprobandolo (aplica igual para cache).

  2. Gracias Pirri, por la acotación!

    Algunas cosas hago así :), es la best practice 29.41 del libro de Francesco Balena.

    Y se nota que Session es mucho mejor hacerlo así. Pero por ejemplo con QueryString sólo se podría hacer una propiedad para directamente recuperar, y hacer una propiedad para recupearr sólo el nombre, y poder enviar el parametro.

    La idea de este post era resaltar la capacidad de listar nombres con una clase, como por ejemplo con los nombres de las páginas Web.

    Lo cual se coplementa con lo que enviastes además de listar nombres, puede listar directamente valores de los elementos como Sessión, Cache, Application, y los que se pueda, y para casos que sólo nececitemos los nombres, sólo usamos eso :).

    Saludos,

  3. ¿Y porque no en vez de usar propiedades, usas constantes hardcodeadas, que a efectos es lo mismo, tal como lo planteas?

    public class NOTQuery {
    public const string CodArea=»CodArea»;
    ….
    ….
    ….
    }

    Esto es como se hace desde siempre y tampoco hay que reinventar la rueda.

    Ademas en tus propiedades todavía hardcodeas los nombres de las varaibles, lo ideal seria que eso fuera a fichero de configuración externo.

  4. Hola Neu!

    Tienes razón, el efecto es el mismo, y en este caso que no se va necesitar que el string cambie caería mejor usar const string.

    y porque no en un archivo externo¿?, es que esto sólo es usado en programación, y no se necesitaría cambiar afuera. Y es que, de todas maneras lo que tu no quieres harcodear, tienes que declararlo en algún lugar, y este caso lo hago en un clase.

    Claro es distinto por ejemplo que tengas que saber cual el nro de noticias a tener en una portada, el tipo de imágenes a subir, en eso no hay duda que debe estar en un archivo de configuración, para que pueda ser configurable. Ahí estamos hablando de «datos» que la aplicación necesita para ejecutarse, y que sería hardcode ponerlos directamente. Pero en este caso CodArea, no es un dato en mi aplicación, es una «constante».

    Por otro lado, si usamos constantes no podemos leer de archivos externos, ya que la expresión asignada a una constante debe poder ser evaluada completamente en tiempo de compilación.

    P.D.: Si hemos tenido esta configuración con propiedades, y hemos cambiado a constantes, se vio la necesidad de entrar a cada página y cambiar alguna valor¿?, NO!, es la utilidad que quiero recalcar que si en algún momento del desarrollo vas cambiar el nombre de la constante, sólo lo hagas en esa clase, más no tener que ir a buscar en cada página. Además ya no tienes errores de tipo, por el intellsense generado.

    Aupa, que sigan los comentarios que hacen que lo posteado sea mejor validado, y también permite discutir de otros temas relacionados.

    Saludos,

  5. Hola, y por qué en vez de una clase no usas un tipo enumerado, ¿no sería más correcto? ya que es un tipo por valor y por tanto más eficiente.

    Un saludo, Pedro.

  6. Y puede ser no?, en mi caso veo a una enumeración más cuando desees asignar valores y para comunicación de clases, pero en este caso de sólo listar, y puede ser.. en algunos casos, porque recuerda que en una propiedad puedes agregar algunas condiciones adicionales, cosas que no puedes hacer en una enumeración. Pero imaginemos que no necesitemos eso, y que lo hagamos en enumeraciones, de todas maneras se necesitará convertir la enumeración en String, y eso..

    Por cierto este post es interesante sobre las enumeraciones: http://geeks.ms/blogs/rfog/archive/2007/04/07/hay-cosas-del-c-que-no-puedo-comprender.aspx.

    Saludos,

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *