Sobre las Colecciones en .NET


¿Quien no ha utilizado un lista en algún desarrollo?, he visto como algunos desarrolladores (algunos novatos y otros no tanto) odian los famosos Arrays o arreglos y ven en la Lista (List<T>) un excelente compañero, pero quizás algunos consciente o inconscientemente obvian que detrás de esa dinámica lista en memoria sigue existiendo un Array como el de toda la vida… (¿Te acuerdas de VB 6.0?), pues si, a algunos les parecerá un hecho desastroso, otros quizás lo intuían, el objetivo de este post es profundizar en la razón de ser de esto.

Básicamente el tipo List no es más que un buen administrador de un arreglo común y corriente, y que si de tener cuidado se trata deberás tener el mismo que con los Arrays.

¿Como lo administra entonces?

Básicamente el Tipo List<T> contiene un arreglo del tipo definido es decir:

List<T> lista = new List<T>();
T[] arreglo = new T[];

Ambos son prácticamente iguales.

De hecho el tipo List internamente tiene un campo de Tipo T[] llamado _items, y otro llamado _emptyArray, el primero es la versión actual de la lista que estamos manejando y es este el que se re-dimensiona (crea y descarta) cuando hacemos uso de los metodos Add, AddRange, Remove, Clear, etc…

Un hecho muy importante es que esta re-dimensión se realiza con cierta lógica y este es el punto mas importante, predeterminadamente las lista si no se especifica una capacidad en el constructor, se crea con cero items y su array interno esta totalmente vacío.

T[] _items;
T[] _emptyArray = new T[];

//Constructor sin parámetros del tipo List<T>
public List()
{
   _items = _emptyArray;
}

Cuando agregamos el primer ítem (Invocamos al método Add(item); ) este se re-dimensiona a 4 ítems, es decir, olvida el arreglo anterior (vacío) y crea un nuevo arreglo con 4 ítems, asignando al primero de ellos el elemento que estamos agregando, luego de esto, las siguientes 3 inserciones con el método Add no modificarán el tamaño del arreglo (_items), para la quinta invocación del método Add, este crecerá el arreglo al doble del tamaño establecido (8 items) copiando los ítems ya asignados mas el ítem agregado dejando las últimas posiciones (3 items) vacías, repitiéndose este ciclo hasta que se llegue al limite de ítems permitidos.

Este límite es impuesto principalmente por uncampo interno de la clase Array asi:

internal const int MaxArrayLength = 0X7FEFFFFF;
/*Este valor correspondería a un
 entero de 2146435071, es decir
 unas 2GB de elementos.*/

¡Nota Importante!

 

  • Si tienes alguna idea de cuantos items podrá tener la lista a crear, es bueno que invoques la sobrecarga del constructor que pide como parámetro la capacidad inicial de la lista, esto evitará una re-dimensión innecesaria y constante del array interno, pero ten cuidado una capacidad sobre dimensionada podría saturar la memoria RAM.

Hasta aquí este post.

Juan Lombana

Anuncios

La Potencia de Windows Azure


Ya se ha hablado bastante de Windows Azure en toda la red; y para aquellos que aún no estén enterados de que se trata les recomiendo la lectura de los siguientes artículos:

El objetivo de este articulo (y de otros que vendrán…) es poner en contexto esta tecnología en el mundo de las aplicaciones actuales y adentrarnos técnicamente en ciertas características.

Componentes de Windows Azure

¡La Potencia de Windows Azure!

Windows Azure como vemos en la imagen superior cuenta con una gran cantidad de componentes, los cuales podemos utilizar para mejorar en todos los aspectos (Técnicos y económicos) nuestra aplicación.

Es un buen comienzo para este tema entonces imaginarnos que clase de aplicaciones podemos implementar en Windows Azure y como sería la mejor forma de lograrlo.

Migrar una aplicación web existente: En este escenario simplemente constaría de trasladar la aplicación web que ya tienes desarrollada a las instancias de computo de Windows Azure; esto es un buen comienzo, te permite conocer la consola administrativa y empezar a ambientarte con el tema de los costos; (ya veo venir la pregunta del millón) ¿Que ventajas tiene este escenario? La primera ventaja sería el tema del despliegue y esto se ve enmarcado en la tecnología que utilizas para desarrollar tu aplicación web actual, supondremos un escenario “benigno” y es suponer que esta hecha sobre ASP.NET ó Silverlight, tecnologías que trabajarías en Visual Studio 2010, allí el tema del despliegue a Windows Azure ya se encuentra bastante automatizado y después de un par de click’s de configuración subir la aplicación al Windows Azure es bastante sencillo…, además pasamos por este tema sin mencionar que también se cuenta con un ambiente de desarrollo bastante bueno, que emula el storage y el computo, familiarizándote con el entorno “real”; el tema de los costos también es un punto a favor, pues las estrategias de computo elástico que puedes adoptar para tu aplicación te permitirán ofrecer el mejor servicio con el costo mas ajustado.

Azurificar” la aplicación existente: Cuando ya tenemos nuestra aplicación ejecutándose en un entorno de computo de Windows Azure es bueno empezar a “Azurificarla”, y este termino (rebuscadisimo) refiere concretamente a empezar a aprovechar las características de Windows Azure para nuestra aplicación como los son: Service Bus, Access Control, Cache Service, Storage, Worker Roles.

Una de las razones que nos puede llevar a empezar esta “Azurificación” es intentar tener varias instancias de nuestra aplicación, (De hecho el SLA de Windows Azure te sugiere  – casi obliga en termino de legalidad para cumplir con el SLA – tener dos instancias por lo menos de computo en donde hacer el despliegue.) ante este escenario la “Azurificación” puede comenzar por implementar el Cache Service con el fin de administrar las sesiones de nuestra aplicación web (Tema que tocaremos en un próximo post).

Después de pasar por esta pequeña “Azurificación” podríamos pensar en implementar el Storage Service con el fin de disminuir costos en BD relacionales.

Crear una aplicación web desde cero aprovechando el Potencial de Windows Azure: En este escenario contemplamos la idea de realizar una aplicación de principio a fin implementando las características de Windows Azure como nuestra “Lanza” principal y “aliado” tecnológico, esto debe ir acompañado de un buen arquitecto de software que te guie en la toma de decisiones ante este magnifico escenario; recordemos que Windows Azure es PAAS (Plataform As A Service) y es allí (en el consumo de la plataforma) en donde se encuentra lo mejor de Windows Azure, implementar sistemas transaccionales con la ayuda de los Servicios de Caché, implementar clientes remotos que consuman nuestros servicios (S+S) implementando el Service Bus, pensar en un sistema de trazabilidad de nuestra aplicación basado en el Storage para disminuir los costos, implementar clientes administrativos de nuestra plataforma para interactuar con el computo elástico.

Todas estas características tienen como único fin, ofrecer un entorno robusto, confiable, seguro y escalable para nuestras aplicaciones, características que solo podrían asegurar grandes compañías con equipos de TI gigantes a precios que un pequeña empresa pueda pagar!

Hasta Pronto.!

Juan Manuel Lombana