Ingeniería de Software, Gestión de Proyectos, Programación, BPM, Arquitectura de Software, .NET, J2EE
¿Quién no ha necesitado trabajar con gráficas en sus aplicaciones de escritorio o web?
Microsoft Chart Controls se presenta como una opción gratuita disponible en aplicaciones web y escritorio, para cubrir esta demanda; el paquete MS-Chart fue incluido en el Framework desde la v3.5 SP1.
Un saludo.
Miguel.
Abierto ayer el capítulo de LINQ, incorporo una interesante referencia extraida del MSN
Saludos.
Miguel
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.
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.
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:
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.
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.
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.
Recientemente, en uno de los comentarios añadidos al post Mejorando Nuestros DAO y DTO, se ha tratado el uso del método Find en listas genéricas.
Dejo a vuestra disposición dos artículos que marcan sendos ejemplos de uso. Resulta una práctica que puede seros interesante en vuestros desarrollos.
Saludos y gracias a Ignacio por el apunte.
Miguel.
AjaxControlToolkit es el conjunto de controles web ajax provistos por el propio Microsoft y totalmente compatibles con Visual Studio 2008 y Framework 3.5 de .NET.
Hoy hablaremos brevemente cómo resolver la problemática que nos podemos encontrar si combinamos el uso de dicho Toolkit con la seguridad básica de ASP.NET.
Ante claúsulas como la descrita en la parte inferior:
<authorization>
<deny users=”*” />
</authorization>
estamos denegando el acceso a cualquiera de los recursos de la aplicación, a todos los usuarios que no cuenten con cierto tipo de autenticación. Cuando hablamos de recursos estamos hablando de recursos de cualquier tipo, entre los cuales estamos incorporando páginas aspx, javascript, imágenes, hojas de estilo, themes…
Para resolver el acceso total a recursos necesarios a nivel de aplicación como por ejemplo hojas de estilo, imágenes y javascript podemos combiar el anterior tag con el siguiente:
<location path=”images”>
<authorization>
<allow users =”*” />
</authorization>
</location>
donde podemos apreciar cómo para todos los usuarios estamos dando acceso a la carpeta donde estamos almacenando las imágenes. Si no hiciéramos esto, las páginas aspx se cargarían, pero no podríamos ver las imágenes que tuviéramos contenidas.
Algo muy similar pasa cuando utilizamos Ajax Control Toolkit, vamos a necesitar indicar la visibilidad de sus recursos a los usuarios para que puedan ejecutar los controles ajax, tanto la funcionalidad javascript que incorporan como sus imágenes y estilos relacionados. Para ello, no tenemos que dar permisos a una carpeta concreta, si no a un fichero que no es visible en tiempo de diseño, pero que sí podremos observar si lanzamos la aplicación. Se trata del archivo WebResource.axd.
Añadiendo el nuevo location
<location path=”WebResource.axd”>
<authorization>
<allow users =”*” />
</authorization>
</location>
conseguiremos nuestro objetivo. Nuestros controles ajax volverán a funcionar correctamente, veremos las imágenes relacionadas a los controles, así como sus estilos.
Saludos.
Miguel.
Es curioso el siguiente nuevo mecanismo que aparece en el .NET Framework 3.5,
namespace MetodosExtension
{
public static class MisExtensiones
{
public static bool ContieneLaZ(this String str)
{
//Código que a partir de un string retorna verdadero
//si éste contiene la letra ‘Z’
}
}
}
Que luego te deja hacer cosas como esta;
string variable = “escuché un zumbido”;
if (variable.ContieneLaZ())
{
}
A esta nueva facilidad que incluye el entorno de desarrollo se le llaman extensiones. Como podréis apreciar lo que se ha hecho es definir en una clase separada un nuevo método asociado a un objeto (String) que el propio framework de .NET trae consigo. La magia para conseguir esto último reside en la forma en la que se define el parámetro del método “ContieneLaZ”, que como véis utiliza el identificador “this” previo a la definición de la variable y el tipo.
La principal gracia de todo esto es la capacidad de poder dotar de más potencia a clases ya definidas sin necesidad de utilizar tipos derivados y sin modificar el tipo original.
Apuntar además que las extensiones se mantienen también cuando heredamos la clase original sobre la que se ha hecho la extensión. Por ejemplo, si extendemos la clase “Coche” con nuevas operaciones, y luego creamos una clase “CocheVolador”, esta última, también podrá contar con las extensiones definidas en su clase padre.
Saludos.
Miguel.