Enterprise Library, descripción general

Hola,
Iba a comenzar un especial sobre Enterprise Library, pero al realizar un análisis de mercado al respecto me he encontrado una web que explica cada uno de los Application Blocks estupendamente, así­ que me voy a limitar a incorporar el link al grupo de artí­culos 😉
Viva la reutilización de componentes.
http://rmottap.blogspot.com.es/2009/07/enterprise-library.html
Un saludo.
Miguel.

Compartir sesión de ASP.NET con un servicio WCF

Hola,
No soy muy amigo de hacer cosas como estas, ya que normalmente considero mejor el separar los servicios WCF en una aplicación diferente.
A pesar de ello, si alguien está interesado, o como mera curiosidad, el artí­culo es interesante.
http://blogs.msdn.com/b/wenlong/archive/2010/02/21/using-asp-net-sessions-from-wcf.aspx
Un saludo.
Miguel.

ASP.NET Merge

Hola,
Alguna vez has necesitado compilar tu proyecto de tipo web site en una dll?
Pues puedes hacerlo mediante la instrucción aspnet_merge lanzado desde la consola de comandos de Visual Studio.
El proceso es sencillo:
1) Precompilar tu sitio web mediante la publicación estándar de un proyecto de tipo web site
2) Una vez precompilado, abrir la consola de comandos de Visual Studio y lanzar la instrucció “aspnet_merge rutaaplicacion -o”
Al entrar en la carpeta bin del sitio que previamente habéis precompilado, veréis que las diferentes dll que habí­a en un inicio se han quedado en solo una.
Aquí­ tenéis la referencia de la MSDN al respecto del comando:
http://msdn.microsoft.com/es-es/library/bb397866%28v=vs.100%29.aspx
Adicionalmente un estupendo video explicativo que describe todo el proceso, y en general el funcionamiento del procesado asociado a la precompilación; muy interesante en general
http://www.asp.net/web-forms/videos/how-do-i/how-do-i-use-the-aspnet_mergeexe-utility-to-merge-assemblies
Un saludo.
Miguel.

El antes y el después de LINQ

Problema: a partir de una lista de objetos de tipo “Coche”, quiero sumar el precio de cada uno de ellos agrupado por marca.
La clase coche tiene la siguiente forma
public class Coche
{
  public int IdCoche { get; set; }
  public string Matricula { get; set; }
  public int IdMarca { get; set; }
  public int NumeroPuertas { get; set; }
  public int Precio { get; set; }
  public Coche(int idCoche, string matricula, int idMarca, int numeroPuertas, int precio)
  {
     this.IdCoche = idCoche;
     this.Matricula = matricula;
     this.IdMarca = idMarca;
     this.NumeroPuertas = numeroPuertas;
     this.Precio = precio;
   }
}
Inicializamos una lista con objetos de la clase  Coche
List<Coche> lista = new List<Coche>();
lista.Add(new Coche(1, “3322-AAA”, 1, 3, 15000));
lista.Add(new Coche(2, “3322-EEE”, 2, 5, 25000));
lista.Add(new Coche(3, “3322-III”, 3, 3, 35000));
lista.Add(new Coche(4, “3322-OOO”, 1, 3, 18000));
lista.Add(new Coche(5, “3322-UUU”, 2, 5, 20000));
lista.Add(new Coche(6, “1111-AAA”, 3, 3, 150000));
lista.Add(new Coche(7, “1111-EEE”, 1, 3, 30000));
lista.Add(new Coche(8, “1111-III”, 1, 5, 28000));
lista.Add(new Coche(9, “1111-OOO”, 3, 5, 16000));
lista.Add(new Coche(10, “1111-UUU”, 1, 5, 9000));
Solución antes de LINQ (una de muchas)
Hashtable hash = new Hashtable();
foreach (Coche c in lista)
{
  if (!hash.ContainsKey(c.IdMarca))
  {
    hash.Add(c.IdMarca, c.Precio);
  }
  else
  {
    hash[c.IdMarca] = (int)hash[c.IdMarca] + c.Precio;
  }
}
IDictionaryEnumerator _enumerator = hash.GetEnumerator();
while (_enumerator.MoveNext())
{
  Console.WriteLine(String.Format(“Marca: {0}, Total Precio: {1}”, _enumerator.Key, _enumerator.Value));
}
Solución después de LINQ
var marcas = from m in lista
             group m by m.IdMarca into g
             select new { IdMarca = g.Key , TotalPorMarca = g.Sum (m => m.Precio) };
foreach (var marca in marcas)
{
  Console.WriteLine(String.Format(“Marca: {0}, Total Precio: {1}”, marca.IdMarca, marca.TotalPorMarca));
}
Resultado
Marca: 1, Total Precio: 100000
Marca: 2, Total Precio: 45000
Marca: 3, Total Precio: 201000
Saludos.

Variables de Sesión en Memoria, Balanceos y Alta Disponibilidad

Una de las herramientas más comunes a la hora de trabajar con aplicaciones web son las variables de sesión.
Dejando de lado en este capí­tulo las recomendaciones de arquitectura en el uso de las sesiones, simplemente plantear una solución a uno de los tí­picos problemas que se encuentran los arquitectos de software a la hora de definir el uso de sesiones, que son las limitaciones al uso relacionadas a entornos donde se cuente con una infraestructura que ofrezca alta disponibilidad cuando estamos trabajando con variables de sesión almacenadas en la memoria del servidor.
Para solucionar este problema, existen productos disponibles en el mercado, que lo que hacen es mantener también balanceado el contenido de la sesión de todos los servidores existentes en una granja, por lo que, aunque un usuario a medida que va lanzando peticiones, el balanceador lo vaya dirigiendo a servidores diferentes, podrá seguir trabajando con la información de sesión que haya generado, en memoria, en un servidor diferente.
Os dejo el link a uno de los productos que solventa este problema en entornos .NET: NCache
http://www.alachisoft.com/ncache/
Saludos.
Miguel.

Consideraciones de Arquitectura respecto al uso de Variables de Sesión

A continuación paso a enumera una serie de consideraciones a tener en cuenta y que os pueden ser íºtiles a la hora de tomar ciertas decisiones de arquitectura al respecto del uso de variables de sesión. Como veréis algunas de ellas tienen que ver con entornos .NET, ya que es la plataforma con la que suelo trabajar, pero la mayorí­a son aplicables a otros entornos tecnológicos no Microsoft.
Sesión en Memoria vs Sesión en Sistemas Persistidos (Base de Datos o Servicios del Sistema Operativo)

La forma más eficiente de trabajar con sesiones es manteniendo su contenido en memoria. En el caso de estar trabajando con una granja de servidores, pueden utilizarse soluciones existentes en el mercado como es NCache, para balancear el contenido de las sesiones en memoria entre todos los servidores de la granja.
En caso de no poder barajar esta alternativa existen soluciones que permiten almacenar el contenido de la sesión sobre sistemas persistidos. Esta solución es más lenta, pero permite compartir la información de sesión sobre diferentes servidores, además de garantizar que aunque se reinicie el servidor de aplicaciones, la información de sesión va a permanecer disponible cuando la aplicación vuelva a arrancarse.
Cantidad de Memoria en Uso
El uso de sesión afecta directamente al consumo de memoria del servidor que está ejecutando las llamadas del cliente, por lo que deberá almacenarse en sesión íºnicamente la información que se considera imprescindible y que, se recomienda, esté relacionada con alguna de las siguientes caracterí­sticas:

  • Información básica relacionada con la autenticación o la seguridad del usuario y que es necesario comprobar en las llamadas o peticiones que realiza el usuario contra la aplicación.
  • Otro tipo de información funcional asociada al usuario, que va a permanecer estática a lo largo de toda la vida de la sesión y que es requerida de forma constante en las peticiones que realiza el usuario a la aplicación. El objetivo de este punto serí­a minimizar el níºmero de llamadas a base de datos.

Tipos de Objetos en Memoria
Los objetos almacenados en la sesión deben ser en todo caso de poco peso, minimizando así­ la cantidad de información almacenada por sesión por cada objeto. Se recomienda el uso de objetos de negocio que incluyan tipos de datos básicos. No se recomienda el almacenamiento de objetos propietarios de .NET del tipo Dataset ó DataTable debido al tamaño asociado a los mismos.
Manejando Información Sensible
Si el contenido almacenado en la sesión contiene información sensible, como podrí­an ser contraseñas o información personal del usuario activo, ésta deberá permanecer encriptada durante todo el ciclo de vida de la sesión.
Usando Sesión a modo de Caché
No debe emplearse la sesión para almacenar catálogos de datos comunes de la aplicación, como podrí­an ser listados de paí­ses, regiones, provincias, etc, ya que éste no es el objetivo de  este tipo de objeto. Para estos casos se deberá recurrir a un objeto de tipo caché.
Usando Sesión a modo de Viewstate (especí­fico .NET)
No se recomienda emplear la sesión para almacenar información que será necesaria explotar entre llamadas a la misma página, ya que para ello existe un objeto preparado especí­ficamente para resolver esta problemática como es el Viewstate de ASP.NET.
Usando Sesión a modo de POST y GET
No debe emplearse la sesión para transportar información entre páginas de la misma aplicación, ya que para ello se deberá recurrir a los objetos POST y GET.
Liberando Información de Sesión
Siempre y cuando se detecte que la información almacenada en sesión deje de ser necesaria para la sesión de usuario actual, se debe solicitar la liberación de la memoria asociada al servidor.
Saludos.
Miguel.

ASP.NET Report Viewer y Reserved.ReportViewerWebControl.axd

Hace unos dí­as se incorporó un artí­culo muy similar que hablaba de problemas de autorización de recursos al utilizar AjaxControlToolkit.
Hoy solventamos un problema muy similar, cuando estamos utilizando el control de ASP.NET Report Viewer en una aplicación que utiliza la seguridad de ASP.NET
En este caso el location que deberéis añadir es el siguiente:
<location path=”Reserved.ReportViewerWebControl.axd”>
<authorization>
<allow users =”*” />
</authorization>
</location>
Saludos.
Miguel.

Pruebas Unitarias con Visual Studio 2008

Os dejo un link donde se muestra un pequeño manual donde se describen las principales funcionalidades incluidas en los proyectos de pruebas unitarias incluidos en Visual Studio 2008.
En el artí­culo se describen los siguientes puntos:
* Crear un Test
* Ejecutar un Test
* Crear un Test Ordenado
* Debuggear un Test
* Soporte de test para aplicaciones ASP.NET
http://www.geekzone.co.nz/vs2008/4819
Saludos.
Miguel.