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

Generación de código con CodeDOM


CodeDOM (Code Document Object Model) es una tecnología que nos permite Generar y Compilar código dinámicamente, Todo se basa principalmente en representar el código sobre una estructura que vincula los objetos entre si, el inicio de esta estructura es el  CodeCompileUnit la cual es el inicio del árbol, todo esto es “Traducido” por un proveedor del lenguaje en el cual queramos generarlo (por defecto el Framework dispone de proveedores para C#, VB.Net y JScript).

Combinar esta técnica con otras podría representar una gran herramienta de la cual podríamos sacar ventaja:

Por ejemplo:
CodeDom + Serialization+ Reflection  = Aplicaciones Explosivas!!!
(Podriamos añadir aquí AppDomains y mucho más!).

Comenzando con CodeDOM

CodeDom funciona como un arbol de elementos jerarquicos, los cuales vamos referenciando y agregando al elemento principal (CodeCompileUnit).

He preparado unos videos con una aplicación de prueba.

1/3

2/3


3/3

Nota: Espero aun subir estos videos con una Buena Calidad… jejeje 🙂

Hasta la próxima.

Juan Manuel Lombana

Accediendo a Servicios Web Cross-Domain desde Silverlight


Después de un rato sin escribir, retomaré con algunos temas bastante interesantes, este es el primero de ellos.

Lo más común cuando desarrollamos un aplicación sobre silverlight es que esta tenga un servicio el cual le entrega los datos y la lógica del negocio, por comodidad el servicio siempre se encontraba en la aplicación web que hospedaba la aplicación de silverlight (o por lo menos así lo hacia yo para evitarme mayores problemas :$) , para estos casos la aplicación funcionaba perfectamente, pero cuando el servicio no se encontraba en este directorio era toda una odisea hacerlo funcionar!…

¿Cómo funcionan el acceso a los servicios Cross-Domain?

Cuando silverlight accede a un servicio web lo primero que verifica es el dominio en donde este se encuentra hospedado, si este se encuentra en un domino diferente al propio busca un par de archivos; el primer es el clientaccesspolicy.xml si este no existe silverlight buscará crossdomain.xml; estos archivos deben estar en la raíz del dominio en donde se hospeda el servicio web.

Los servicios más comunes en internet como Twitter, Amazon, Youtube disponen de archivos crossdomain.xml en la raiz de su dominio (Twitter tiene algunas restricciones en este archivo – Gracias Rodrigo)

Además de este hecho tener el servicio y el cliente de silverlight en un mismo directorio no es lo más seguro.

Manos a la Obra!

Después de tener listo nuestro servicio web (En otro proyecto obviamente) y tener creado nuestro cliente de silverlight dispuesto a consumir dicho servicio tendremos que crear el siguiente archivo.

El cual debe estar en la Raíz del Dominio en donde se hospeda el servicio web.

   <?xml version="1.0" encoding="utf-8"?>
   <access-policy>
      <cross-domain-access>
         <policy>
            <allow-from http-request-headers="*">
               <domain uri="*"/>
            </allow-from>
            <grant-to>
               <resource path="/" include-subpaths="true"/>
            </grant-to>
         </policy>
       </cross-domain-access>
   </access-policy>

Con esta configuración cualquier dominio podrá acceder a todos los recursos que se encuentran en el dominio actual.

Si el acceso al servicio se realiza sobre HTTPS desde un cliente en HTTP debe colocar la siguiente configuración entre los elementos <allow-from></allow-from>

<allow-from http-request-headers="*">
   <domain  uri="http://*"/>
</allow-from>

Es de anotar que Silverlight 4 nos evita esta configuración SI y SOLO SI el cliente de silverlight esta corriendo fuera del explorador con permisos Elevated-Trust (Como si se tratase de una aplicación windows común corriendo con privilegios).

Para ampliar mas información sobre este tema pueden visitar.

http://msdn.microsoft.com/es-es/library/cc197955%28VS.95%29.aspx

Hasta la Próxima.

Juan Manuel Lombana

Visual Studio – Error “El Registro de sucesos está lleno.”


El dia de ayer tuve un inconveniente con un visual studio 2008, al intentar crear una nueva conexión en el ServerExplorer salia un error diciendo “El registro de sucesos esta lleno”.

ServerExplorer

Obviamente pense en el Registro de Sucesos del Sistema Operativo, pero ¿por qué ha de llenarse?, además de esto el equipo tenia unas cuantas semanas de estar formateado, intente de otra forma y agregue un DataSet Tipado al proyecto, arrastre un TableAdapter y le indique “New Connection” pero en este caso no mostraba error, simplemente cerraba el Asistente y borraba el TableAdapter del DataSet… Pense en formatear de nuevo, pero esto llevaría mucho tiempo… la solución era casi obvia pero mi experiencia con las herramientas del sistema operativo ha sido poca… así que el pequeño problema se convertia en uno mas Mayúsculo…

La Solución.

Como ya lo había comentado era un poco obvio, si el Registro estaba lleno… pues Borrarlo sería lo mejor.. 🙂 y asi se hace:

1. Vamos a Inicio.

2. Opción Herramientas Administrativas (Debes tener habilitada esta opción en el menú de incio, si no lo tienes te vas a las propiedades de la barra de inicio, pestaña “Menu Inicio”,  “Personalizar”, y en la lista que aparece buscas “Herramientas Administrativas”, seleccionas la opción “Mostrar en todos los programas y menú inicio”, Después Aceptar a Todo 😉 .)

3. Seleccionamos Visor de Sucesos.

4. Buscamos el Log de Aplicación.

5.Vamos al menú Acción.

6. Seleccionamos la opción “Borrar Registro” (o algo parecido…)

7. Nos preguntará si deseamos guardarlo, seleccionamos una ruta y OK.

Ya podremos trabajar con normalidad, aunque aun me queda la intriga de que pudo llenar el registro y cuanto es el limite de este, esto en realidad puede suceder con cualquier aplicación que utilice el Registro de Sucesos de Windows.

Por cierto la clase para Acceder al Registro de Sucesos de Windows desde el Framework es: System.Diagnostics.EventLog.

Hasta la próxima.

Juan Manuel Lombana.