Cierto es que con la llegada de la tecnología AJAX a nuestras vidas, hemos conseguido reducir parte de ese coste (con las peticiones asíncronas y la renderización parcial de página), pero, pese a todo, todavía quedan aspectos en los que la mejor opción sigue siendo ejecutar código en el lado del cliente. El lenguaje más utilizado para programar ése código del lado del cliente es Javascript, por lo que se nos hace necesario orquestrar la comunicación entre ASP.NET en el servidor (incluso si usamos ASP.NET AJAX) y Javascript en el cliente.Este artículo no pretende ser una referencia al lenguaje Javascript, sino a cómo añadir código Javascript a nuestras páginas aspx (WebForms) y realizar la comunicación entre el cliente y el servidor utilizando este lenguaje. En cualquier caso, existe una lista casi interminable de recursos en la web en los que podremos encontrar o informarnos acerca de los temas más básicos o extremos de este lenguaje.

Así pues, comenzaremos con la foma más simple de añadir código Javascript a nuestra página ASP.NET: añadiendo el código al código ASP/html de nuestra página. El siguiente ejemplo muestra cómo añadir una función javascript que ejecuta un Alert mostrando un texto cualquiera:

Ejemplo simple de uso de Javascript desde ASP.NET

Como se puede observar en el código, hemos añadido el código Javascript directamente en el código ASP/html de nuestro WebForm. VS2008 y posteriores proporcionan IntelliSense para Javascript, con lo que añadir este tipo de código resulta muy fácil.
En este ejemplo, se define una función que simplemente muestra el mensaje que le llega como parámetro. Desde el control Button (es un control de ASP.NET, por lo tanto del lado del servidor) invocaremos a esta función pasándole el mensaje que queramos. Para ello, indicamos el atributo OnClientClick indicándole la función a ejecutar en el cliente cuando se haga click en el botón. Justo después de ejecutar la función indicada, el Button hace un Postback al servidor.

El resultado de ejecutar este código es el siguiente:

Ejemplo de ejecución sin pulsar el botón

Ejemplo 1 tras pulsar el botón y ejecutarse el código Javascript

Hasta aquí todo muy simple, ¿verdad? Bien, avancemos un poco.
En muchas ocasiones disponemos de un archivo con extensión .js que hemos utilizado a modo Librería de funciones Javascript. Nos gustaría hacer referencia a dicho archivo con tal de poder reutilizarlo en varias apliaciones. Pues bien, vamos a comprobar cómo se hace paso a paso:

1. Añadimos o creamos el archivo en nuestra solución (podemos utilizar el menu Añadir – Elemento Existente  para seleccionar un archivo existente o bien Añadir – Nuevo elemento para crear un nuevo archivo vacío).
2. Para añadir una referencia a este archivo desde nuestra página .aspx, es tan fácil como, en la vista de código ASP/HTML, arrastramos el archivo desde el explorador de soluciones a la linea en la que queremos añadir la referencia.
   

   Arrastramos el archivo desde el explorador de soluciones a la linea de código dónde queremos situar la referencia.

3. Una vez hecho esto, ya podemos hacer referencia, desde el código ASP/Html a las funciones Javascript definidas dentro del archivo referenciado. Para demostrarlo, añadimos un nuevo botón a nuestra página de ejemplo que hace referencia a la función mostrarFechaYHoraDelCliente definida dentro del archivo que hemos referenciado. A continuación se muestra tanto el código añadido a la página .aspx como el contenido del archivo referenciado:
   

   Añadimos un campo input del tipo button a la página. Al hacer click en el botón se ejecuta la función que contiene el archivo referenciado.

   

   Código Javascript contenido en el archivo referenciado.

   Este código Javascript recoge la fecha y hora del cliente y la muestra justo debajo de todos los controles que contiene la página. En caso de referescar la página, se actualiza la hora.

Una vez hemos seguido estos pasos, ya podemos ejecutar la aplicación para comprobar que todo funciona correctamente:

Al pulsar el boton se muestra la hora actual en el cliente.

 El objeto ClientScriptManager:

Hasta el momento se han comentado las bases para poder añadir funcionalidad Javascript a nuestro código ASP.NET en tiempo de diseño (conceptualmente no hay mucho más que añadir. Ahora podríamos complicar el tema mucho más, añadiendo funciones Javascript que llaman a otras funciones Javascript y más controles que hagan uso de esas funciones en sus diferentes eventos), pero el concepto es el mismo que hemos comentado.

Ahora bien, en muchas ocasiones, el código lo generamos de forma dinámica desde el lado del servidor en función de varios parámetros. En este caso, ¿cómo hacemos para enviar código Javascript al cliente? Pues es en este contexto cuando más sentido tiene utilizar la clase ClientScriptManager.

 Para demostrar su uso, volveremos a mostrar los mismo ejemplos pero ahora añadiremos los scripts desde el código de servidor haciendo uso del objeto ClientScriptManage. Para ello, volveremos a dejar el código ASP.NET/HTML en su estado inicial:

Una vez hecho esto, en el evento Page_Load pasaremos a utilizar el objeto ClientScriptManager para añadir nuestro código javascript. Como hicimos antes, nuestro primer ejemplo tratará de mostrar un mensaje al pulsar el botón con el título “Pulsa para ejecutar Javascript”. Para ello haremos uso del método RegisterClientScriptBlock. Este método nos permite registrar código javascript en el cliente, o lo que es lo mismo, añadir funciones javascript a la respuesta enviada desde el servidor. Para añadir la función muestraAlerta, el código es el siguiente:

Código que muestra el uso del método RegisterClientScriptBlock el cual añade código javascript a nuestra página.

 Y si lo ejecutáis, vereis que el efecto es exactamente el mismo que en el ejemplo anterior. Incluso podemos ver qué códgio ha sido enviado al servidor para comprobar el funcionamiento. Para ver el código, hacemos click con el botón derecho en la página y seleccionamos “Ver código fuente”. Podremos ver lo siguiente: 

Se muestra el código fuente que llega al cliente.

Una vez hecho esto,  avanzaremos en el ejemplo y . tal y como hicimos en la primera parte, ahora añadiremos una referéncia a un archivo javascript existente. Para ello haremos uso del método RegisterClientScriptInclude de la clase ClientScriptManager. Este método nos permitirá añadir la referéncia a un archivo javascript existente en nuestro servidor, o lo que es lo mismo, nos permite añadir al código html del cliente una linea tal como esta:

Uso del método RegisterClientScriptInclude

Para que, como en el ejemplo inicial, el segundo botón pueda llamar a la función que se encuentra definida dentro del archivo, es necesario capturar el evento onclick y asignarle una llamada a dicho método.

Modificamos el html para el submit de forma que llame a la función definida dentro del archivo javascript

Obvia decir que el resultado de ejecutar este ejemplo es exactamente el mismo que en la rimera parte del artículo.

Por último, vamos a mostrar cómo registrar una función javascript para que se ejecute al cargarse la página (de forma automática). Para ello haremos uso del método RegisterStartupScript de la clase ClientScriptManager tal y como se muestra en la siguiente imagen:

La última linea muestra el código necesario para ejecutar un script al iniciar la página

 Y el resultado de ejecutar esta página es el siguiente:

Ejecución de la página. Se ejecuta el javascript definido al iniciar la carga.

Como se puede comprobar en la imagen, el script se ejecuta durante la carga de la página (al inicio de la misma).

En este artículo se ha tratado de generar código Javascript de forma manual sin hacer uso de ninguno de los miles de Frameworks existentes (y , por cierto, de gran utilidad) como podría ser JQuery (para mi gusto, uno de los mejores frameworks para trabajar con Javascript). Aunque seguramente hay muchos programadores C# que siguen siendo reticientes a aprender las características de este lenguaje de cliente. Para ellos tambien existe soluciones, como puede ser el uso de Script#, un add-in para Visual Studio que nos permite escribir funciones en C# y, tras ser compiladas, estas se traducen a Javascript y se almacenan en su correspondiente archivo .js.
Así que, como podeis ver, existen muchas alternativas para todos los programadores con tal de que podamos enriquecer la experiencia de nuestros usuarios desde el propio cliente.

Un saludo a todos y, como siempre, espero que os sea útil!

Escenario:

Pongámonos en situación. Con tal de demostrar el uso de la directiva OutputCache, desarrollaremos una pequeña aplicación web en la que se mezclen formularios web estáticos y dinámicos (como ocurre en el 90% de las aplicaciones web). La aplicación constará de una página inicial en la que se mostrará un menú mediante el cual el usuario navegará por el web site.  Crearemos un formulario web en el que el usuario especificará el nombre de un Artista y se mostrarán los Álbumes editados por dicho Artista. Por último veremos ejemplos de cómo mejorar ciertas partes del Caching mediante el uso de UserControls.

OutputCache: la directiva

La directiva OutputCache debe aplicarse al código ASP.NET o html de nuestra página.  La sintaxi para utilizar esta directiva es la siguiente:

<%@ OutputCache Duration=“x” VaryByParam=“none” %/>

Como puede observarse, además de declarar la directiva, deben especificarse como mínimo dos atributos:

• Duration: especifica el tiempo que se almacena en cache el resultado de esta página
• VaryByParam: especifica si se debe guardar en cache una versión por cada valor de un parámetro concreto. Por ejemplo, podríamos indicar VaryByParam=”name” y se guardaría una versión de la página por cada uno de los posibles valores de la variable “name”. Si hacemos una llamada a la página con name=”javi” se guardará el resultado en cache y si luego hacemos la misma llamada pero con name=”luis” se guardará otra versión de la misma página pero con el resultado cuando la variable name=”luis”.

La directiva acepta otros atributos que iremos comentando más adelante, pero estos dos son los mínimos requeridos.
Como veremos más adelante, podremos configurar todos estos elementos tanto en código asp.net html como en el archivo web.config.

Así pues, la primera imagen que se muestra es la página principal del site:

Página principal del site

Como puede verse, la página consta de un menú de navegación y varios textos estáticos. Esta página es una firme candidata a ser “cacheada”, puesto que no parece probable que vaya a ser modificada de forma asidua y sus controles tienen datos estáticos. Si miramos el trace generado por la petición para obtener esta página, veremos lo siguiente:

Trace de la petición inicial

El tiempo total en renderizar la página es de 0.0134 segundos. Como ya hemos dicho, esta página es la candidata ideal para ser “cacheada”. Para ello, lo que haremos será añadir la directiva OutputCache a la página, tal y como se muestra en la siguiente imagen:

Añadimos la directiva OutputCache con los atributos requeridos

El resultado de añadir esta directiva es que la página no volverá a ser renderizada (atención, nos saltaremos TODO el proceso de renderización de la página, con lo que el ahorro de tiempo es máximo) y se devolverá inmediatamente el resultado al cliente. Si ahora volvemos a ejecutar la página y miramos el trace, encontraremos lo siguiente:

Trace con la directiva OutputCache activada.

Como podéis observar, ni siquiera marca entrada alguna en el registro de tiempos. Eso se debe a que se ha saltado todo el proceso de renderización de la página, con lo que no se han podido calcular los tiempos invertidos en cada fase o evento del proceso. Si, el ahorro de tiempo es máximo.

Imaginemos ahora que, en esta misma página, tan sólo hay un elemento texto que debe ser dinámico. Pongamos, por ejemplo, que queremos que se muestre la hora del servidor en nuestra web. Claro, si cacheamos la página entera, siempre aparecerá la misma hora (hasta que caduque la caché). ¿Significa eso que ya no puedo guardar en Cache esta página? Pues no, ni mucho menos. Para este caso en concreto, en el que deseamos que cierto texto sea dinámico, podemos utilizar el control Substitution. Este control nos permite sustituir determinados valores de nuestra página en Cache, devolviendo así siempre el valor deseado y manteniendo en Caché la página en sí.
Vamos a mostrar un ejemplo para que quede demostrado el uso del control Substitution:

Añadiremos, al pie de nuestra web, dos textos en los que se indicará la hora del servidor. El primero se ejecutará desde el lado del servidor, es decir, obtendremos el valor del tiempo en el evento On_Load de la página y lo mostraremos. El segundo utilizará el control Substitution para mostrar la hora:

Muestra cómo queda el diseño de la página. Además se muestra el control Substitution en la caja de herramientas.

Para que el control Substitution funcione correctamente, es necesario especificar, en sus propiedades, el método al que debe llamar para obetener el texto a mostrar.  El código de la página principal se muestra en la siguiente imagen:

Se recoge la fecha del servidor en el evento Load de la página y en el método llamado por el control Substitution

Ahora podemos ejecutar la aplicación. Al recibir la primera petición, ambos controles muestran el mismo valor:

Ambas lineas muestran el mismo valor al recibir la primera petición (ya que la página no está cacheada)

Una vez se ha recibido la respuesta, el servidor a cacheado la página, con lo que si ahora refrescamos, como la duración es de 60 segundos, el servidor nos devolverá la página cacheada, pero aplicando la sustitución al control substitution, por lo que el resultado es este:

El tiempo mostrado por el control Substitution se ha refrescado, mientras que el otro no, ya que proviene de la página Cacheada.

Como puede verse, la primera linea mantiene el valor que hay en la página Cacheada mientras que el valor de la segunda linea se ha actualizado gracias al uso del control Substitution, mostrando así la hora del servidor actualizada.

Pero bien, no nos vamos a ganar el cielo tan fácilmente no? Claro…y que ocurre con aquellas páginas cuyos datos són dinámicos (bien porque contienen controles dinamicos como listview, gridview, formview, detailsview,etc… o bien porque las construimos de forma dinámica).
Bueno, lo primero que hay que comentar es que no todo puede ser cacheado. Utilizando la Cache ganaremos en velocidad (mejor dicho, tiempo de respuesta), pero la contrapartida es que aumentaremos la memoria ocupada y esto, cuando llega a ciertos límites, acaba produciendo una disminución de la velocidad y finalmente un colapso en el servidor. Debemos elegir cuidadosamente aquellas páginas/elementos a cachear.

Segundo: debemos elegir aquellas páginas que varien por parámetros cuyos rangos de valores no sean demasiado grandes, pues por cada uno de los valores comprendidos en dicho rango se almacenaría una cópia de la página.

Bien, veamos qué podemos hacer con una página que contiene datos dinámicos.

La página que trataremos de “agilizar” es la que se muestra en las siguientes imágenes:

El usuario selecciona un Artista y se le muestran todos los Álbumes de que se dispone.

Otro ejemplo, con un Artista diferente

Bien, podemos observar que esta página contiene datos estáticos (la parte superior de la misma, en la que se muestra el título, el menú, etc..) y datos dinámicos (el DropDownList + el GridView). Evidentemente no podemos guardar en cache una versión de la página por cada uno de los Artistas que hay en el DropDownList (ya que la lista es interminable), Cachear la página tal y como hicimos en el ejemplo anterior no tiene sentido, pues siempre veríamos el mismo album y artista. Entonces ¿está página no puede cachearse? La respuesta es no tal y como está. El resultado del DropDownList y del GridView no podremos cachearlos, pues son dinámicos (en cualquier caso podríamos cachear el datasource del dropDownList y, quizás el del GridView con tal de no volver a buscar en la base de datos). Pero fijémonos bien. Hay una parte en la página que es estática. Podríamos reducir el tiempo necesario para renderizar esta página si pudiéramos cachear sólamente esa parte. Pues lo cierto es que podemos hacerlo. El tema consiste en poner toda esa parte estática dentro de un UserControl y cachear ese UserControl tal y como hicimos en el ejemplo anterior.

UserControl que contiene la cabecera estática

Ahora, añadimos la cabecera tanto a la página principal, como a la página de búsqueda de albums:

Añadimos la cabecera al Webform de búsqueda de Albums

Antes de marcar el UserControl para ser cacheado, vamos a comprobar el tiempo que tarda la petición en el servidor:

Muestra el trace inicial (sin outputCache del UserControl)

Ahora añadiremos la directiva OutputCache a nuestro UserControl, tal y como se muestra en la siguiente imagen:

Añadimos la directiva OutputCache al UserControl de la misma forma que hicimos con la página principal.

Y finalmente volveremos a realizar la petición para volver a comprobar el tiempo que se tarda en generar la respuesta a la petición:

Se puede comprobar la disminución del tiempo necesario para generar la respuesta a la petición

Se puede apreciar la diferencia del tiempo invertido en generar la misma respuesta que en la petición anterior.

Configurando la directiva OutputCache:

Hasta el momento sólo hemos utilizado dos atributos de la directiva OutputCache: Duration y VaryByParam. Pero la directiva admite otros atributos que nos pueden proporcionar funcionalidades muy interesantes:

• Shared: determina si se puede compartir la versión cacheada con múltiples páginas.
• SqlDependency: al igual que con el objeto Cache, podemos crear una dependencia a una tabla de una base de datos concreta.
• VaryByCustom: Nos permite especificar si queremos guardar una versión de la página por cada Browser y versión o bien por cada valor diferente de un string que le pasamos.
• VaryByHeader: Guarda una versión por cada valor diferente de una cabecera http determinada.
• NoStore: Se envia la cabecera no-store. No disponible para UserControls.
• Location: especifica las cabeceras de cache que se van a enviar al cliente. De esta forma se determina si la versión de la página se almacena en el cliente, en el servidor, en un proxy, etc…

El objeto HttpCachePolicy:

Una forma alternativa de controlar el OutputCache es mediante el objeto HttpCachePolicy del cual obtenemos unas instancia a través del objeto Response. Con este objeto podemos configurar, programaticamente lo mismo que hemos configurado mediante la directiva OutputCache, aunque nos ofrece algunas funcionalidades extras, como por ejemplo el SlidingExpiration o la renovación del timeout (si una página cacheada tiene una duración de 20 segundos y en el segundo 19 alguien realiza una petición, la duración vuelve a renovarse 20 segundos más).

Para recuperar el objeto, como ya he comentado antes, lo haremos a través del objeto Response tal que así:

El objeto HttpCachePolicy

el nombre Cache no es demasiado adecuado en este contexto, ya que podría confundirse con el objeto Cache que tratamos en el artículo anterior. Por ese motivo debemos tener claros los conceptos.

Cache Dependency:

Al igual que ocurre con el objeto Cache, podemos añadir dependencias a la directiva OutputCache, de forma que podamos caducar la cache en función de la dependencia/s que le hemos añadido.

Para añadir una dependencia a la directiva OutputCache, tan solo deberemos utilizar el objeto Response y su método AddCacheDependency como se muestra en la siguiente imagen:

Añadimos una dependencia a archivo a la directiva OutputCache

En cambio, si queremos añadir una dependencia a una tabla de SqlServer debemos modificar la directiva añadiéndole el atributo SqlDependency.

Modificamos la directiva para que acepte dependencias a Sql

Este atributo acepta dos tipos de valores diferentes:

• CommandNotification: si queremos utilizar la notificación de sentencia de SQL Server 2005 y posteriores (no disponible si aplicamos la directiva a UserControls).
• String con DatabaseName/Table: un string que define el nombre de la base de datos y la tabla a la que se añade la dependencia.

Finalmente, añadiremos la dependencia mediante el objeto Response, como en el ejemplo anterior.
Cabe recordar que para dependencias SQL es necesario añadir las correspondientes entradas en el archivo de configuración web.config (tal y como se comentó en el artículo anterior).

Configuramos la dependencia Sql en el archivo web.config (o en el especificado en el atributo configSource)

OutputCacheProfiles:

Hasta el momento, cualquier configuración sobre la directiva OutputCache la hemos realizado directamente en el código de nuestra página aspx. En muchas ocasiones nos gustaría tener la ibertad de poder modificar, en tiempo de ejecución, los parámetros de dicha directiva (por ejemplo, queremos cambiar el atributo Duration para que la Cache caduque antes o más tarde). En estos casos podemos utilizar (y de hecho es una práctica muy recomendable) los archivos de configuración de la aplicación web para almacenar lo que se conoce como OutputCache profiles.
Estos profiles no son más que los mismos atributos que configuramos en la directiva OutputCache con la ventaja de poder modificarlos directamente en el archivo web.config (o en otro archivo xml siempre que se configure el atributo configSource del nodo correctamente).

Para añadir un nuevo profile al archivo de configuración, solo es necesario crear la siguiente estructura xml:

Ejemplo de configuración de un profile de OutputCache

El archivo web.config en VS2005 y 2008 dispone de IntelliSense, por lo que no es necesario recordar cada unos de los atributos posibles. Es suficiente con seleccionarlos de la lista.
Podemos añadir tantos profiles como queramos. Una vez añadido el profile, sólo nos queda indicarle a nuestra página aspx que debe utilizar dicho profile para configurar la directiva OutputCache. Esto lo conseguimos modificando la directiva de la siguiente forma:

<%@ OutputCache CacheProfile=”MiConfiguracion”%>

Con este simple cambio, nuestra directiva leerá su configuración del archivo de configuración de la aplicación web.

Y eso es todo. Creo que se han abordado ámpliamente todos los aspectos relacionados con la directiva outputcache, dando una visión global bastante completa. Espero que os sirva en vuestros proyectos.

Un saludo!

Tan importante como evitar roundtrips al servidor, es evitar el tiempo de procesado que se invierte en recuperar información persistente (almacenada en una base de datos o bien en un archivo) de forma repetitiva.

Imaginemos la siguiente situación:

Disponemos de una formulario web (Webform o página web) en el que , al pulsar el botón “Obtener datos” se muestran los datos de una tabla en un GridView. Esta tabla y los datos que contiene se generarán dinámicamente al pulsar el botón. La página se muestra en la siguiente imagen, así como el código utilizado para generar la tabla y su contenido (en esta série de ejemplos no utilizaremos ASP.NET AJAX para la comunicación asíncrona):

Bien, si prestamos atención veremos que el contenido de la tabla que se muestra mediante el control GridView es estático (siempre el mismo) sin embargo, cada vez que pulsamos el botón “Obtener datos” invertimos un preciado tiempo de proceso a volver a generar los mismos datos. De hecho, podríamos comprobar el tiempo que se tarda en generar estos datos al mirar en el Trace de nuestra web accediendo a la página trace.axd (cabe recordar que para poder acceder a esta página debemos añadir el nodo <trace enabled=“true” pageOutput=“false“/> a nuestro archivo web.config):

Ahora muestro una captura del Trace para esta página (accediendo a http://localhost:1312/trace.axd)

Evidentemente, la creación de una tabla dinámica con tan pocos datos es muy rápida, pero se puede observar como el tiempo transcurrido entre el primer mensaje en rojo y el segundo es de 0,000404 segundos (un tiempo insignificante). Ahora modificaremos el código mostrado anteriormente para hacer uso del objeto Cache de ASP.NET.

El objeto Cache:

ASP.NET dispone de un objeto llamado Cache, que nos facilitará mucho la inserción y recuperación de objetos de caché (además de la gestión de los mismo como veremos más adelante). Mediante el uso del objeto Cache, podremos almacenar en memoria (durante un tiempo configurarable) cualquier objeto que sea serializable.

El objeto Cache se usa de la misma forma que el objeto ViewState o Session, es decir, mediante un indexador. Este objeto siempre devuelve objetos del tipo Object, por lo que será necesario realizar un cast al tipo de objeto esperado. No se ha comentado anteriormente (y es importante), pero ASP.NET instancia un objeto Cache por cada una de las aplicaciones que maneja (es decir, no es a nivel de usuario sino de aplicación).

De forma esquemática, podemos utilizar el objeto Cache tal que así:

Cache[“Miobjeto”]=miObjeto;

O bien

Tipo miObjeto=(Tipo)Cache[“Miobjeto”];

Ahora bien, para utilizar el objeto Cache, normalmente se siguen tres pasos básicos:

1. Comprobar si el objeto existe en la Cache
2. Si existe, lo recuperamos de la cache.
3. En caso contrario, creamos el objeto (es decir, realizamos la consulta a la base de datos, leemos el archivo o creamos los objetos como en este ejemplo, o lo que sea necesario para generar los datos). Finalmente, añadimos el objeto a Cache para poder utilizarlo posteriormente.

Procedemos a modificar el código anterior siguiendo estos tres pasos:

Aquí se muestra el nuevo código que hace uso de la cache siguiendo los tres pasos previamente definidos.

Y a continuación se muestra una segunda captura del trace para observar que hemos conseguido reducir algo que ya de por sí era de un coste muy bajo:

Se puede observar una reducción del tiempo de proceso invertido en generar la respuesta para esta petición (marcada con el mensaje "Usamos la cache").

El efecto del uso de la cache es más evidente cuando el proceso de recolección de datos (mediante una consulta a base de datos o leyendo de un archivo) es más lento que el que se muestra como ejemplo, pero creo que este ejemplo es bastante claro y facilita asumir los conceptos.

Actualizando la cache:

Seguramente a estas alturas alguien ya habrá clamado contra el cielo: “¡Pero los datos que utilizo en mi aplicación no son estáticos! ¡La cache no me sirve!”. Pues no estás en lo cierto. Evidentemente ASP.NET ya dispone de los elementos necesarios para gestionar este escenario. Ahora entraremos a describir las CacheDependencies.

Podemos asociar nuestros objetos en Cache con otros elementos que harán que esta entrada sea eliminada, obligando a que la próxima petición que requiera ese objeto/s vuelva a obtenerlos, guardando así una versión actualizada de los mismos en Cache. Esta asociación entre nuestros objetos en Cache y elementos externos se produce a través de las CacheDependecies (o dependencias de Cache).

Escenario:
Imaginemos el siguiente escenario. Tenemos la misma tabla dinámica que hemos definido anteriormente (la tabla generica) pero serializada en un archivo con formato xml. Queremos que nuestro DataTable (el DataTable generica del ejemplo anterior) en Cache se elimine cuando alguien modifique el archivo xml que contiene sus datos. De esta forma, en la próxima petición ASP.NET se verá obligado a obtener los datos leyendo el archivo de nuevo y guardando el DataTable en Cache (así obtenemos los datos actualizados).
Para ello, hemo definido un nuevo botón al ejemplo anterior (botón que serializa el DataTable a un archivo xml, añadíendole un nuevo registro) y hemos modificado el código del botón ObtenerDatos.

Modificamos el método ObtenerDatos para que: 1) Lea la tabla del archivo. 2) Guarde la tabla en Cache con una dependencia al archivo.

En este código, añadiremos los elementos a la Cache mediante el uso del método estático Add (no utilizaremos el indexador). Este método nos permitirá definir la CacheDependency a utilizar. Deberemos especificar, además de la clave y el objeto a serializar (como en el uso con indexador) el tiempo máximo que va a permanecer en Cache el objeto (he definido DateTime.MaxValue para definir un tiempo ilimitado) y un TimeSliding (tiempo sin uso que hace que el objeto sea eliminado de la Cache. He definido que tras 5 días sin ser usado, debe eliminarse el objeto de Cache). Podeis obtener toda la información a cerca de este método aquí.

Ahora muestro el código del método ModificarArchivoXml, el cual añade un nuevo registro a la tabla y la guarda en el archivo xml, cancelando asi el objeto en Cache (por la dependencia que añadimos antes).

Método que añade un nuevo elemento a la tabla Generica y la serializa al archivo xml.

Ahora, el diseño de nuestra página es este:

Nuevo diseño de la interfaz gráfica de la página.

Ahora pasamos a ejecutar la página. Mostraré capturas del Trace para que pueda comprobarse tanto el uso de la cache, como de las dependencias que hemos declarado asi como para comprobar cómo el hecho de guardar los datos en un archivo implica un mayor tiempo de procesado y cómo el uso de la Cache lo reduce drásticament.

Primero, pulsamos el botón ObtenerDatos para leer los datos del archivo:

La primera petición necesita leer los datos del archivo, lo que consume mayor tiempo de proceso que en el ejemplo anterior.

Observad que la petición ha tardado 0,005340 segundos en procesarse. Ahora  pulsamos el botón de nuevo para obtener los datos de Cache.

Ahora obtenemos los datos de la cache. Observad la reducción de tiempo.

Al pasar por Cache, la petición ha tardado 0.000803 (un 150% más rápido). Ahora pulsamos el botón ModificarArchivoXml:

Puede verse cómo pasamos por el método que añade una nueva fila a la tabla y la serializa al archivo xml.

Por último, volvemos a pulsar el botón ObtenerDatos. Ahora podremos ver como vuelve a leer los datos del archivo (nosotros en el código en ningún momento hemos cancelado la Cache o eliminado el objeto de la misma. Lo único que hemos hecho es modificar el archivo xml y, mediante la dependencia, la Cache a borrado el objeto, con lo que obliga al método a volver a leer el archivo para deserializar la tabla).

Hemos tenido que volver a leer el archivo, ya que la cache había caducado por la dependencia.

Creando dependencias con tablas de bases de datos

Una vez llegados a este punto, seguro que alguien ha vuelto a clamar al cielo: “¡Pero mis datos no son ni estáticos ni los tengo en un archivo, los tengo en una base de datos! La caché no me sirve”. Pues vuelves a equivocarte. Con la llegada al mundo del framework 2.0,  el equipo de desarrollo de ASP.NET solucionó este problema. Ahora podemos crear dependencias con tablas de base de datos, de forma que mientras la tabla siga inalterada, el objeto permanecerá en Cache, pero en el momento en que esa tabla sea modificada, entonces la Cache para el objeto quedará caducada, y la siguiente petición deberá volver a acceder a la base de datos para actualizar el objeto en Cache.
Para ello haremos uso del objeto SqlCacheDependency. Este objeto, al igual que el objeto CacheDependency hacía con un archivo, nos permitirá crear una dependencia entre un objeto en Cache y una tabla en una base de datos concreta.

Lo primero que debemos hacer es añadir a nuestro archivo web.config, la siguiente entrada para:

1. Habilitar las dependencias de Cache con Sql
2. Especificar la cadena de conexión (o las cadenas de conexión si hay varias) con las que se comprobará la modificación de la tabla a supervisar.

El código quedaría tal que así:

Muestra el código xml necesario para activar las dependencias de Cache a SQL

Ahora, modificaremos el código del método ObtenerDatos para que :

1. Realice la consulta a la base de datos mediante LinQ (no es requisito ya que puede hacerse mediante cualquier otro método de ADO.NET).
2. Cree la dependencia entre la base de datos y la Cache.

Aquí está el código necesario para hacerlo:

Código necesario para crear la dependencia entre Cache y sql.

Finalmente, muestro el resultado de una consulta. Los tiempos de ejecución son análogos a los del ejemplo anterior, por lo que omito colocar las capturas del Trace.

Resultado de la consulta de Artistas.

Y eso es todo. Espero haberos ayudado a desmitificar el tema de Cache en ASP.NET. Como podeis comprobar es muy simple de utilizar y nos aporta grandes beneficios. Cabe recordar que no hay que confundir el uso del objeto Cache con el uso de la directiva OutputCache, que trato en otro artículo distinto. Pese que los dos hablan de Cachear datos, uno se refiere a Cachear ciertas partes de una página mientras que el otro se refiere a Cachear todo el resultado de una petición.

Como siempre, espero vuestro comentarios! Gracias!

Tagged: .NET, ASP.NET, C# ]]> http://jimenezroda.wordpress.com/2009/08/13/using-asp-net-cache-object-utilizando-el-objeto-cache-de-asp-net/feed/ 0 jimenezroda Diseño de la página Código inicial Resultado de la página tras pulsar el botón Obtener datos Trace de la página inicial Código con uso de Cache Trace de la página utilizando la Cache Método ObtenerDatos modificado Método modificarArchivoXml. Diseño de la página trace2sincache trace2concache trace2nuevafila trace2connuevafila sqlcachewebconfig obtenerdatos3 artistas http://jimenezroda.wordpress.com/2009/08/07/decorator-pattern-patron-decorador/ http://jimenezroda.wordpress.com/2009/08/07/decorator-pattern-patron-decorador/#comments Fri, 07 Aug 2009 11:34:38 +0000 Javier Jiménez Roda http://jimenezroda.wordpress.com/?p=185 ]]> Continuando con la temática de patrones de diseño software, hoy me propongo explicar el patrón Decorador.
En ocasiones, durante la etapa de creación del diseño lógico de nuestra aplicación, podemos encontrarnos que necesitamos poder extender la funcionalidad de una clase en tiempo de ejecución.
Tambien podemos encontrarnos en la tesitura de necesitar que cierta funcionalidad pueda ser “asociada” a diferentes componentes. Es en estos contextos donde el patrón Decorador puede salvarnos!

Un ejemplo muy utilizado para explicar éste patrón es el ejemplo de una Ventana del sistema. Podemos tener ventanas sin borde, con borde, ventanas que proporcionen un icono con ayuda, ventanas que proporcionen un botón para minimizar a la barra de notificaciones, etc..
Bien, uno podría pensar en crear una clase base llamada Ventana con las funcionalidades básicas de este objeto. Al necesitar una ventana con bordes, podríamos pensar en crear una clase llamada VentanaConBorde que herede de la clase Ventana. Hasta aquí perfecto. Ahora necesitamos tambien una ventana que contenga un icono de ayuda. Volveríamos a heredar de Ventana para crear la clase VentanaConIcono. Pero claro, yo quiero tener una ventan con borde e icono. Asi pues tambien debo crear otra clase que herede de VentanaConBorde y que tenga el icono. Esta clase se podría llamar VentanaConBordeEIcono. Una vez hecho esto, nos damos cuenta de que tambien podemos crear ventanas con un botón que minimice a la barra de notificaciones, pero claro pueden ser ventanas con o sin borde y con o sin icono de ayuda (con todas sus combinaciones).

Nos podemos dar cuenta de que con la herencia de objetos no podremos solucionar (de una forma simple y mantenible) este problema. Aquí es donde el patrón Decorador nos ayudará.

Para empezar, éste es el esquema de la solución que propone este patrón:

Muestra las clases que aplican al patrón Decorador y las relaciones existentes entre ellas

Descripción de los elementos del diagrama:

Component: es una clase abstracta que englobará cualquier elemento que puede ser decorado (en el ejemplo anterior, sería una clase AbstractVentana que incluiría los métodos que definien la interfaz para dibujar los elementos).

ConcreteComponent: clase que hereda de Component y que define un elemento que puede ser decorado (la clase Component es abstracta, por lo que no puede instanciarse). Es clase implementará las operaciones de la clase Component dando una primera funcionalida base (en el ejemplo anterior, correspondería con la clase Ventana, y el método dibujaría una ventana básica, sin bordes ni nada parecido).

Decorator: es la clase base para cualquier decorador que vayamos a utilizar. Se trata de una clase abstracta que será agregada (las clases que la hereden) a cada componente (en el ejemplo, sería una clase AbstractDecorator que no implementaría los métodos de la base, pero que tendría como atributo el componente al que se está aplicando (a nivel de instancia)).

ConcreteDecorator: se trata de una clase que hereda de Decorator y que define una funcionalidad concreta a añadir al componente (en el ejemplo podría ser añadir un borde, un icono o un botón. Cada una de ellas sería una clase que deriva de Decorator y que puede asociarse a cualquier Ventana).

Un ejemplo práctico

Con tal de que el patrón quede claro, voy a mostrar un pequeño ejemplo de código en el que utilizo este patrón.

El ejemplo que voy a desarrollar se trata de elaborar iconos a los que se les pueda añadir otros iconos informando de detalles concretos (por ejemplo, en el sistema operativo Windows Vista, cuando una aplicación requiere de aprobación del Administrador,  su icono está “decorado” con otro pequeño icono en forma de escudo en los 4 colores del icono de windows). Viene a ser el mismo ejemplo. Queremos poder decorar ciertos iconos en función de las características que se apliquen a ese icono.

Esta clase se corresponde con la clase Component del diagrama de clases UML para el patrón Decorator.

En segundo lugar, pasamos a crear la clase AbstractDecorator que será la clase base para todos aquellos decoradores que puedan aplicarse a un icono (en realidad no es más que otro icono que dibujaremos encima del original, en una posición concreta).

Esta clase se corresponde con la clase Decorator del diagrama de clases UML del patrón Decorator.

Ahora que ya hemos definido las clases base, podemos crear las clases que heredarán de estas y que serán las que nos proporcionarán toda la funcionalidad. Emepezaremos definiendo un decorador concreto:

Esta clase se corresponde con la clase ConcreteDecorator del diagrama de clases UML del patrón Decorator.

Y ahora una clase que herede de la clase AbstractIcon y que admita decoradores:

Esta clase se corresponde con la clase ConcreteComponent del diagrama de clases UML para el patrón Decorator.

Por último os dejo el código de un formulario Winform en el que se hace uso de todas estas clases para dibujar un icono al que, al pulsar un botón del formulario, se le añade un decorador.

Simplemente remarcar que, por el diseño que hemos realizado, un decorador puede contener otros decoradores, lo que nos proporciona un enorme abanico de posibilidades y combinaciones.

Y eso es todo sobre este patrón. Como veis, en determinadas situaciones puede resultarnosde mucha utilidad, como todos los patrones de diseño.
Como siempre, espero que este artículo os resulte útil e interesante!

¡Hasta otra!

Esto evita que introduzcamos nuevos bugs o errores en un código existente. Si nunca lo cambiamos,¡ nunca lo rompemos!

¿Y cómo llevamos a cabo nuestro objetivo?

Pues no hay un método o procedimiento único. Debemos aplicar, en cada contexto, aquellos patrones de diseño que nos permitan preveer posibles actualizaciones o ampliaciones de nuestro código.
Un ejemplo práctico:

A continuación os presento un pequeño ejemplo en el que muestro los beneficios de aplicar correctamente los patrones de diseño con tal de cumplir con el principio Open Closed:

Este ejemplo muestra una clase llamada Filtro que se utiliza para filtrar los elementos que se le pasan dentro de una colección en función de uno de los atributos o propiedades de dichos elementos. En este ejemplo, la clase filtro filtrará elementos del tipo Persona. La clase persona tiene el siguiente código:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OpenClosedPrinciple
{
    /// <summary>
    /// Clase Persona. Almacena los atributos básicos de una
    /// persona. Sirve de ejemplo para mostrar los beneficios
    /// de aplicar el principio Open Closed.
    /// </summary>
    public class Persona
    {
       #region Class attributes

       /// <summary>
       /// Nombre de la persona
       /// </summary>
       private string _name;

       /// <summary>
       /// Apellidos de la persona
       /// </summary>
       private string _secondName;

       /// <summary>
       /// Edad de la persona.
       /// </summary>
       private int _age;

       #endregion

       #region Class constructors

       /// <summary>
       /// Constructor por defecto de la clase Persona
       /// </summary>
       public Persona()
       {
       }

       /// <summary>
       /// Constructor que recibe como parámetro el nombre de la persona
       /// </summary>
       /// <param name="name">Nombre de la persona</param>
       public Persona(string name)
       : this()
       {
          this._name = name;
       }

       /// <summary>
       /// Constructor que recibe como parámetro el nombre
       /// y el apellido de la persona
       /// </summary>
       /// <param name="name">Nombre de la persona</param>
       /// <param name="secondName">Apellido de la persona</param>
       public Persona(string name, string secondName)
       : this(name)
       {
          this._secondName = secondName;
       }

       /// <summary>
       /// Constructor que recibe como parámetro el nombre, apellidos y
       /// la edad de la persona
       /// </summary>
       /// <param name="name">Nombre de la persona</param>
       /// <param name="secondName">Apellido de la persona</param>
       /// <param name="age">Edad de la persona</param>
       public Persona(string name, string secondName,int age)
       : this(name,secondName)
       {
          this._age = age;
       }

       #endregion

       #region Class public properties

       /// <summary>
       /// Devuelve o establece la edad de la persona.
       /// </summary>
       public int Age
       {
          get
          {
             return _age;
          }

          set
          {
            _age = value;
          }
       }

      /// <summary>
      /// Devuelve o establece el nombre de la persona.
      /// </summary>
      public string Name
      {
         get
         {
            return _name;
         }

         set
         {
            _name = value;
         }
      }

      /// <summary>
      /// Devuelve o establece el apellido de la persona.
      /// </summary>
      public string SecondName
      {
         get
         {
            return _secondName;
         }

         set
         {
           _secondName = value;
         }
      }

      #endregion
   }
}

Una vez definida la clase que se deberá filtrar (es decir, recibiremos una lista de personas y deberemos filtrar por alguno de sus atributos o propiedades, por ejemplo, filtrar por nombre o por apellidos) ahora podemos pasar a definir la clase que se encargará de filtrar los elementos que recibirá como parámetro. A esta clase la hemos llamado Filtro.

En esta primera muestra de código no utilizaré ningún patrón, por lo que no cumpliremos con el principio, como veremos más adelante:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OpenClosedPrinciple
{
    /// <summary>
    /// Clase filtro. Filtra objetos en base a un atributo de los elementos
    /// y a un parámetro de entrada.
    /// </summary>
    public class Filtro
    {
       /// <summary>
       /// Método que filtra un enumerado de personas en base a su nombre.
       /// </summary>
       public IEnumerable<Persona> Filtrar(IEnumerable<Persona> personas, string nombre)
       {
          foreach (var Persona in personas)
          {
              if (Persona.Name.Equals(nombre))
                 yield return Persona;
          }
       }
    }
}

Esta clase funciona perfectamente. De hecho, a simple vista, nadie diría que tenga que tocarse en un futuro. Pero la verdad es otra y, muy seguramente, en un futuro nos pedirían que se pueda filtrar las personas por su apellido. Esto implica que tenemos que “abrir” la clase, cambiar el código y luego volver a compilar y distribuir. Entonces tendríamos algo tal que así:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OpenClosedPrinciple
{
    /// <summary>
    /// Clase filtro. Filtra objetos en base a un atributo de los elementos
    /// y a un parámetro de entrada.
    /// </summary>
    public class Filtro
    {
       /// <summary>
       /// Método que filtra un enumerado de personas en base a su nombre.
       /// </summary>
       public IEnumerable<Persona> Filtrar(IEnumerable<Persona> personas, string nombre)
       {
          foreach (var Persona in personas)
          {
              if (Persona.Name.Equals(nombre))
                 yield return Persona;
          }
       }

       public IEnumerable<Persona> FiltrarApellidos(IEnumerable<Persona> personas, string apellido)
       {
          foreach (var Persona in personas)
          {
              if (Personas.Apellido.Equals(apellido))
                 yield return Persona;
          }
       }
    }
}

Bueno, no tiene mala pinta, pero, como ya he comentado, hemos tenido que abrir el código, cambiarlo, recompilar y redistribuir de nuevo. Si es sólo por esta vez podríamos aceptarlo, pero ahora viene cuando alguien decide que también debemos filtrar por la edad de la persona. ¿Y que implica eso? Pues volver a abrir, cambiar el código, volver a recompilar y volver a distribuir.
Como podeis ver, no es la mejor de las opciones. Lo que nos indica el principio Open Closed es que la clase Filtro debería quedar cerrada, lo que indica que no deberíamos volver a tocarla. Cualquier nueva funcionalidad la tendríamos que implementar o bien en clases derivadas y sobreescribiendo métodos o bien mediante la delegación de métodos.

La solución, aplicar patrones de diseño o una buena guia de diseño como la que vamos a aplicar…”Encapsular todo aquello que cambia”.

Asi pues, modificaremos el código para que quede de la siguiente forma. Crearemos una interfaz llamada IElemento. Todo elemento (objeto) que pueda ser filtrado, deberá heredar de IElemento.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OpenClosedPrinciple
{
    interface IElemento
    {
    }
}

Crearemos una interfaz llamada IComparacion que será una interfaz genérica y que tendrá un método que nos permita comparar un atributo interno con un elemento del tipo de la interfaz. Esta interfaz deberá ser implementada por aquellas clases que sirvan como comparador a la hora de aplicar un filtro. Por decirlo de alguna forma, la clase que implemente esta interfaz  será la encargada de determinar si un elemento de la lista de elementos totales estará en el resultado o no.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OpenClosedPrinciple
{
    interface IComparacion<T>
    {
          bool CompararCon(T item);
    }
}

Seguidamente, definiremos la interfaz IFiltro. Esta interfaz permitirá definir distintos filtros en función de la comparación y los elementos a comparar. La clase que implemente esta interfaz será la que se encargará de controlar el proceso de filtrado.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OpenClosedPrinciple
{
    interface IFiltro<typodefiltro>
    {
         IEnumerable<typodefiltro> Filtrar(IEnumerable<typodefiltro> elementos, IComparacion<typodefiltro> comparacion);
    }
}

Como puede observarse esta interfaz es genérica y permite definir el tipo de filtro a aplicar. El tipo de filtro nos indicará el tipo de elementos que contendrá la lista de elementos asi como el tipo de objeto que la comparación utiliza para filtrar.
Una vez definidas las interfaces, pasaremos a definir las clases que las implementan. La primera será la clase Persona (tal y como la definimos antes). El único cambio en esta clase es que ahora implementa la interfaz IElemento:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OpenClosedPrinciple
{
    /// <summary>
    /// Clase Persona. Almacena los atributos básicos de una
    /// persona. Sirve de ejemplo para mostrar los beneficios
    /// de aplicar el principio Open Closed.
    /// </summary>
    public class Persona:IElemento
    {
       #region Class attributes
    ...
}

El siguiente paso será crear una clase que implemente la interfaz IComparacion. Crearemos una clase que, tal y como se hacía en el ejemplo original, filtre las personas por su nombre. La clase se llamará ComparacionPersonaNombre.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OpenClosedPrinciple
{
    class CompararPersonaNombre:IComparacion<IElemento>
    {
          private string nombre;

         #region Miembros de IComparacion<string>

         public bool CompararCon(IElemento item)
        {
              return nombre.Equals(((Persona)item).Name);
        }

       #endregion

       public CompararPersonaNombre(string nombre)
       {
             this.nombre = nombre;
       }
   }
}

Esta clase recibe como parámetro un nombre con el que se quiere comparar el elemento que recibe como parámetro el método CompararCon (método definido en la interfaz). Como queremos comparar un nombre con el nombre de una Persona, lo que haces es un cast al objeto item para obtener el nombre de la persona.

Lo último que nos queda por hacer es definir la clase Filtro, que implementará la interfaz IFiltro y que será la encargada de controlar todo el filtrado.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OpenClosedPrinciple
{
      class Filtro:IFiltro<IElemento>
      {
         #region Miembros de IFiltro<IElemento>

         public IEnumerable<IElemento> Filtrar(IEnumerable<IElemento> elementos, IComparacion<IElemento> comparacion)
         {
             foreach (var elemento in elementos)
             {
                if(comparacion.CompararCon(elemento))
                   yield return elemento;
             }
         }

         #endregion
     }
}

Como puede verse, en la implementación del método Filtrar, lo que se hace es recorrer la lista de elementos y aplicar a cada elemento la comparación. Si es válida se añade el elemento a la lista de resultados.

Y con esto ya está todo. Si, es evidente que no es tan simple como antes. No es complicado, digamos que no es trivial. Pero el diseño es mucho más limpio, más cohesionado, menos acoplado y mucho más mantenible.

Por último muestro una pequeña aplicación de tipo Consola que hace uso de todo esto:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Collections;

namespace OpenClosedPrinciple
{
    class Program
    {
      static void Main(string[] args)
      {
           //Creamos una lista de personas.
           IEnumerable<IElemento> personas = listaPersonas();

           //Creamos una comparación por nombre para filtrar las personas
           //por aquellas que se llamen "j"
           CompararPersonaNombre compararNombre = new CompararPersonaNombre("j");

           //Creamos el objeto filtro que va a filtrar la lista de personas
           Filtro filtro = new Filtro();

           IEnumerable<IElemento> filtradas = filtro.Filtrar(personas, compararNombre);

           //Mostramos el resultado
           foreach (Persona persona in filtradas)
           {
             Console.WriteLine(persona.Name);
           }
           Console.ReadKey();
      }

      private static IEnumerable<IElemento> listaPersonas()
      {
          yield return new Persona("j", "j", 25);
          yield return new Persona("p", "p", 35);
          yield return new Persona("k", "k", 45);
          yield return new Persona("h", "j", 15);
      }
   }
}

Y eso es todo acerca de este principio. Espero que os resulte interesante y, sobretodo, útil.

Gracias a todos!

Imaginemos que vamos a desarrollar la clase Persona y nos planteamos determinar cuáles son las responsabilidades y la información que debemos asignarle. En este momento debemos razonar de la siguiente forma con tal de aplicar el patrón alta cohesión: la información que contenga la clase Persona debe estar relacionada con la entidad que se intenta representar, es decir, una clase Persona (entidad lógica) sólo debe contener información y responsabilidades referentes a una Persona (física).Así pues, podríamos asignar como atributo de la clase Persona los atributos siguientes:

- Nombre

- Apellidos

- Año de Nacimiento

- Peso

- Estatura

- Estado civil

- Color del cabello

- Color de ojos

- Sexo

Pero no podemos asignar estos otros, puesto que es información no referente a una Persona:

- Código postal

- Demarcación

- Regalo

- Asignaturas

- Clase

Asimismo, a la hora de asignar las responsabilidades de la clase Persona, deberíamos plantearnos la misma pregunta: ¿es responsabilidad de esta clase?

Otro ejemplo:

La clase Persona puede tener las siguientes responsabilidades (o métodos):

- EstablecerNombre

- EstablecerApellidos

- Edad

- AsignarPareja

Pero no sería lógico que tuviera una de las siguientes:

- EstablecerCodigoPostal

- CalcularNomina

- AsignarClase

-EnviarRegalo

Si cumplimos este pequeño patrón, obtendremos clases que son fácilmente mantenibles y reutilizables lo cual hará nuestro código y nuestra vida más simples.

Resumiendo: Una entidad debe tener relacionados aquellos datos y responsabilidades que tengan lógica en la vida real. Para saber si un dato o responsabilidad debe ser asignada a una clase, además de consultar patrones tales como Experto en Información, Patrón Creador, etc.. podríamos intentar relacionar el atributo que estamos intentando asignar con el nombre de la clase. Por ejemplo: la relación entre Persona y Demarcación no parece demasiado obvia. Sin embargo la relación entre Jugador y Demarcación ya nos resulta más lógica (Jugador puede ser una clase que deriva de Persona, con lo que ya lo tendríamos todo relacionado).

Y eso es todo! Nos vemos pronto por aquí!

Podemos definir el acoplamiento software como el número de relaciones que una entidad software (una clase, por ejemplo) tiene con otras entidades software o, dicho de otra forma, el número de relaciones fuertes (strong relations) que tiene una clase.
Para aclarar el concepto, fijémosnos en las siguientes figuras:

La primera de ellas nos muestra una clase fuertemente acoplada. Como puede observarse, la clase A tiene relaciones con las clases B, C, D, E y F. En este caso diríamos que la clase A es una clase con un alto acoplamiento.

La segunda imagen nos muestra una clase A con un bajo acoplamiento, ya que tiene muy pocas relaciones fuertes con otras entidades.

Ahora que el concepto de acoplamiento está definido, podemos realizarnos la pregunta de cómo afecta el acoplamiento a nuestro desarrollo software. A la vista de los diagramas mostrados anteriormente queda claro que, si en cualquier momento es necesario modificar alguna funcionalidad de la clase A, en el caso de que se encuentre fuertemente acoplada es más que probable que nos veamos obligados a modificar alguna de las clases con las que se encuentra relacionada, lo que hace que la modificación de la clase sea más dificultosa.
Sin embargo, si nos encontramos en el contexto de la segunda imagen, la modificación de la clase A será, seguro, mucho más simple.
El patrón bajo acoplamiento, bien aplicado, permite que nuestras entidades software sean más mantenibles, extensibles y reutilizables, ya que tienen perfectamente definidas las responsabilidades y eso permite que puedan ser reutilizadas en cualquier otro contexto, siempre que la funcionalidad que se les demande sea la misma.

En definitiva, el patrón bajo acoplamiento nos indica que debemos asignar correctamente las responsabilidades de cada entidad de forma que cada una de éstas tiene asignadas únicamente las responsabilidades que puede llevar a cabo con los datos que ésta tiene disponibles.

Como siempre, espero que os sea de utilidad y os resulte interesante. Hasta Pronto!

Las expresiones lambda pueden considerarse una extensión de los métodos anónimos. Una de las características que más valoran los arquitectos .NET es que una expresión lambda tanto puede ser invocada como utilizada como un dato corriente.
Para implementar expresiones lambda en C# es necesario hacer uso de delegados.
La sintaxi para crear expresiones lambda es la siguiente en C#:

delegate T NombreDelegado<T>(–parametros–);

A bote pronto, esto parece chino. Pero podemos empezar a desgranar esta expresión. En realidad se está declarando un delegado genérico que devolverá como valor un objeto del tipo T que es el mismo tipo que trata en su interior. T puede ser cualquier tipo de objeto. Ejemplo:

delegate T MiFuncion<T>(T x); –> Primero declaramos el delegado que mapea la función.

MiFuncion<int>cuadrado= x =>x*x; –> Especificamos la función lambda.

Podriamos leer la segunda linea como:

Se define una función llamada cuadrado que devolverá un valor entero y que, dado un valor ‘x’ devuelve el valor ‘x’ multiplicado por ‘x’. 

Para nuestro caso, y para el 90% de los casos, será más útil y recomendable utilizar el tipo genérico predefinido Func y cualquiera de sus sobrecargas. De forma que el mismo ejemplo anterior quedaría como:

Func<int> cuadrado = x => x*x;

Podríamos utilizar esta expresión lambda como parámetro de una función, de la misma forma que pasaríamos cualquier otro objeto.

En próximos artículos se explicará cómo utilizar las expresiones lambda para generar arboles de procesado.

Hasta otra!

Normalmente, cuando se acomete la tarea de diseñar una aplicación web, uno intenta reducir el número de páginas a diseñar a la mínima expresión (una página para la autenticación de usuario, otra página con el mapa del site, otra más para la gestión de usuarios, y así hasta obtener un número de páginas que nos permita un mantenimiento relativamente simple de la aplicación, así como para la extensibilidad de la misma). Pues bien, y porqué no crear una aplicación web que sólo disponga de una única página (WebForm)?

Imaginemos la siguiente situación:

Tenemos una página que dispone de un menú horizontal en la parte superior de la pantalla. Este menú nos permite navegar por nuestro site. La imagen muestra el escenario descrito:

Sin tener en cuenta el modelo de interfaz de página unica, podríamos decidir crear un webform para el “Home”, otra para “Manager’s Zone”, una más para “Costumers” y así por cada uno de los items que contiene el menú. Pero el diseño (alternativo, por supuesto) que vamos a proponer sólo dispone de una única página aspx (un único webform). Al hacer click sobre cada uno de los items del menú, lo que haremos es enviar una petición asíncrona para recargar el contenido de el único control que contiene nuestra página, un UpdatePanel. Este UpdatePanel contiene un control PlaceHolder donde iremos substituyendo los controles por aquellos que deban ser mostrados en cada momento. Cabe recordar que para hacer uso de ASP.NET AJAX es necesario incorporar el control ScriptManager a la página, e indicar al control UpdatePanel, cual o cuales serán los disparadores (triggers) que harán que el UpdatePanel se recargue. Para que se vea la propuesta, aquí muestro el diseño en Visual Web Developer:

Nosotros crearemos UserControl’s por cada uno de los items del menú (podríamos añadir los controles necesario para cada item de forma programática, pero hemos decidido utilizar UserControl’s). Asi pues, cuando el usuario seleccione un item del menú, se cargará el UserControl adecuado. Para ello, añadiremos al UpdatePanel un disparador (trigger) que apunte al evento MenuItemClick tal y como muestra esta imagen:

Todos los eventos que se lancen desde el UserControl que se ha cargado en el UpdatePanel, se ejecutarán de forma asíncrona. Esto lleva implícito un problema: Cuando el usuario lanza un evento del UserControl al servidor, evidentemente se ejecuta un Postback en el que se envian todos los datos de la página actual. Cuando ASP recibe la petición lo que hace es cargar los controles que se han especificado en el webForm solicitado (es decir, se cargan los controles de la única página que se ha especificado). Esto significa que los controles que se han cargado dinamicamente (es decir el contenido del PlaceHolder del UpdatePanel, en nuestro caso el UserControl) ASP no los cargará.

Intentaré explicarlo de forma más simple. Cuando ASP recibe una petición por una determinada página (por ejemplo la página Defualt.aspx) ocurre lo siguiente:

- ASP cogerá la página Default.aspx y la utilizará a modo de plantilla, creando en memoria los controles y los tags html que se indican en la misma.

- Después, utilizará los datos del ViewState que llegan en la petición para rellenar los datos y reestablecer el estado de los controles que se han generado en memória.

Así pues, ASP cargará el control PlaceHolder, pero no su contenido. Será responsabilidad nuestra cargar en el PlaceHolder el control que ha lanzado el evento que ha provocado el Postback que se está tratando. Evidentemente cargaremos el control siempre y cuando el Postback no esté provocado por el menú.

Para determinar la procedéncia del PostBack, haremos uso de una propiedad del control ScriptManager (control necesario para hacer uso de ASP.NET AJAX) llamada AsyncPostBackSourceElementID. Esta propiedad nos indicará el Identificador del control que ha lanzado el PostBack. Si el postback proviene del menu, cargaremos en el control UpdatePanel (mejor dicho, en el PlaceHolder que hay en su interior) el UserControl perteneciente al item seleccionado. En caso de que el Postback esté generado por otro control, primero será necesario recargar el UserControl actual con tal de que pueda recargar los datos que le llegan del Postback, y ejecutar los eventos que el usuario haya lanzado. 

A continuación muestro el código que proporciona la funcionalidad que hemos comentado:

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

public partial class _Default : System.Web.UI.Page 
{

    /// <summary>
    /// Constante que identifica el control cargado actualmente en el UpdatePanel
    /// </summary>

    private const string ViewStateControl = “CurrentLoadedControl”;   

    protected void Page_Load(object sender, EventArgs e)
    {

        //Al hacer un load, debemos saber si es por un postback o por que se ha
        //generado la pagina por primera vez. 
        //Si es un postback, es necesario saber si lo ha producido el menu, o alguno
        //de los UserControls que hemos cargado en el UpdatePanel

        if (IsPostBack && !IsAMenuItemPostBack())
        {

            //El postback lo ha producido un usercontrol cargado en el UpdatePanel,
            //por lo tanto, debemos recargar ese control con tal de que le lleguen los 
            //datos de Postback (que estan contenidos en el ViewState) y se pueda atender el 
            //evento que ha generado el PostBack.
 

            Control control = null;

            try
            {
                control = this.LoadControl(ViewState[ViewStateControl] as string);
            }
            catch (Exception)
            {
                throw;
            }

            if (control != null)
            {
                MainPlaceHolder.Controls.Add(control);
            }
        }
    }

    protected void MainMenu_MenuItemClick(object sender, MenuEventArgs e)
    {
        //Si el item seleccionado no es el actual, se debe cargar el UserControl
        //que debe mostrarse en el UpdatePanel.

        string controlToLoad = e.Item.Value+”.aspx“;

        if (ViewState[ViewStateControl] as string != controlToLoad)
        {
            Control control = LoadControl(controlToLoad); 

            if (control != null)
            {
                MainPlaceHolder.Controls.Clear();
                MainPlaceHolder.Controls.Add(control); 

                ViewState[ViewStateControl] = controlToLoad;
            }
        }
    }

    private bool IsAMenuItemPostBack()
    {
        //Miramos si el control que ha generado el Postback es el MainMenu.
        if (MyScriptManager.AsyncPostBackSourceElementID == “MainMenu“)
            return true;
        else
            return false;
    }
}

Queda claro en el código que es necesario dar a la propiedad Value de cada MenuItem el nombre del UserControl que se va a cargar (es una propuesta de funcionamiento. Bien podríamos utilizar una clausula switch o if anidados si se cree conveniente. 

Así es como implementaríamos la interfaz de página única. De esta forma obtendriamos una aplicación totalmente implementada haciendo uso de AJAX, lo que proporcionará una interfaz de usuario más interactiva.

Es evidente que sobre este modelo pueden discutirse la mantenibilidad y extensibilidad (quizás más complejas que en otros modelos), pero no es mi intención vender este modelo como la única ni mejor alternativa, pero si como eso, como una alternativa. No todos los proyectos requieren de un modelo en tres capas, ni de una inversión enorme en el diseño del mismo para que sea fácil su mantenimiento. Evidentemente hay que evaluar las ventajas e inconvenientes de este modelo antes de proponerlo siquiera como solución a algún problema aunque esta práctica debería hacerse con cualquier modelo y/o paradigma. Y digo esto último porque pocas veces alguien se atreve a cuestionar que utilizar el paradigma de la programación orientada a objetos sea el conveniente para un proyecto concreto (cuando es una de las primeras cuestiones que deberíamos plantearnos). Hay alternativas a este paradigma que nos pueden facilitar el desarrollo de un proyecto (paradigma de programación guiada por eventos, programación secuencial, programación funcional, programación basada en políticas, y muchos otros paradigmas).

Como siempre, espero que os resulte interesante este artículo. Espero vuestros comentarios!!!

Gracias!!

Hay que tener presente que para implementar métodos parciales es necesario implementar clases parciales. 
Como hemos comentado, los métodos parciales nos permiten hacer referencia a un método que todavía no ha sido implementado. Imaginemos que trabajamos en un equipo de desarrollo. Es responsabilidad nuestra implementar un método tal como este:

public double RealizarContabilidad(guid referenciaExpediente)

Los demás desarrolladores necesitan poder hacer la llamada a éste método con tal de dejar acabada sus respectivos módulos. Si implementamos los métodos parciales, los demás desarrolladores pueden acabar sus módulos y continuar con sus desarrollos y nosotros retrasar la implementación lo necesario.  

Entremos en materia. Para declarar un método parcial utilizaremos la siguiente sintaxis:

 modificador_acceso partial tipo_retorno nombre_método(parámetros);

Ejemplo:

public partial double RealizarContabilidad(guid referenciaExpediente);

Ahora podríamos hacer lo siguiente:

C#
 public partial class PartialClassSample
 {
   
   //Declaración del método parcial
   partial double RealizarContabilidad(guid referenciaExpediente);

   public void DoSomething()
   {
     ...
     RealizarContabilidad(Guid.NewGuid()); //Usamos el método pese a no estar implementado
                   
   }

 }

VB.NET
 Partial Public Class PartialClassSample

   Partial Private Sub RealizarContabilidad(ByVal referenciaExpediente As Guid)
   End Sub

  Public Function DoSomething() As Double
    ...
    RealizarContabilidad(Guid.NewGuid()) ' Usamos el método parcial
  End Sub

 End Class

Ahora deberíamos implementar el método tal que así:

C#

 public partial class PartialClassSample
 {
   partial double RealizarContabilidad(guid referenciaExpediente)
   {
     return 20.0f;
   }
 }

VB.Net
 Partial Public Class PartialClassSample
   Private Fucntion RealizarContabilidad(ByVal referenciaExp As Guid)As Double
     Return 20.0
   End Sub
 End Class

Cuando el compilador encuentra una llamada a un método parcial, busca en cada una de las partes de la clase para encontrar la implementación del mismo.
Si la encuentra, la utiliza, Sino, ignora cualquier llamada al método en
concreto. 

Espero que os sea útil. Un saludo!  

Cuando desarrollamos aplicaciones web, podríamos afirmar que en la mayoría de casos la arquitectura que se acaba implementado es una arquitectura en dos capas (Cliente – Servidor) cómo la que se muestra en la imagen:

Arquitectura en dos capas

Ésta arquitectura lleva implícito un riesgo si utilizamos AJAX en el cliente: el front-end accederá al back-end haciendo uso de los servicios que éste último publica mediante una interfaz o API. El riesgo consiste en que estos servicios son públicos (sino no podríamos acceder a ellos mediante AJAX o Silverlight), es decir, que están abiertos a cualquiera que quiera hacer uso de ellos (sea mediante nuestro cliente o a través de cualquier otro canal). El caso más habitual es el uso de WebServices en la parte back-end. Estos servicios web són incapaces, por si mismos, de diferenciar si la llamada está siendo efectuada por un cliente propio o por un agente externo (y probablemente con intenciones maliciosas) ya que lo único que el cliente hace es llamar una URL con un conjunto de parámetros y recibir la respuesta del servicio. 

Cualquier barrera que planteáramos poner en este nivel (firewalls, por ejemplo) privaría de acceder al servicio tanto a propios como ajenos, por lo que nadie podría acceder al mismo.

Si no se hiciera uso de AJAX, esto no sería un problema, puesto que la llamada al servicio se realizaría desde el propio Servidor, y esta ya se encuentra controlada ya que el servidor ya se encarga de comprobar que el usuario que realiza la petición se encuentre autenticado y esté autorizado (ASP.NET Authentication).

En caso de utilizar AJAX, sería necesario implementar esta comprobación por nosotros mismos.

Actualmente se ha aceptado como diseño de arquitectura, colocar una capa llamada Capa de servicios (o Service layer) que es la capa a la que accede el front-end (AJAX en este caso) y que se encarga de gestionar todos los pasos necesarios para generar la respuesta esperada por el cliente (la capa de servicios se encarga de acceder a los servicios, objetos de negocio o de ejecutar workflows (flujos de trabajo) con tal de obtener una respuesta correcta). Aun así, esta capa no nos proporciona la seguridad esperada si accedemos a ella mediante AJAX o Silverlight (es decir, de forma asíncrona) ya que sigue siendo imposible determinar si la llamada proviene de un cliente autorizado o de un cliente que no lo está.

La solución que se propone es añadir una capa intermedia, entre el front-end y la capa de Servicios, con tal de que esta quede protegida. Esta capa se denomina AJAX Service Layer (o capa de servicios AJAX) y es la capa a la que se conecta el front-end y la encargada de comprobar que éstos dispongan de los permisos adecuados para poder acceder a dicho servicio. Para hacernos una idea, la arquitectura propuesta es la siguiente:

Capa de servicios

Arquitectura con AJAX Service Layer

Pero vayamos paso a paso:

Con tal de implementar seguridad en aplicaciones que utilicen Silverlight o AJAX, se propone utilizar, tal y como se ha comentado, una capa intermedia, llamada Capa de Servicios AJAX (AJAX Service Layer). Las aplicaciones cliente (entiéndase AJAX o Silverlight) deberán realizar cualquier petición a la capa de servicios AJAX (ya que la situaremos entre el front-end y la capa de servicios (Service Layer). 

La responsabilidad de la capa de servicios AJAX es comprobar si la llamada que esta recibiendo proviene de un cliente autorizado o no. Si la comprobación resulta afirmativa, lo que se hará es llamar al correspondiente servicio de la capa de servicios (Service Layer) con tal de devolver la respuesta esperada. En caso negativo, se lanzará un error.

¿Y cómo determinará la capa de servicios AJAX si la llamada proviene de un cliente autorizado? Pues muy simple: comprobaremos que el usuario esté autenticado. ¿Cómo? una llamada AJAX hace un Postback del estado actual de la aplicación. Entre los datos que recibimos estará la Cookie de Autenticación. Podremos, así pues, comprobar que el usuario esté autenticado. 

Obviamente, para ello deberemos hacer pasar al usuario por un proceso de autenticación y autorización previamente a la utilización de aquellos servicios que requieran la autenticación del usuario por motivos de seguridad. No está de más recordar como se configura la autenticación y autorización de usuarios. En el archivo web.config podremos especificar la autorización de un grupo de usuarios creando una entrada como la siguiente:

<location path="MembersOnly">
    <system.web>
        <authorization>
            <deny users="?" />
        </authorization>
    </system.web>
</location>

Para especificar el modo de autenticación (Forms, Windows Integrated, Passport,etc..) se puede crear una entrada tal que esta:

<authentication mode="Forms">
    <forms loginUrl="MembersOnly/login.aspx">
    </forms>
</authentication>

Y eso es todo. Si tenéis cualquier duda o propuesta de mejora para esta solución, no dudéis en dejarla patente en forma de comentario. La discusión y el debate nos harán a todos mejores programadores.

Hasta pronto!:)

El concepto de ensamblado amigo nos indica que un ensamblado podrá compartir sus miembros Friend / Internal con otros ensamblados determinados (es decir, que tenemos que especificar explícitamente).
Esto podremos conseguirlo haciendo uso del Atributo:

<InternalsVisibleTo( … )>    o    [InternalsVisibleTo( ...)] 

En principio, cuando declaramos los miembros de un assembly (ya sean clases, o los miembros de las propias clases) como Friend o Internal, estos sólo son accesibles desde el propio assembly (cabe recordar que si no se especifica el modificador de acceso, VB.NET establece como modificador de acceso por defecto Friend, mientras que C# establece Internal, lo que conceptualmente es exactamente lo mismo). Si decidimos que éstos miembros deben ser visibles sólo para ciertos assemblies, entonces podemos decantarnos por dos opciones:

- Declaramos los miembros a compartir como Protected Friend o Internal Protected (lo cual nos obliga a que todos los miembros del assembly (sea cual sea) que contengan objetos que derivan de los miembros a compartir puedan acceder a dichos miembros.

- Usamos los ensamblados amigos.

Si nos decantamos por la segunda opción, podremos especificar los assemblies con acceso a los miembros Friend o Internal del assembly actual utilizando el atributo <InternalsVisibleTo()> en el archivo AssemblyInfo del siguiente modo:

<Assembly: InternalsVisibleTo("Ensamblado_amigo, PublicKey=llave pública")> 

[assembly: InternalsVisibleTo("Ensamblado_amigo, PublicKey=llave pública")]

Para poder usar este atributo, es necesario hacer referencia al espacio de nombres System.Runtime.CompilerServices;

Una vez hecho esto, ya podremos utilizar los miembros Friend o Internal en los ensamblados especificados. Se pueden especificar ensamblados amigos en VB.NET 8.0 o superior y en C# 2.0 o superior, pero sólo pueden consumirse en C#2.0 o superior y en VB.NET 9.0.

Y eso es todo. Otra cuestión muy diferente es si el uso de ensamblados amigos rompe con algunas de las bases de la POO, pero eso es otro cantar! Hasta Pronto!

Un poco de historia para contextualizar esta característica:

Como todos sabemos, un delegado no es sino un puntero que hace referencia a una dirección de memoria que contiene la firma de un método (y el método en sí). En versiones anteriores (podríamos ir directamente al lenguaje C++ para comprobar esto) la firma del método era fuerte (strong). Eso quiere decir que el método espero un numero determinado de parámetros y espera que cada uno de éstos parámetros sea de un tipo específico y, finalmente, devolverá un objeto de un tipo concreto (o no devolverá nada). Ejemplo:

Public Sub DoSomething(ByVal Param1 As String, ByVal Param2 As StringDictionary)

Los delegados nacieron como una via para envolver la firma de un método, de forma que se podía comprobar, antes de llamar a un método, que a éste se le pasaban los parámetros adecuados (tanto en número como en tipos). 

Imaginemos la siguiente situación:

Como es bien sabido, todos los tipos de objetos del .NET Framework derivan de la clase Object . Imaginemos, pues, que, haciendo uso de la OO, decidimos realizar la siguiente operación:

Imports System.Runtime.CompilerServices
Imports System.Collections.Specialized

Public Class TryRelaxedDelegates

    Private Delegate Sub DoSomething(ByVal Param1 As String, ByVal Param2 As StringDictionary)

    Public Sub ProbarDelegado()
        Dim delegado As New DoSomething(AddressOf HacerAlgo)
        delegado(New Object, New Object)
    End Sub

    Private Sub HacerAlgo(ByVal str As String, ByVal strdic As StringDictionary)

        Console.WriteLine(“OK!”)

    End Sub

End Class

¿qué ocurrirá? Pues la verdad es que la respuesta, a dia de hoy, será: Depende

- Si utilizamos una versión de C# (entendiendo que el código anterior debería traducirse a C#) anterior a la versión 2.0 o utilizamos VB.NET 8.0 o anterior, esta operación nos dará un error de compilación, puesto que los parámetros que le hemos pasado a la función no se corresponden con la firma del delegado y, por lo tanto, se producirá un error de compilación.

- Sin embargo, si utilizamos C# 2.0 o posterior o bien Vb.NET 9.0, esta operación (la mostrada en el código, dónde estamos pasando Object’s en vez de objetos con el tipo esperado) está permitida. Esto es gracias a la relajación de delegados . Ahora se habilita la posibilidad de utilizar, no solo lo objetos que indica la firma del método, sino también todos aquellos que estén dentro de la misma herencia de clases (contravarianza). Así pues, imaginemos que tenemos la siguiente estructura de clases:

Gracias a la relajación de delegados, podríamos declarar un delegado que apuntara al siguiente método:

Public Function ObtenerNombreDoctor(ByVal Doctor As Doctor) As String

y llamarlo de las siguientes formas:

Dim doc As New Doctor (“Román”)
Dim per As New Persona (“Alberto”)
Dim obj As Object 

 - ObtenerNombreDoctor(doc) –> Funciona, ya que cumple con la firma del método
 - ObtenerNombreDoctor(per) –> Funciona, gracias a la relajación de delegados y a la contravarianza
 - ObtenerNombreDoctor(obj) –> Lo mismo que en el caso anterior
 - ObtenerNombreDoctor() –> También funciona (en VB.NET) ya que la relajación llega al extremo de no tener que indicar ningún parámetro. 

Pues bien, eso es todo en cuanto a la relajación de delegados (Relaxed delegates). Como siempre, espero volver a veros por aquí!

Nada mejor que un poco de código para comprender mejor lo explicado.

VB.NET:

Existen diferencias sintácticas entre los dos lenguajes que tratamos en este blog asiduamente (VB.NET y C#) con respecto a los tipos anónimos.
Para declarar un tipo anónimo en VB.NET se hace uso de la palabra reservada With, tal y como se muestra en la siguiente imagen:

Figura 1: Declaración de un tipo anónimo en VB.NET. Observar como el compilador detecta las propiedades declaradas.

Tal y como puede observarse en la imagen, el compilador ya detecta las propiedades que tiene el nuevo tipo de objetos y que hemos especificado en la declaración (inline) de la propia variable. 
Cabe destacar el uso necesario de la palabra reservada With para especificar que se está declarando un tipo anónimo, así como el uso del punto para especificar el inicio de la declaración de un atributo del tipo en i.  

C#:

A continuación se muestra el mismo ejemplo pero utilizando C# como lenguaje de programación. A destacar las diferencias en la sintaxis. No es necesario hacer uso de la palabra reservada With y tampoco es necesario comenzar los nombres de los atributos con un  punto:

Figura 2: Aquí también puede apreciarse como el compilador detecta las propiedades del objeto que se ha declarado inline en la línea anterior

Nótese como se hace uso de la palabra reservada var, ya que en éste ejemplo también hay implícito el uso de la inferéncia de tipos.

En el caso de VB.NET, será necesario tener activada la opción Option Infer On con tal de que este ejemplo compile correctamente.

Pero, ¿cómo actúa el compilador para conseguir éste resultado? ¿Cada vez que declaro un tipo anónimo se crea un nuevo tipo interno?
Son buenas preguntas con respuestas simples:
- Cuando declaramos un tipo anónimo, el compilador actúa creando un tipo interno exactamente igual que si nosotros lo hubiéramos creado de forma explícita, es decir, creando una clase (directamente en código MSIL) con un nombre del tipo <proyección>f__0.

- Los tipos anónimos están tipados, por lo que, si nosotros declaramos otra variable del tipo anónimo utilizando la misma sintaxis que en los ejemplos, el compilador no crearía otro tipo de datos, sino que instanciaría un nuevo objeto haciendo uso del tipo antes declarado. En cambio, si cambiamos el orden en el que definimos los atributos (por ejemplo, primero indicamos los Apellidos y luego el Nombre, el compilador lo interpretará como un nuevo tipo de datos y creará, de forma interna, otro tipo de datos distinto.

Para finalizar, sólo cabe mencionar que los tipos anónimos son de contexto local, por lo que si pasamos como parámetro un tipo anónimo a otro assembly, éste no podrá determinar el tipo a menos que hagamos uso de la Reflexión (Reflection).

Y eso es todo por el momento. Espero que esta información os resulte interesante y os sea útil. Hasta pronto!

Una de las nuevas características que incorporan éstos lenguajes es la inferencia de tipos. Para entender este nuevo concepto, creo que es mejor empezar con un ejemplo práctico:

VB.NET:

Partamos del siguiente código

Dim i=new ArrayList()     –> Notar que se ha omitido la especificación del tipo (As XXXX)

Uno espera que el comportamiento del compilador sea tratar la variable i como un
ArrayList, pero si comprobamos con IntelliSense la variable veremos que el
compilador la trata como un Object. La inferencia de datos soluciona este problema. 
Si activamos la opción  Option Strict On, el compilador no dará un error en la sentencia anterior, puesto que no hemos indicado el tipo de la variable declarada, i los tipos no son convertibles de forma implícita.

Es muy recomendable programar con la opción Option Strict activada puesto que nos impedirá generar este tipo de código.

Si activamos la opción Option Infer On podremos introducir el siguiente código:

Option Infer On
Dim i = new ArrayList()

El compilador, ahora es capaz de inferir el tipo del objeto i, reconociendo a éste como un objeto del tipo ArrayList. 

Más ejemplos de Inferencia de tipos:

Option Strict y Option Infer = Off (El compilador trata la variable i como Object, no como ArrayList)

Option Strict On (no nos permite este tipo de declaraciones, ya que los tipos no se pueden convertir de forma implícita)

Con Option Strict y Option Infer On, la inferencia de tipos funciona correctamente

Para activar las opciones Option Strict y/o Option Infer (o bien deshabilitarlas) para todo nuestro proyecto, podemos hacerlo accediendo a las propiedades del proyecto y modificándolo en la pestaña de Compilación:

Activando las Options en las propiedades del proyecto, evitaremos tener que declararlas en cada uno de nuestros archivos fuente

C#:

La inferencia de tipos en C# se puede implementar haciendo uso de la palabra reservada var. La sintaxis para declarar una variable haciendo uso de la inferencia de tipos seria así:

var i=new ArrayList();

Ahora la variable i es del tipo ArrayList, pese a que en ningún momento hemos declarado su tipo, tal y como se demuestra en la siguiente imagen:

Y eso es todo en cuanto a la inferencia de tipos. Espero que os sea útil en vuestro trabajo diario!