Ser o no ser... un frame...

Como ya os he contado otras veces, estoy a cargo de www.todoexpertos.com, uno de los sitios Web más importantes en castellano, con millones de usuarios únicos mensuales.

No sé por qué, tal vez para un futuro ataque phising, pero hubo otros tres sitios que les dio por poner la Web dentro de un frame sin ningún permiso.

Es decir, utilizaban un código similar a:

<HTML>
<HEAD> </ HEAD>
<FRAMESET>
   <FRAME src = "http://www.todoexpertos.com">
</ FRAMESET>
</ HTML>


Por lo que esa Web parecía ser todoexpertos.com...
Así que, con razón moral pero sin consistencia juridico/legal, podría haberme enfadado... pero decidí que lo mejor era aplicar este sencillo código javascript que asegura que una página no esté dentro de un iframe:

if (top.location! = Self.location) top.location = self.location;

Y con una sola línea te ahorras diversos dolores de cabeza



ASP.NET AJAX Control Toolkit... traducido al castellano!

Es-asp.net se ha convertido en menos de un año en uno de los mayores portales de ASP.NET en castellano. Además de sus concurridos foros, desde hace mucho tiempo se está realizando un poderoso esfuerzo para traducir los tutoriales oficiales de ASP.NET al castellano.

Tras el primer tutorial sobre los servicios web, vino el tutorial de ASP.NET. En este último seguimos trabajando y aprovecho para animar a que cualquiera pueda ayudar a la comunidad de ASP.NET en castellano para traducir del inglés.

La noticia es que a partir de ayer mismo, ya está disponsible el tutorial del ASP.NET AJAX Control Toolkit en castellano: ¡¡todo un bombazo!!

Por el momento el tutorial es una traducción del oficial en inglés, y queda maquetarlo un poco. La novedad es que durante las próximas semanas iremos añadiendo vídeos explicando cómo se usa cada uno de los controles y extendedores del Toolkit, así como código y ejemplos distintos de los explicados en el tutorial oficial

¡Espero que lo aprovechéis!



De XML a JSON con javascript... incluyendo namespaces

Durante estos días he estado haciendo un Google Gadget para todoexpertos.com, web de la que me estoy encargando desde el mes de Abril, tras un par de meses de trabajo junto con mi compañero Richard.

La verdad es que a mí estas cosas me divierten bastante. De hecho, aprovechando he hecho otro gadget para una de mis páginas (playsudoku).

Pero bueno, a lo que vamos. La API de Google Gadgets es muy potente, pero siempre hay algunas cositas mejorables. En mi escenario, lo que pretendo hacer es acceder a la API de Todoexpertos.com (que también he creado yo ) que funciona mediante llamadas REST y devuelve RSS con el Namespace de Todoexpertos incluido. un ejemplo del RSS que devuelve es el siguiente:

<?xml version="1.0"?>
<rss version="2.0"  xmlns:te="http://www.todoexpertos.com/api/te">
  <channel>
    <title>GetExpertCategories</title>
    <link>Url de la API</link>
    <description>Recoge las categorías de un experto.</description>
    <item>
          <title>Arte y ocio</title>
          <te:CategoryPath>/arte-y-ocio</te:CategoryPath>
          <te:CategoryUrl>http://www.todoexpertos.com/categorias/arte-y-ocio/</te:CategoryUrl>

    </item>
  </channel>
</rss>


Pues bien, la API de Google Gadgets ofrece la función "_IG_FetchFeedAsJSON()" mediante la que se accede a la URL de un RSS o un ATOM y te la transforma en JSON, de forma que es sencillísimo manejar el resultado con Javascript (prometo un futuro artículo de JSON).

El problema es que cuando incluyes namespaces al RSS (algo permitido en RSS 2.0), 
"_IG_FetchFeedAsJSON()" no las reconoce!! (o yo no he sabido hacerlo bien ).

Pero bueno, que no cunda el pánico, Google ofrece otra función, "
_IG_FetchXmlContent()", que recoge un XML desde la url que le des como parámetros. Sí, de ese modo sí funciona... pero, ¿por qué tengo que usar XML pudiendo usar JSON?

De modo que me puse a investigar y encontré este fenomenal algoritmo que transforma a JSON desde cualquier XML (no sólo RSS y Atom, como hace la API de Google Gadgets)... pero, ¡tampoco funcionaba bien con Namespaces!

Así que me tuve que poner manos a la obra, cambiando un poco el código original. El problema estaba en que el algoritmo original no reconocía bien los dos puntos ":", usados en los namespaces. Mi aportación consiste simplemente en eliminar los namespaces del XML, antes de pasarlo a JSON.

Este es el código añadido del que os hablo:

    delete_namespace: function(x){
        var indexNamespace = x.indexOf('%3a');
        if (indexNamespace>-1)
        {
            x = x.substr(indexNamespace + '%3a'.length);
        }
        return x;
    }


Donde '%3a' son los dos puntos ':'.

Como véis, en lugar de borrar el namespace,
se puede modificar al gusto, cambiándolo, por ejemplo, por un guión bajo.

Bajaos el archivo adjunto con el algoritmo, de modo que usarlo es tan simple como esto:

    myJsonObject=xml2json.parser(XmlText);


Donde XmlText es el texto en XML.

Espero que os sea de utilidad, pero recordad que todo el mérito es del código original de Thomas Frank.



Controles Web avanzados

En el anterior vídeo tutorial sobre Controles Web Básicos echamos un primer vistazo a los controles ASP.NET más sencillos: el Button, el Hyperlink, el Label, el TextBox y el DropdownList.

Durante este vídeo tutorial vamos a seguir unos Controles Web más avanzados, que no quiere decir que sean difíciles.
Quiero volver a destacar dos cosas: la primera es que todos Controles de ASP.NET acaban traduciéndose en lenguaje HTML, y que eso es lo que van a ver los usuarios de nuestra Web.

En segundo lugar, recomiendo que se piense en los controles Web como lo que son desde el punto de vista de programación: clases. Y como tales, tienen propiedades, métodos, eventos, etc.

A continuación podéis ver el vídeo desde youtube o con descarga directa desde rapidsahre y megaupload.





La historia de mis Webhostings/Hospedajes

Cuando uno decide “hacer una página Web” debe pasar por muchas fases. Una de esas fases es decidir dónde contratar el hosting.

El mundo de los hospedajes Web es enorme, con una oferta gigantesca, de forma que el que se está iniciando no hace sino marearse, buscar durante mucho tiempo, y no conseguir otra cosa más que la indecisión.

Y esto lo digo con conocimiento de causa, ya que se acerca mi decena de años teniendo páginas Web lidiando con este tema tan espitoso, con enormes desencantos y pocas buenas noticias.

Así pues, aprovecho para contar un poco mi historia y hablar un poco de las experiencias de otros compañeros webmasters, y si eso os puede ayudar de algo bienvenido sea :D

Ahora mismo no recuerdo muy bien el porqué, pero desde que me conecté por primera vez a Internet (allá por el 96, cuando iniciamos una dura cruzada por la “tarifa plana”), además de conectarme al IRC demasiado frecuentemente (y siempre por la noche, porque el módem de 14,4 Kbps no daba para demasiadas alegrías durante el día), me llamaba mucho la atención el tener una página Web.

En esos tiempos, Altavista marcaba el ritmo del mundo Web,  jeje. La cosa es que con mi conexión a Arrakis, se nos ofrecía un espacio Web gratuito, con una url que, si no recuerdo mal, era ésta: http://www.arrakis.es/~vija, con la virgulilla incluida y sin poder elegir qué iba detrás de ésta. Por supuesto ese hospedaje Web dejaba muchísimo que desear, y poca cosa se podía hacer más que subir HTML puro y duro. Por cierto, esa primera Web la llamé “el mundo de Murphy”, y pretendía ser lo que hoy en día se denomina un “Blog personal”.

Animado por mis más de 10 visitantes diarios, leyendo las historietas de un adolescente, se me ocurrió una “brillante idea”: ¿por qué no hacer una Web donde se puedan intercambiar apuntes y libros? Probablemente no diga fechas con exactitud, pero estaríamos hablando del 97 o el 98.  En ese caso, la Web la hospedé con Geocities, un hosting gratuito que en su momento fue la revolución y uno de los dominios más solicitados de la red. A parte de HTML, te dejaban programar algo de CGI… ¡¡increíble!!

Pero esa Web cayó en el olvido. Yo no tenía tiempo ni muchas ganas de aprender. Además, conocí otra Web con temática muy similar, que estaba empezando pero que ya tenía la friolera de 300 visitas al día. Además, esa Web era mejor que la mía y aún había muchas ideas por explotar. Se llamaba elrincondelvago.com

Pero fue en 1999 cuando inicié la primera Web con verdadera “repercusión”, y que hoy en día es mi preferida por muchos motivos: discotequeros.com. En ese momento pude comprar también el dominio discotecas.com, pero como el registro valía 5000 pesetas (30 euros), me eché atrás. La web comenzó el 1 de Agosto de 1999 con geocities, con la url www.geocities.com/vija (http://web.archive.org/web/*/http://geocities.com/vinafer), pero para noviembre ya recibía más de 300 visitas y decidí comprar el dominio discoteqeros.com en www.registrateya.com. Además, ya no quería publicidad en mis Webs, así que opté por mi primer hosting de pago: www.hostspain.com. Busqué bastantes empresas de hospedaje, casi todas norteamericanas, pero al final me decidí por esta empresa española, porque era barata y parecía tener un buen servicio.

HostSpain.com resultó sacarme de mis casillas. El tiempo de respuesta del servicio técnico no era del todo malo, pero en cuestión de tres años nunca cambió sus tarifas ni sus servicios ofrecidos. Algo totalmente escandaloso y avergonzante, pues de 1999 pasábamos de que la tarifa plana era una novedad y RDSI era el futuro, a 2001, donde ADSL tenía muy buena pinta.

Así que no tardé en cambiarme a www.aruba.it. Una empresa de telecomunicaciones italiana, que se ve que le sobraba sitio, ancho de banda y equipos, porque ofrecían (y ofrecen) espacio en disco y ancho de banda ilimitado, algo que incluso hoy en día casi nadie se atreve a ofrecer. Además, el precio era de 49$ al año, con lo que no había vuelta de hoja: había que cambiarse. Contraté el hospedaje para ASP (aún no existía ASP.NET 1.0). De hecho, durante dos años no estuvo mal su servicio.

Un par de veces a la semana, durante unos diez minutos sus servidores no respondían. No era para menos, cada servidor hospedaba más de mil páginas Web, y el servicio de atención al cliente… eso no tenía nombre. Tardaban días en contestar y NUNCA, repito NUNCA ofrecían una respuesta acorde con la pregunta. Para mí o contestaba un robot, o no me entendían, o seguían la táctica de “vamos a contestarle rápido a ver si se cansa y no vuelve a protestar”.

La cosa es que discotequeros.com superaba ya las 1500 visitas al día, pero cierto día de Agosto, en plenas vacaciones estivales, me cortaron el servicio sin previo aviso. De hecho yo me enteré casi una semana después (vacaciones e Internet son incompatibles), y entre unas cosas y otras, la Web pasó más de un mes sin servicio. Lo que realmente me molestó es que ni me avisaran, porque al fin y al cabo ellos tenían razón: mi base de datos era Access y con mi cantidad de visitas ocupaba casi el 100% de la CPU, jejejeje.

La solución fue pasarse a MySQL. Hay que tener en cuenta que en esa época era poco más que un aficionado, que sabía ASP lo justo, y MySQL sólo me sonaba de oídas. Es lo que tiene ser un autodidacta cuando tu vida se basa en sacarte la carrera de ingeniería superior de telecomunicaciones.

Pero la historia con aruba no paró ahí, al tiempo me avisaron de que producía un tráfico Web demasiado elevado y que me iban a cerrar la cuenta (¡avisaron!). Era increíble, pero ofrecían ancho de banda ilimitado, pero en las cláusulas del contrato ponía que ellos decidían acerca de la exclusión de Webs con ancho de banda excesivo… para banda ellos, pero de gañanes.

De nuevo a cambiar de hospedaje. Le he llegado a coger mucho miedo a lo del cambio de hospedaje, jeje. Otra vez a buscar sitios y más sitios. Después de dar muchas vueltas, me decidí por hospedar los servicios del que es el registrante de dominios más grande de la Web: GoDaddy.

En su momento pasé el nombre del dominio de registrateya.com a namecheap.com y de namecheap a aruba, pero me obligaron a cambiar a GoDaddy. La verdad es que la gestión de dominios siempre ha sido muy bueno y barata. Ahí nunca he tenido ningún problema. Sólo algunos problemillas con el “bloqueo de dominio” con aruba, pero poco más.

La verdad es que GoDaddy.com prometía. No era el más barato, pero es una empresa enorme, reconocida y con un buen servicio técnico, rápido y con respuestas de calidad. De hecho, lo puedo aconsejar para Webs pequeñas-medianas, porque la relación calidad precio es muy buena.

Sin embargo, yo tuve feos problemas con ellos. Con GoDaddy crecí como webmaster, y llegué a hospedar con ellos hasta 20 dominios activos (ahora ya con ASP.NET 2.0). Pero algunas Webs se hicieron muy grandes y encontré algunos feo bugs que repercutían mucho en el rendimiento. Bueno, más que encontrarlos me los encontraron, porque un buen día GoDaddy decidió que una de mis Webs más pequeñas (www.deporteynutricion.net) consumía demasiada CPU y me cortaron el servicio.

Obviamente me entró de nuevo el pánico, porque ni tal si quiera me avisaron… y si hacían los mismo con mis otras 19 Webs!! Algunas de ellas eran demasiado importantes.

Pánico justificado, porque en poco tiempo me fueron dando de baja algunas Webs, mientras yo trabajaba en resolver esos feos (e imperdonables) bugs.

Al fin resolví el problema, y me volvieron a aceptar los hospedajes… pero yo ya no me fiaba de ellos. ¡Ni mucho menos! Así que llegó un nuevo cambio (espero que sea el último). Me decidí contratar un Servidor Privado Virtual, que es como un servidor dedicado, pero compartido de forma virtual con hasta otras cinco personas.

Tras mucho buscar, me decidí por una empresa joven, de buen precio y buenos servicios: www.aspnix.com. Hoy en día sigo con ellos, y creo que fue una decisión acertada.

Al principio tuve que lidiar sólo con el VPS (Virtual Private Server), configurar los FTP, los servicios Web, ASP.NET, etc. Realmente no es algo complejo, pero una cosa es la teoría y otra la práctica.

Durante todo el tiempo que llevo con www.aspnix.com no han sido todo rosas. He tenido feos problemas con ellos, como reiniciaciones de servidor (yo creo que por problemas de alimentación), problemas con DNS, o un servidor de Base de dato sobreutilizado. Incluso hubo algún momento en que me planteé comprarme un servidor y contratar un housing (en Valencia, mi ciudad, hay buenas empresas de housing), pero eso implicaba gastos demasiado grandes (es el problema que tiene ASP.NET, unos gastos con licencias muy fuertes).

La gran diferencia es que la atención al cliente en aspnix es SOBRESALIENTE. Contestan en muy poquito tiempo, de forma muy personal y con gente altamente cualificada. Siempre que hay algún problema sé que va a ser solucionado, incluso cuando ha sido culpa, mía por alguna mala configuración. Ellos no tienen problemas en conectarse a tu ordenador, echarle un vistazo a la configuración y resolverlo ellos mismo. Otras empresas cobran hasta 60$/hora por este servicio.

Además, tiene un programa de referidos (http://www.aspnix.com/Support.aspx?cid=22), así que si te decides por aspnix y te caigo bien, pues echarme una mano sólo con dar mi mail de contacto (subgurimARROBAgmailPUNTOcom).

En cuanto a experiencias de amigos, puedo sintetizar varias conclusiones:
-          Si tienes varias Webs, lo mejor es un servidor dedicado o un servidor privado virtual
-          Si no eres una gran empresa, no elijas un hosting español. Son todos pésimos.
-          www.aspnix.com es siempre una buena opción
-          www.orcsweb.com es muy caro. ¡Mucho! Pero es el Ferrari de los hostings. Son simplemente los mejores.
-          Siempre puedes echar un vistazo a mi Web sobre hospedajes. La hice en un par de días y tengo algo abandonada, pero es un interesante punto de información.

¿De verdad has llegado a leer hasta aquí?




Controles Web Básicos (video tutorial)

ASP.NET introduce el concepto de control Web. Es difícil dar una definición a un concepto que se autoexplica con sencillos ejemplos, pero como introducción podemos decir que un control Web es un elemento que podemos arrastrar a nuestra página y que mediante código podemos manejar de forma muy sencilla sus propiedades y sus eventos asociados.

Al final de la historia, el control Web acaba enviándose al navegador como código HTML y, si es el caso, javascript asociado desde el que se llamará a los métodos que hayamos definido en nuestro código.

Durante el video tutorial se va a dar un pequeña introducción a algunos de los controles Web más comunes y básicos.
El video tutorial no pretende ser, ni mucho menos, una referencia teórica, sino una ligera toma de contacto del trabajo con controles Web.

Por cierto... mi primer video tutorial
No estoy acostumbrado a enfrentarme al micrófono, así es que tengo algunas erratas tontas que espero que sepáis obviar

Descargar video tutorial (prometo que el siguiente lo subiré a YouTube)



¿Cómo solucionar un error/problema en tu aplicación ASP.NET?

Si hay una cosa SEGURA en programación, es que os vais a encontrar más de una vez con diferentes errores y/o problemas en vuestra aplicación... ¡¡y esto no va a ser menos para ASP.NET!!

Aunque siempre vamos a trabajar en la dura tarea de evitarlo, los errores se pueden cometer y los problemas pueden llegar... el quid de la cuestión es: ¿Cómo lo solucionamos?

No hay un método mágico para ello, lo que si que hay es una metodología con la que enfrentarte a un error/problema. A continuación se muestra una serie de consideraciones que os aconsejo toméis en cuenta durante vuestra carrera de programadores.

1.- Identificar el error.
Aunque parezca una tontería, lo más importante es identificar de dónde proviene el error. Siempre que estemos en la etapa de desarrollo del programa, es conveniente decírselo a nuestra aplicación de modo que ésta esté atenta a todos los sucesos que ocurren, y si hay un error nos lo comunique con la mayor precisión posible. En este artículo tendréis más información al respecto: ¿Cómo le decimos a ASP.NET que estamos en etapa de desarrollo?

Si se trata de un error de compilación, el compilador nos avisará exactamente en qué documento y página está el problema, incluso con un poco de suerte nos propondrá una solución. Ejemplos típicos de este error son fallos en la sintaxis, parseo de variables, etc.

Si nuestra aplicación Web compila bien, pero de algún modo obtenemos un resultado que no esperamos... habrá que trabajar un poco más. En este caso, lo más importante es que tengamos muy claro lo que está haciendo el programa (no siempre es así), para de ese modo poder utilizar los breakpoints y vigilar paso por paso donde está el error. En este artículo tenéis más información sobre el uso de los breakpoints.


2.- Combatir el error/problema
Los errores de compilación son, habitualmente, muy sencillos de corregir. Los demás pueden llegar a ser mucho más complicados, pero usando debidamente los breakpoints son fáciles de localizar y corregir.

Sin embargo, no nos equivoquemos... sobretodo en nuestra época de aprendizaje nuestra mayor falta no son los errores en sí, sino que NO tenemos el suficiente conocimiento de la tecnología para llevar algo a cabo el proceso que requerimos... dicho de otro modo: o no sabemos cómo se hace, o no sabemos como lo hemos podido hacer (aunque sea a medias).

Llegado a este punto las recomendaciones son muy sencillas:
- Buscar en Google.
- Preguntar en foros.

Algo que parece tan sencillo... no lo es en realidad. Estoy seguro de que todos sabéis exprimir las posibilidades de Google al máximo, adecuando las palabras clave de vuestras dudas.

Sin embargo el tema de los foros no es tan sencillo, ya que o no sabemos dónde acudir, o no acertamos a que nos comprendan y nos ayuden.

2.1 ¿A qué foros acudir?
No lo dudéis ni un instante, durante el curso vosotros tenéis un foro exclusivo para cualquier tipo de dudas de cualquier nivel, así como foros específicos semanales. ¡Usadlos!

Por otra parte, tenemos otros foros con una gran comunidad a su alrededor a los que deberemos acudir para solicitar ayuda... y en un futuro para ser nosotros quienes ayudemos!! Estos son:
- Foros de ASP.NET en castellano.
- Foros de ASP.NET en inglés.

2.2 Cómo hacernos comprender
De nada sirve encontrar el mejor foro del mundo... si no sabemos expresar nuestros problemas. Esta parte, aunque parezca trivial, es excepcionalmente importante. Dado el carácter asíncrono de los foros, puede llegar a ser frustrante esperar varias horas a que contesten tu pregunta y te respondan algo como "por favor, podrías explicarte mejor" o "¿cuál es exactamente el error?"... en este caso, la resolución de un problema puede llegar a durar día o incluso ni tal si quiera te respondan.

Aunque el plantear bien una cuestión no es sinónimo de obtener una respuesta, a continuación se plantean una serie de consejos a seguir para el caso:
  • Haber seguido los pasos marcados en "identificar un error", que aunque no nos hayan resuelto el problema, es seguro que nos han servido para comprenderlo mejor y, por ende, expresarlo mejor.
  • Si lo creéis necesario, explicad correctamente algunos datos de la configuración de vuestro equipo. Por ejemplo, si acudís a un foro sobre bases de datos en ASP.NET, y vosotros usáis MySQL, aseguraros de decir algo como "Uso MySQL 4, conectando con ODBC, ASP.NET 2.0 y Windows2003".
  • De haber distintos tipos de foros (algo habitual) dedicad un tiempo a decidir cuál es el foro adecuado a vuestra pregunta. De no hacerlo así, puede que simplemente os borren la pregunta.
  • En caso de tratarse de un error específico es imperativo adjuntar la máxima información posible acerca del error. No sólo el mensaje exacto del error, sino también su traza (trace).
  • Como más vale un error que mil palabras, es esencial que mostréis el código que produce el error/problema, o al menos el que sospecháis que lo produce (acordaos de los breakpoints).
Sobretodo no seáis ni egoístas ni vagos. Tener un error y rápidamente preguntarlo en el foro no os aportará nada y jamás aprenderéis.
De hecho, la gran mayoría de veces las respuestas que os darán nos sean exactamente lo que buscáis, sino que simplemente serán un camino para que por vosotros mismos encontréis al solución. Así es como se aprende.

Aunque tengamos mucha prisa por resolver un problema, más vale invertir 5 minutos en expresarnos lo mejor posible que perder 5 días (si no más) en hacernos comprender.

En los foros de este curso se os "exigirá" este comportamiento.
En otros foros, si no seguís este camino o no obtendréis jamás una respuesta o de obtenerla apenas aprenderéis.


3.- No rendirse
A pesar de lo que en ciertos momentos creamos: el problema/error SÍ TIENE SOLUCIÓN. No humanicemos nuestro código. Siempre hay un motivo por el cual algo no funciona como debería, y por tanto se puede solucionar.

Hay que pensar en el código con lógica pura y absoluta, y sobretodo no desesperar. Cuando creamos que nos vamos a volver locos, es que nuestro planteamiento no es el correcto. Reiniciemos nuestra mente y agrandemos los límites que estamos abarcando.

Incluso en ocasiones se puede caer en la tentación de pensar que el problema sea un "bug de la aplicación". ¡Y no! No es un bug, y en caso de serlo seguro que está tratado, lo podréis encontrar en Google, y en caso de no tener solución... tocará plantearse otro modo de hacer lo mismo ;)



HttpContext.Current.Items

Los que más y los que menos, sabemos lo que es el ciclo de vida de una llamada a una página ASP.NET. Los que no lo estén o quieran más info, les recomiendo este sencillo artículo. Durante el ciclo de vida, hacemos llamadas a clases, inicializamos controles, recogemos información de base de datos, llamamos a servicios Web, etc.

Es bastante común que en dos momentos puntuales del ciclo de vida de nuestra página queramos acceder a un mismo dato desde dos sitios diferentes. Por poner un ejemplo, podemos tener dos clases que acceden a un mismo método que, obligatoriamente, debe acceder a BBDD.

¿Y por qué tener que acceder dos veces a la BBDD en un mismo ciclo de vida si obtenemos el mismo resultado?
Una primera solución podría ser guardar ese dato en una variable de Session, una variable de Application o una variable de Cache, de modo que se puede acceder a ese dato en todo momento... pero aunque esas variables son muy útiles en ciertos momentos, no están hechas para guardar información que sólo es válida en el mismo ciclo de vida.

Pero vale ya de tanta explicación, y veamos un poco de código:

    public static string Valor
    {
        get
        {
            if (!HttpContext.Current.Items.Contains("Valor"))
            {
                HttpContext.Current.Items["Valor"] = NuestraClase.MetodoQueAccedeBBDD();
            }

            return HttpContext.Current.Items["Valor"].ToString();
        }
        set
        {
            HttpContext.Current.Items["Valor"] = value;
        }
    }


El Dictionary "HttpContext.Current.Items" guarda Items durante un mismo ciclo de vida. En nuestro ejemplo, cada vez que leemos la propiedad "Valor" vemos si en el Dictionary existe esa clave. Si no existe, accedemos a un método cualquiera que, como cuello de botella habitual, accede a la BBDD; y metemos el resultado en el Dictionary. De este modo, la próxima vez que accedamos a la propiedad dentro del mismo ciclo de vida de la página, no hará falta entrar en el método que accede a BBDD.

Este modo de trabajar puede ser realmente beneficioso. Yo me he encontrado con proyectos que llamaban hasta 10 veces a un método que tardaba medio segundo en acceder a BBDD y volver... lo que hacía un total de la friolera de 5 segundos!!!! Aplicando este método, rebajamos drásticamente 4,5 segundos.

De este modo, os aconsejo que reviséis vuestras Webs y analicéis dónde puede ser efectivo usar el HttpContext.Current.Items. Huelga decir que en nuestro ejemplo, trabajabamos con un simple "string", pero el Dictirionary "HttpContext.Current.Items" almacena "objects", de modo que podemos guardar absolutamente cualquier cosa .