vtortola

Recorrer una estructura en arbol con multiples hilos: ThreadedTreeBase

vtortola — Sun, 14 Oct 2007 00:01:00 GMT

Esta clase, fruto de un fin de semana de inspiración y una semana de depurado en mis ratos libres, que no son muchos, sigue el planteamiento anterior para recorrer estructuras en arbol con múltiples hilos. Se trata de una clase abstracta que encapsula todo el mecanismo multithreading, simplemente hay que implementar un método que define como se obtienen sus hijos y suscribirse a un evento que es disparado por cada nodo.

Siempre es buena idea encapsular funcionalidades complejas de este tipo ya que:

Permite probar la funcionalidad en otros campos.
Permite hacer correciones de forma más sencilla. La lógica puede ser bastante complicada y no conviene mezclarla con la lógica de negocios.
Permite su reusabilidad.

La clase utiliza un tipo genérico para que pueda adaptarse a cualquier tipo. Los nodos encontrados se envian vía evento, junto a un StringBuilder que indica su jerarquia en el arbol y cuyo separador puede ser indicado también en una sobrecarga del constructor. Además, la clase argumento del evento está implementado dentro de la clase, lo que permite que use el tipo genérico de la clase ThreadedTreeBase. Las excepciones capturadas se devuelven también en un evento, por lo que conviene comprobar si la propiedad Error es null ó no cuando evaluemos un nodo.

[more]

Hay un método que permite cancelar la operación si esta en curso por medio de la evaluación de una variable run que se comprueba en cada ciclo.

Cuando se construye, se le indica el número de hilos que podrá manejar y la prioridad que se le quiere asignar.

public abstract class ThreadedTreeBase<NodeType>

  where NodeType : class

  // Objeto que controla el fin de la ejecución

  private readonly Object endLock = new Object();

  // Delegado para recursividad

  private delegate void runDlgt_(NodeType Node, StringBuilder Path);

  private readonly runDlgt_ runDlgt;

  // Control de hilos.

  private readonly Int32 maxThreads;

  private Int32 runningThreads = 0;

  public Int32 MaxThreads { get { return maxThreads; } }

  // Indicador de nodos por procesar

  private Int32 remainingNodes = 0;

  // Control de prioridad de ejecución.

  private readonly ThreadPriority priority;

  public ThreadPriority Priority { get { return priority; } }

  // Control de cancelación.

  private Int32 runFlag = 1;

  // Caracter delimitador de la ruta xpath

  private readonly Char xpathDelimiter = '/';

  public Char XpathDelimiter { get { return xpathDelimiter; } }

  // Evento de nodo procesado

  protected delegate void ProcessedNode_(ProcessedNodeEventArgs e);

  protected event ProcessedNode_ ProcessedNode;

  protected class ProcessedNodeEventArgs : EventArgs

    private NodeType node;

    private String xpath;

    private Exception error;

    public NodeType Node { get { return node; } }

    public String XPath { get { return xpath; } }

    public Exception Error { get { return error; } }

    public ProcessedNodeEventArgs(NodeType Nodo,

                                  String XPath,

                                  Exception Error)

      this.node = Nodo;

      this.xpath = XPath;

      this.error = Error;

  /// <summary>

  /// Constructor protegido.

  /// </summary>

  /// <param name="MaxThreads">Máximo de tareas concurrentes.</param>

  /// <param name="Priority">Indica la prioridad de los hilos.</param>

  protected ThreadedTreeBase(Int32 MaxThreads, ThreadPriority Priority)

    runDlgt = new runDlgt_(Run);

    // Resto un hilo ya que hay que

    // contar con el thread que inicia

    // la clase

    this.maxThreads = MaxThreads-1;

    this.priority = Priority;

  protected ThreadedTreeBase(Int32 MaxThreads, ThreadPriority Priority,

                             Char XpathDelimiter): this(MaxThreads, Priority)

    this.xpathDelimiter = XpathDelimiter;

  /// <summary>

  /// Iniciar navegación del arbol.

  /// </summary>

  /// <param name="Parte">Parte inicial.</param>

  public void RunBrowser(NodeType nodo)

    lock (endLock)

      runDlgt.BeginInvoke(nodo, new StringBuilder(),

        delegate(IAsyncResult ia)

          try { runDlgt.EndInvoke(ia); }

          catch (Exception Ex)

            Debug.Fail(Ex.Message, Ex.StackTrace);

            sendNodeData(nodo ?? default(NodeType), null, Ex);

        }, null);

      Monitor.Wait(endLock);

  /// <summary>

  /// Inicia recorrido desde nodo inicial.

  /// </summary>

  /// <param name="nodo">Nodo inicial</param>

  private void Run(NodeType Node, StringBuilder path)

    // Compruebo la cancelación (nuevas bifurcaciones).

    if (Thread.VolatileRead(ref runFlag) == 0) return;

    // Asigno la prioridad al thread.

    Thread.CurrentThread.Priority = this.priority;

    // Obtengo la jerarquia

    path = new StringBuilder(path.ToString());

    path.AppendFormat("{0}{1}",this.xpathDelimiter, Node);

    // Envio el nodo vía evento

    sendNodeData(Node, path, null);

    // Obtengo los subnodos y los contabilizo

    NodeType[] childs = getNodeChilds(Node);

    lock (endLock) remainingNodes += childs.Length;

    // Recorro la lista de nodos hijos...

    foreach (NodeType child in childs)

      // Compruebo la cancelación dentro del bucle.

      // (bifurcaciones en curso).

      if (Thread.VolatileRead(ref runFlag) == 0) return;

      // ... llamando recursivamente a cada uno de ellos..

      if (Thread.VolatileRead(ref runningThreads) < maxThreads)

        // Incremento el número de hilos secundarios en ejecución.

        Interlocked.Increment(ref runningThreads);

        // Ejecuto en otro hilo.

        runDlgt.BeginInvoke(child, path,

          delegate(IAsyncResult ia)

try

                Monitor.Enter(endLock);

                runDlgt.EndInvoke(ia);

              catch (Exception Ex)

                Debug.Fail(Ex.Message, Ex.StackTrace);

                NodeType userState = ia.AsyncState as NodeType;

                sendNodeData(userState ?? default(NodeType), null, Ex);

              finally

                runningThreads--;

                remainingNodes--;

                // Se pulsa sobre 'endLock' si no hay hilos

                // secundarios en ejecución ni nodos pendientes.

                if ((runningThreads == 0) && (remainingNodes == 0))

                  Monitor.Pulse(endLock);

                Monitor.Exit(endLock);

            }, child);

      else

try

          runDlgt.Invoke(child, path);

          lock (endLock)

            remainingNodes--;

            if ((runningThreads == 0) && (remainingNodes == 0))

              Monitor.Pulse(endLock);

        catch (Exception Ex)

          Debug.Fail(Ex.Message, Ex.StackTrace);

          sendNodeData(child ?? default(NodeType), null, Ex);

  /// <summary>

  /// Envia los datos vía evento.

  /// </summary>

  /// <param name="nodo">Nodo del que se obtuvo la información.</param>

  /// <param name="infoNodo">Información.</param>

  private void sendNodeData(NodeType nodo,

                            StringBuilder path, Exception Ex)

    if(ProcessedNode!=null)ProcessedNode.Invoke(new ProcessedNodeEventArgs

      (nodo, path == null ? String.Empty : path.ToString(), Ex));

  /// <summary>

  /// Cancela la ejecución.

  /// </summary>

  protected void CancelBrowse()

    // Full memory barrier

    Interlocked.Exchange(ref runFlag, 0);

  /// <summary>

  /// Función a implementar con la forma de obtener

  /// los nodos hijos de otro nodo.

  /// </summary>

  /// <param name="nodo">Nodo padre</param>

  /// <returns>Lista de nodos</returns>

  protected abstract NodeType[] getNodeChilds(NodeType nodo);

Ahora un ejemplo de su implementación. El sistema de archivos es a fin de cuentas, una estructura en arbol, así que voy a hacer una pequeña implementación de esta clase que me diga cuantos archivos contiene un directorio contando los que hay en sus subdirectorios... en multihilo, por supuesto :D

Evidentemente, no tiene utilidad práctica lanzar múltiples hilos contra un recurso local, con latencia mínima y compartido para todos los hilos ... simplemente como prueba:

public class ThreadedTreeFileSystem

  : ThreadedTreeBase<FileSystemInfo>

  // Contador

  private long counter = 0;

  public Int64 Contador

    get { return Thread.VolatileRead(ref counter); }

  public ThreadedTreeFileSystem(int MaxThreads, ThreadPriority p)

      : base(MaxThreads, p)

    // Me subscribo al evento que devuelve los nodos.

    this.ProcessedNode += new ThreadedTreeBase<FileSystemInfo>.ProcessedNode_

      (ExplosionSistemaDeArchivos_ProcessedNode);

  void ExplosionSistemaDeArchivos_ProcessedNode

    (ThreadedTreeBase<FileSystemInfo>.ProcessedNodeEventArgs e)

    // Si el nodo es un archivo, lo cuento y lo muestro.

    if (e.Node is FileInfo)

      Interlocked.Increment(ref counter);

  protected override FileSystemInfo[] getNodeChilds(FileSystemInfo nodo)

    // Obtengo la lista de subnodos.

    List<FileSystemInfo> array = new List<FileSystemInfo>();

try

      if (nodo is DirectoryInfo)

        array.AddRange(((DirectoryInfo)nodo).GetDirectories("*"));

        array.AddRange(((DirectoryInfo)nodo).GetFiles());

    catch (SecurityException sEx)

      Console.WriteLine("{0} : {1}", sEx.GetType().Name, sEx.Message);

    return array.ToArray();

La implementación tiene cuatro partes esenciales:

La clase se define heredando de ThreadedTreeBase y especificando el tipo que usaremos como nodo.
En el constructor, se pasan los parámetros adecuados y se define el evento.
En el manejador del evento, se procesa el nodo, en este caso, únicamente se cuentan los archivos y se muestra su nombre. También podríamos ver la jerarquia en e.XPath.
En GetNodeChilds, el método que debemos implementar para completar la clase abstracta, esta la lógica necesaria para obtener los subnodos de un nodo y lo devuelve en forma de array.

Es importante remarcar, que aunque todo el mecanismo multithreading esta encapsulado, seguimos necesitando sincronizar los accesos a la memoria compartida, como por ejemplo el acceso a counter, que se incrementa con Interlocked para evitar race conditions (condiciones de anticipación).

Para su uso...

string folder = Environment.GetFolderPath(Environment.SpecialFolder.Personal);

ThreadedTreeFileSystem browser =

    new ThreadedTreeFileSystem(5, ThreadPriority.Normal);

browser.RunBrowser(new DirectoryInfo(folder));

Console.WriteLine("-- Archivos: " + browser.Contador);

Cualquier feedback sobre esta clase ó su diseño es bienvenida :)

Recorrer una estructura en arbol con multiples hilos: ThreadedTreeBase | vtortola.NET

Crossposting desde ElBruno.com

Recorrer una estructura en arbol con múltiples hilos

vtortola — Sat, 13 Oct 2007 20:45:16 GMT

Una estructura arbol se recorre por medio de una función recursiva empezando desde el nodo raiz por medio de dos operaciones básicas, un método ProcessNode con el que procesamos la información de ese nodo, y otro GetNodeChilds con el que obtenemos los nodos hijos de un nodo, sería algo así:

static void BrowseTree(Node root)

  ProcessNode(root);

  foreach (Node n in GetNodeChilds(root))

    BrowseTree(n);

Pero cuando esa estructura en arbol es realmente grande, ó alguna de las dos operaciones conlleva una latencia significativa, como puede ser por ejemplo procesar cada nodo localmente u obtener los hijos de un nodo a través de la red, puede ser muy útil recorrer dicha estructura con múltiples hilos si se dan las condiciones adecuadas, que pueden ser:

[more]

Latencia elevada que provoca tiempos de Idle significativos al obtener los hijos.
Múltiples CPUs en la máquina que navega el arbol.
Múltiples CPUs en la máquina que contiene el arbol, capacidad para atender peticiones concurentes y preferiblemente concurrencia optimista.

El algorrítmo se complica un poco, pero gracias al modelo de programación asíncrono podemos simplificar bastante. A priori, puede parece que es tan simple como lanzar un hilo por cada nodo hijo del nodo raiz, pero si el nodo raiz tiene muchos hijos en su primer nivel podemos dejar vacio el ThreadPool pudiendo causar un deadlock ó en caso de usar Threads convencionales llegar a un número contraproducente de ellos, por lo que debemos controlar cuantos hilos vamos a usar para recorrer el arbol. Pero no esta todo solucionado, si el primer nodo hijo tiene 4 hijos, y el segundo nodo hijo tiene 400... el hilo que se encargue del primer nodo quedará desaprovechado mientras que el que se encargue del segundo tendrá mucho trabajo por delante, por lo que debemos poder reutilizar los hilos de forma dinámica.

Estos dos problemas quedan resueltos con el siguiente modelo:

Nota: Estos ejemplos de código son orientativos y simplificados.

static BrowseTreeDlgt_ BrowseTreeDlgt = new BrowseTreeDlgt_(BrowseTree);

static void BrowseTree(Node root)

  ProcessNode(root);

  foreach (Node n in GetNodeChilds(root))

    if (runningThreads<maxThreads)

      runningThreads++;

      BrowseTreeDlgt.BeginInvoke(n,

                                 delegate(IAsyncResult ia)

                                   BrowseTreeDlgt.EndInvoke(ia);

                                   runningThreads--;

},

                                 null);

    else

      BrowseTreeDlgt.Invoke(n);

maxThreads define el número máximo de hilos a usar y runningThreads los que tenemos ya en funcionamiento, si hay hilos disponibles se lanza el nodo en otro hilo (.BeginInvoke) y si no, pues se continua con el hilo actual (.Invoke) como si de una función recursiva se tratase. Cada vez que creamos un hilo, incrementamos runningThreads y lo decrementamos cuando acaba, pero ... ¿en que orden exactamente? Pues el incremento lo antes posible y el decremento lo más tarde posible, de forma que se reduzca la posiblidad de crear hilos de más. De esta forma controlamos la cantidad de hilos.

Este modelo tiene una pega particular, y es el hecho de que cuando lanzamos nodos con todos sus hijos en otro hilo, la ejecución del hilo principal llegará al final y no sabremos si el resto de hilos secundarios han acabado ya de procesar todos sus nodos. El mejor planteamiento es bloquear el hilo que llama a la función hasta que se acabe de recorrer el arbol, para ello bloqueamos dicho hilo y cuando el número de hilos secundarios sea 0, lo liberamos. Sería algo así:

static void BrowseTree(Node root)

  ProcessNode(root);

  foreach (Node n in GetNodeChilds(root))

    if (runningThreads<maxThreads)

      runningThreads++;

      BrowseTreeDlgt.BeginInvoke(n,

                                 delegate(IAsyncResult ia)

                                   BrowseTreeDlgt.EndInvoke(ia);

                                   runningThreads--;

                                   if (runningThreads == 0)

                                     lock (endLock)

                                       Monitor.Pulse(endLock);

},

                                 null);

    else

      BrowseTreeDlgt.Invoke(n);

Y al llamar a la función:

lock (endLock)

  BrowseTree(node);

  Monitor.Wait(endLock);

Esto hará que se llame a BrowseTree y cuando termine el hilo principal quede bloquedado hasta que runningThreads sea 0. Pero siguen habiendo problemas... :D

Una de las cosas que debemos tener en cuenta en entornos multithreading es que no hay un orden concreto y que la memoria puede ser alterada en cualquier momento, incluso entre instrucción e instrucción. Si por cualquier motivo, el hilo principal acaba después de los hilos secundarios... (por que le ha tocado procesar más nodos..) ... el Pulse llegaría antes que el Wait, con lo que la aplicación quedaría en un deadlock. Para evitar esta situación, lo ideal es llamar a BrowseTree asíncronamente de forma que el hilo que llama a la función quede bloqueado en el Wait inmediatamente y aunque añadamos un hilo adicional... la carga es la misma:

lock (endLock)

  BrowseTreeDlgt.BeginInvoke(node,

                             delegate(IAsyncResult ia)

                             {BrowseTreeDlgt.EndInvoke(ia);},

                             null);

  Monitor.Wait(endLock);

Ahora que esta resuelto el tema de "bloquear hasta terminar", hay que dar un repaso a la condición que lo desbloquea, la de que los hilos secundarios en ejecución sea 0... Como decía la memoria puede ser alterada y/ó evaludada en cualquier momento, entonces se puede dar la situación (de hecho se da) de que se haga un Pulse sobre el bloqueo mientras que se esté a punto de iniciar otro hilo secundario porque hay más nodos que procesar en el bucle... Por este motivo, hay que tener en cuenta si hay nodos por procesar antes de hacer el Pulse, es decir, la condición para que se libere el bloqueo y por tanto se de por terminado el recorrido por el arbol es, que no haya hilos en ejecución y que los nodos por procesar sean 0, con lo que se asegura que cuando se den estas dos condiciones es el último hilo en ejecución. Ahora debemos comprobar tanto al final de las ejecuciones síncronas como asíncronas:

static void BrowseTree(Node root)

  ProcessNode(root);

  Node[] childs =GetNodeChilds(root);

  nodesRemaining += childs.Length;

  foreach (Node n in childs)

    if (runningThreads < maxThreads)

      runningThreads++;

      BrowseTreeDlgt.BeginInvoke(n,

                                 delegate(IAsyncResult ia)

                                   BrowseTreeDlgt.EndInvoke(ia);

                                   runningThreads--;

                                   nodesRemaining--;

                                   if ((runningThreads == 0)&&

                                       (nodesRemaining==0))

                                     lock (endLock)

                                       Monitor.Pulse(endLock);

},

                                 null);

    else

      BrowseTreeDlgt.Invoke(n);

      nodesRemaining--;

      if ((runningThreads == 0) &&

          (nodesRemaining == 0))

        lock (endLock)

          Monitor.Pulse(endLock);

Como handicap el uso de multiples hilos trae los problemas que implica la sincronización, cosa en la que habrá que poner sumo cuidado y ... sobre todo ... imaginación, la principal herramienta del programador. La forma ideal de ejecutar esta función sería algo más compleja:

static BrowseTreeDlgt_ BrowseTreeDlgt = new BrowseTreeDlgt_(BrowseTree);

static void BrowseTree(Node root)

  ProcessNode(root);

  Node[] childs =GetNodeChilds(root);

  lock(endLock)

    nodesRemaining += childs.Length;

  foreach (Node n in childs)

    if (runningThreads < maxThreads)

      Interlocked.Increment(ref runningThreads);

      BrowseTreeDlgt.BeginInvoke(n,

                                 delegate(IAsyncResult ia)

try

                                     Monitor.Enter(endLock);

                                     BrowseTreeDlgt.EndInvoke(ia);

                                     runningThreads--;

                                     nodesRemaining--;

                                   finally

                                     if ((runningThreads == 0) &&

                                         (nodesRemaining == 0))

                                       Monitor.Pulse(endLock);

                                     Monitor.Exit(endLock);

},

                                 null);

    else

      BrowseTreeDlgt.Invoke(n);

      lock (endLock)

        nodesRemaining--;

        if ((runningThreads == 0) &&

            (nodesRemaining == 0))

            Monitor.Pulse(endLock);

Como se puede observar, el principal problema es no saber cuantos nodos tiene el arbol hasta que se han recorrido todos, pero con este planteamiento queda resuelto, al menos es lo que dicen las pruebas concienzudas con distintas CPUs y sistemas operativos que he hecho.

En el próximo artículo un ejemplo de una clase que realiza esta tarea mismo, con ejemplos incluidos ... ;)

Recorrer una estructura en arbol con múltiples hilos | vtortola.NET

Crossposting desde ElBruno.com

Cliente FTP asíncrono

vtortola — Sun, 07 Oct 2007 23:38:00 GMT

Este es un (largo) ejemplo de como crear un cliente FTP asíncrono que gestione múltiples descargas de forma paralela. En este modelo, generalmente la lógica de la aplicación suele estar compuesta por métodos estáticos, pero se añade un objeto de estado (objectState) que realiza el seguimiento de la tarea durante las fases de la aplicación, el estado de la tarea puede notificarse mediante eventos por cambio, temporizados ó devolver el mismo objeto de estado para su seguimiento externo.

En este caso, he optado por devolver el propio objeto de estado pero protegido con una interfaz para que solo determinados miembros puedan ser accesibles y solo para lectura, el final de la tarea se indica con un evento que trae el mismo tipo de objeto. Guardar el objeto de estado y monitorizarlo ó simplemente esperar al evento de fin... queda a la libre elección.

[more]

La interfaz y el delegado que define al evento:

public interface IFtpDownloadInfo

  Int32 ID{get;}

  Boolean Ended{get;}

  Int64 Donwloaded{get;}

  Exception Error{get;}

  Int64 ElapsedMilliseconds{get;}

  Int64 Length{get;}

  String LocalDirectory{get;}

  String RemoteFile{get;}

  String FileName { get;}

public delegate void FtpEventDlg_(IFtpDownloadInfo e);

La clase que define el objeto de estado cumple esta interfaz, de forma que cuando enviemos el evento, relamente se pasa dicho objeto, pero solo serán accesibles los miembros de dicha interfaz. Esta clase contiene toda la información y campos necesarios para realizar el tracking de la descarga, además implementa el patrón desechable para poder liberar los recursos correctamente una vez haya terminado. El método .ToString ha sido redefinido para poder obtener una información rápida del objeto:

internal class FtpDownloadState:IFtpDownloadInfo,IDisposable

  private readonly Int32 id;

  private Int64 length = 0;

  private Int64 downloadedBytes = 0;

  private String localDirectory;

  private String remoteFile;

  private String fileName;

  private Exception error;

  public Int32 ID{

    get { return id; }}

  public Boolean Ended {

    get { return (downloadedBytes == length)&&(length!=0);}}

  public Int64 Donwloaded {

    get { return Interlocked.Read(ref downloadedBytes); }

    set { Interlocked.Exchange(ref downloadedBytes,value); }}

  public Exception Error{

    get { return error; }

    set { error = value;}}

  public Int64 ElapsedMilliseconds{

    get { lock(DownloadStopWatch)

            return DownloadStopWatch.ElapsedMilliseconds;}}

  public Int64 Length{

    get { return length; }

    set { length = value; }}

  public String LocalDirectory{

    get { return localDirectory; }}

  public String RemoteFile {

    get { return remoteFile; } }

  public String FileName {

    get { return fileName; } }

  private Boolean disposing = false;

  internal Stopwatch DownloadStopWatch = new Stopwatch();

  internal Int32 BufferLength;

  internal NetworkCredential Credential;

  internal FtpWebRequest Ftpcon;

  internal Stream Target;

  internal Stream Source;

  internal Byte[] Buffer;

  internal FtpDownloadState(Int32 ID, String LocalDirectory, String RemoteFile,

                            Int32 BufferLength, String Login, String Password)

    this.localDirectory = LocalDirectory;

    this.remoteFile = RemoteFile;

    this.BufferLength = BufferLength;

    if ((Login!=null)&&(Login.Length>0))

      this.Credential = new NetworkCredential(Login, Password);

    this.fileName = Path.GetFileName(this.RemoteFile);

    this.Buffer = new byte[this.BufferLength];

    this.id = ID;

  public override string ToString()

    if (this.error == null)

      return string.Format("{0}: {1}kB/{2}kB en {3}s.", this.fileName,

        this.Donwloaded / 1024, this.Length / 1024,

        this.ElapsedMilliseconds / 1000);

    else

      return string.Format("{0}: {1}", this.fileName, this.error.Message);

  private void Dispose(Boolean d)

    if (!disposing)

      this.Target.Dispose();

      this.Source.Dispose();

      GC.SuppressFinalize(this);

  public void Dispose()

    Dispose(true);

  ~FtpDownloadState()

    Dispose(true);

Como se puede ver, esta clase no tiene funcionalidad FTP en si misma, lo que permite poder substituir la entidad ó la lógica de forma separada, incluso trabajar con otros tipos de Streams.

Sobre la sincronización, se protege ElapsedMillisecons y Downloaded porque son dos miembros de 64bits que pueden ser modificados al mismo tiempo que se leen, por lo que hay que asegurar la atomicidad.

Ahora la lógica que realiza todo el proceso de la descarga de FTP. El principio de funcionamiento es el mismo que el ejemplo de la descarga FTP, solo que ahora uso .BeginRead en lugar de .Read. Lamentablemente, para obtener cual es la longitud total del archivo hay que conectar en modo GetFileSize antes, lo cual complica un poco la lógica, que aún así es bastante simple:

static public class FtpAsyncDownload

  // Evento de fin de descarga

  static public event FtpEventDlg_ FtpDownloadEvent;

  // Orden de descarga

  // Prepara el objectState y obtiene pide el tamaño.

  static public IFtpDownloadInfo Download(Int32 ID, String LocalDirectory,

                                          String RemoteFile,Int32 BufferLength,

                                          String Login, String Password)

    FtpDownloadState ftpdwn =

      new FtpDownloadState(ID, LocalDirectory, RemoteFile, BufferLength,

                           Login, Password);

    ftpdwn.Ftpcon = (FtpWebRequest)FtpWebRequest.Create(ftpdwn.RemoteFile);

    ftpdwn.Ftpcon.Credentials = ftpdwn.Credential;

    ftpdwn.Ftpcon.KeepAlive = false;

    ftpdwn.Ftpcon.UseBinary = true;

    ftpdwn.Ftpcon.Proxy = null;

    ftpdwn.Ftpcon.EnableSsl = false;

    ftpdwn.Ftpcon.Method = WebRequestMethods.Ftp.GetFileSize;

    ftpdwn.Source = ftpdwn.Ftpcon.GetResponse().GetResponseStream();

    ftpdwn.Source.BeginRead(ftpdwn.Buffer, 0,ftpdwn.BufferLength,

                            startDownload, ftpdwn);

    return ftpdwn;

  // Comienza la descarga

  // Obtiene el tamaño y pide el inicio de

  // la descarga del archivo.

  static private void startDownload(IAsyncResult ia)

    FtpDownloadState ftpdwn = ia.AsyncState as FtpDownloadState;

try

      ftpdwn.Source.EndRead(ia);

      ftpdwn.Length = ftpdwn.Ftpcon.GetResponse().ContentLength;

      if (ftpdwn.Length <= 0) throw new ArgumentException("FileSize <=0");

      ftpdwn.Ftpcon = (FtpWebRequest)FtpWebRequest.Create(ftpdwn.RemoteFile);

      ftpdwn.Ftpcon.Credentials = ftpdwn.Credential;

      ftpdwn.Ftpcon.KeepAlive = false;

      ftpdwn.Ftpcon.UseBinary = true;

      ftpdwn.Ftpcon.Proxy = null;

      ftpdwn.Ftpcon.EnableSsl = false;

      ftpdwn.Ftpcon.Method = WebRequestMethods.Ftp.DownloadFile;

      ftpdwn.Target = new FileStream(Path.Combine(ftpdwn.LocalDirectory, ftpdwn.FileName),

                                     FileMode.Create, FileAccess.Write, FileShare.None);

      ftpdwn.Source = ftpdwn.Ftpcon.GetResponse().GetResponseStream();

      ftpdwn.DownloadStopWatch.Start();

      ftpdwn.Source.BeginRead(ftpdwn.Buffer, 0, ftpdwn.BufferLength,

                                    downloadCallback, ftpdwn);

    catch (Exception ex)

      ftpdwn.Error = ex;

      if (FtpDownloadEvent != null)

        FtpDownloadEvent.Invoke(ftpdwn);

  // Descarga

  // Función que se ejecuta cada vez que se obtiene

  // un buffer completo para escribir y volver a ejecutarse

  // hasta que acabe.

  static private void downloadCallback(IAsyncResult ia)

    FtpDownloadState ftpdwn = ia.AsyncState as FtpDownloadState;

try

      int readed = ftpdwn.Source.EndRead(ia);

      ftpdwn.Target.Write(ftpdwn.Buffer, 0, readed);

      ftpdwn.Donwloaded += readed;

      if (!ftpdwn.Ended)

        ftpdwn.Source.BeginRead(ftpdwn.Buffer, 0, ftpdwn.BufferLength,

                                      downloadCallback, ftpdwn);

      else

try

          if (FtpDownloadEvent != null)

            FtpDownloadEvent.Invoke(ftpdwn);

        catch { }

        ftpdwn.DownloadStopWatch.Stop();

        ftpdwn.Dispose();

    catch (Exception ex)

      ftpdwn.Error = ex;

      if (FtpDownloadEvent != null)

        FtpDownloadEvent.Invoke(ftpdwn);

Básicamente el funcionamiento consiste en lo siguiente:

Se llama al método Download.
Este crea un nuevo objeto de estado e invoca asíncronamente la obtención del tamaño del archivo. Indica que al finalizar vaya al método startDownload.
Se ejecuta startDownload, obtiene el tamaño de archivo, configura la conexión para realizar la descarga e invoca asíncronamente la descarga del archivo. Indica que al finalizar vaya al método downloadCallback.
Cuando haya descargado un buffer completo, se llama a downloadCallback, escribe el resultado en el archivo y si no se ha descargado todo aún se vuelve a invocar asíncronamente la descarga hasta que complete.
Cuando acaba, dispara el evento y llama a .Dispose para que libere los Streams del objeto de estado.

Para realizar una descarga, simplemente hay que subscribirse al evento e invocar el método estático Download con los parámetros adecuados:

      FtpAsyncDownload.FtpDownloadEvent +=

          new FtpEventDlg_(FtpAsyncDownload_FtpDownloadEvent);

      FtpAsyncDownload.Download(0, Environment.CurrentDirectory, @"ftp://miftp.com/miarchivo.rar",

                                      8192, "MiLogin", "M1P455W0RD");

Como decía anteriormente, el método Download devuelve un objeto de tipo IFtpDownloadInfo con el que podemos monitorizar el estado de la descarga. Una vez acabe, se disparará el evento si estamos subscritos a él.

Cliente FTP asíncrono | vtortola.NET

Crossposting desde ElBruno.com

Extendiendo un ProgressBar. FlatProgressBar.

vtortola — Sat, 06 Oct 2007 20:03:38 GMT

Vamos con una de Arts Attack... El ProgressBar de .NET es "bonito", sobre todo en Windows Vista, pero a mi gusto prefería menos destellos fashion y un poco más de información... y ya puestos ... un estilo flat :D

En vez de crear uno from scratch, mucho mejor extender el ProgressBar, añadirle nuevas propiedades y redefinir como repintarlo. Código fuente al final del artículo ;)

Entre los puntos fuertes de extender un control WinForm, esta el de redifinir los estilo con Control.SetStyle y sobreescribir el método OnPaint, dentro de este obtemenos el objeto Graphics con el que podemos pintar formas y textos. Mediante atributos configuramos los elementos que Visual Studio usará para mostrar sus propiedades:

ToolBoxBitmap: Sobre la clase, indica el icono que mostrará Visual Studio en la paleta de componentes. Se añade una imagen .bmp al proyecto como recurso embebido, después se indica tal y como aparece en el código. A veces no funciona bien, así que hay un truco creando esa clase vacia 'resfinder' y luego indicando la imagen junto al Namespace, funciona siempre :D
Browsable: Sobre una propiedad, indica si Visual Studio debe mostrarla en el Property Grid.
CategoryAttribute: Sobre una propiedad, indica en que categoria del Property Grid colocarla.
DescriptionAttribute: Sobre una propiedad, indica la descripción de esa propiedad en el Property Grid.

Una vez generado el componente en un ensamblado, para usarlo solo tenemos que añadirlo a la paleta de nuestro VS2005, desde el ToolBox, botón derecho, Choose Items, le damos a Browse para ir hasta el ensamblado, lo selecionamos y se añade a la paleta.

Asi mediante VS2005 podemos configurar los nuevos elementos de nuestro ProgressBar, además de ocultar otros que no nos interesan como se puede ver con por ejemplo la propiedad Style.

Pintar en un formulario es relativemente fácil con la clase Graphics y sus utilidades, pero requiere algo de paciencia y "prueba-error" para ajustarlo adecuadamente. Me apunto en el TODO escribir sobre las nociones básicas de GDI+.

Y ahora... el código fuente:

using System;

using System.Collections.Generic;

using System.Text;

using System.Windows.Forms;

using System.Drawing;

using System.Drawing.Drawing2D;

using System.ComponentModel;

internal class resfinder { }

namespace CustomProgressBars

  [ToolboxBitmap(typeof(resfinder), "FlatProgressBar.FlatProgressBar.bmp")]

  public class FlatProgressBar : ProgressBar

    private Pen _border;

    private String _text;

    private SolidBrush _brushForeColor;

    private SolidBrush _brushBarColor;

    [Browsable(true)]

    [CategoryAttribute("FlatProgressBar"),

    DescriptionAttribute("Color de la Barra")]

    public Color BarColor

      get { return _brushBarColor.Color; }

      set { _brushBarColor.Color = value; }

    [Browsable(true)]

    [CategoryAttribute("FlatProgressBar"),

    DescriptionAttribute("Color del Texto")]

    public Color TextColor

      get { return _brushForeColor.Color; }

      set { _brushForeColor.Color = value; }

    [Browsable(true)]

    [CategoryAttribute("FlatProgressBar"),

    DescriptionAttribute("Color del Borde")]

    public Color BorderColor

      get { return _border.Color; }

      set { _border.Color = value; }

    [Browsable(true)]

    [CategoryAttribute("FlatProgressBar"),

    DescriptionAttribute("Color del Borde")]

    public Single BorderWidth

      get { return _border.Width; }

      set { _border.Width = value; }

    [Browsable(true)]

    [CategoryAttribute("FlatProgressBar"),

    DescriptionAttribute("Color de Fondo")]

    public new Color BackColor

      get { return base.BackColor; }

      set { base.BackColor = value; }

    [Browsable(true)]

    [CategoryAttribute("FlatProgressBar"),

    DescriptionAttribute("Texto de la barra"),

    DefaultValue("Text")]

    public new String Text

      get { return _text; }

      set { _text = value; }

    [Browsable(true)]

    [CategoryAttribute("FlatProgressBar"),

    DescriptionAttribute("Tipo de fuente del texto.")]

    public new Font Font

      get { return base.Font; }

      set { base.Font = value; }

    [Browsable(false)]

    new public ProgressBarStyle Style

      get { return ProgressBarStyle.Continuous; }

      set { }

    [Browsable(false)]

    new public Int32 MarqueeAnimationSpeed

      get { return 0; }

      set { }

    [Browsable(false)]

    new public Color ForeColor

      get { return TextColor; }

      set { }

    public FlatProgressBar()

      InitializeComponent();

    private void InitializeComponent()

      this.SetStyle(ControlStyles.AllPaintingInWmPaint |

      ControlStyles.UserPaint |

      ControlStyles.OptimizedDoubleBuffer |

      ControlStyles.ResizeRedraw |

      ControlStyles.SupportsTransparentBackColor, true);

      _border = new Pen(Brushes.Black);

      _brushForeColor = new SolidBrush(Color.White);

      _brushBarColor = new SolidBrush(Color.Gray);

      base.Font = new Font("Tahoma", 10, FontStyle.Bold);

    protected override void OnPaint(PaintEventArgs e)

      // cuando mide cada paso

      Single step = (Single)this.Width / this.Maximum;

      // cuantos puntos es el progreso actual

      Single progressInPoints = (this.Value * step);

      progressInPoints = progressInPoints > 0 ? progressInPoints : 0;

      // barra de progreso

      e.Graphics.FillRectangle(_brushBarColor, 0, 0, progressInPoints, this.Height);

      // texto con antialias

      SmoothingMode bk = e.Graphics.SmoothingMode;

      e.Graphics.SmoothingMode = SmoothingMode.AntiAlias;

      // escribo el texto

      e.Graphics.DrawString(_text, Font, _brushForeColor,

                  new PointF(6, (this.Height - this.Font.Height) / 2));

      string percent = ((this.Maximum / 100) * this.Value).ToString() + '%';

      percent = percent.PadLeft(4, ' ');

      // mido el porcentaje en puntos para saber

      // donde ubicarlo

      SizeF swidth = e.Graphics.MeasureString(percent, base.Font);

      // escribo porcentaje

      e.Graphics.DrawString(percent, base.Font, _brushForeColor,

                  new PointF((this.Width - _border.Width - swidth.Width - 1),

                             (this.Height - base.Font.Height) / 2));

      // restauro el modo

      e.Graphics.SmoothingMode = bk;

      // dibujo el border si es mayor que 0

      if (_border.Width >= 1)

        e.Graphics.DrawRectangle(_border, 0, 0, this.Width - 1, this.Height - 1);

Extendiendo un ProgressBar. FlatProgressBar. | vtortola.NET

Crossposting desde ElBruno.com

Optimización de la evaluación de condiciones

vtortola — Sat, 06 Oct 2007 02:54:42 GMT

En C#, el orden de evaluación de operadores es de izquierda a derecha por orden de prioridad en cualquier tipo de operación. Además, a la hora de evaluar condiciones lógicas se puede anticipar el resultado final si el resultado parcial hasta el momento es inamovible, es decir, que pase lo que pase en el resto de condiciones el resultado parcial será el definitivo, en ese caso, el resto de condiciones no son evaluadas.

Desde el punto de vista del rendimiento, nos permite ahorrar evaluaciones (y con ello instrucciones) innecesarias en nuestra lógica si nos aprovechamos bien de esta característica.

Para ejemplificar este comportamiento, observa este simple programa:

static void Main(string[] args)

  if (Test1(false) || Test2(false) || Test3(false))

    Console.WriteLine("Dentro!");

  Console.ReadKey();

static Boolean Test1(Boolean param)

  Console.WriteLine("Test1");

  return param ^ true;

static Boolean Test2(Boolean param)

  Console.WriteLine("Test2");

  return param ^ true;

static Boolean Test3(Boolean param)

  Console.WriteLine("Test3");

  return param ^ true;

La instrucción 'if' evalua una condición formada por dos operaciones OR sobre tres métodos que devuelven true ó false. Al devolver 'Test1' un true y siendo una opearción OR sea cual sea el resultado de 'Test2' y 'Test3' ... el resultado final será true, por lo que estos dos últimos no son evaluados. El programa devuelve la siguiente salida:

Test1
Dentro!

Sin embargo, si modificamos la línea del 'if' por:

if (Test1(true) || Test2(false) || Test3(false))

Test1
Test2
Dentro!

El resultado varia, ya que al devolver 'Test1' false, el resultado final no se puede anticipar, pero cuando 'Test2' devuelve true, ya no es necesario evaluar 'Test3':

Por ejemplo si sustituimos los OR por AND, el resultado es distinto ... pero siguiendo la misma línea de actuación:

  if (Test1(false) && Test2(false) && Test3(false))

Test1
Test2
Test3
Dentro!

Al ser las dos primeras condiciones true, cualquier resultado parcial podría ser anulado por un false en 'Test3', por lo que debe evaluar las 3ª.

Este comportamiento aplica a cualquier tipo de operación booleana, por compleja que sea, si en un determinado momento dada la ecuación lógica, se sabe que el resultado parcial será definitivo... el resto se obvia.

La última sentencia 'if' probada, podría ser fácilmente substituible por condiciones anidadas ya que al igual que la operación con AND, evaluar una condición implica que se ha superado la anterior:

if (Test1(false))

  if (Test2(false))

    if (Test3(false))

      Console.WriteLine("Dentro!");

Pero en el resto de operaciones implica estructuras más complejas, que al igual que esta última (por simple que sea) deben ser evitadas siempre que no haya que emprender aluguna acción por cada condición a evaluar ó sea un requerimiento evaluarlas todas.

Las estructuras condicionales desmesuradas y mal estructuradas, no solo implican un código ilegible y niveles de identación inaceptables, si no que una mala estructuración puede derivar en la evaluación redundante e innecesaria de condiciones. Evaluar una condición simple como el valor de una variable puede ser algo insignificante, pero si la evaluación es directamente resultado de un método... ejecutar dicho método ó no puede significar una diferencia de rendimiento proporcional al tiempo de CPU que lleva ejecutarlo. Evita la lógica innecesaria !!

Una vez tengamos claro en flujo lógico de nuestra aplicación, y si como decía las condiciones se evaluan pero no se hace nada por cada una de ellas, podemos simplificar fácilmente pequeños grupos de evaluaciones mediante las tablas de Karnaugh, y ecuaciones ya más grandes mediante el algrebra de Boole, muy muy útil para simplificar bloques de lógica de negocios. Dos cosas de las que escribiré en mi blog en breve...

Como colofón, cuando evaluemos condiciones que pueden tomar muchos valores, mejor que la sucesión continua de else if, es mejor usar la instrucción switch. Como muestra un sencillo benchmark (que llevaba tiempo sin hacer uno xD):

Stopwatch sw = new Stopwatch();

sw.Start();

for(int i =0;i<1000000;i++)

  TestCharIfElse('z');

sw.Stop();

Console.WriteLine("TestCharIfElse: {0} ms.",sw.ElapsedMilliseconds);

sw.Reset();

sw.Start();

for (int i = 0; i < 1000000; i++)

  TestCharSwitch('z');

sw.Stop();

Console.WriteLine("TestCharSwitch: {0} ms.", sw.ElapsedMilliseconds);

Por un lado, 'TestCharIfElse' que com prueba si un caracter está en el alfabeto por medio de instruciones 'if else':

static Boolean TestCharIfElse(Char c)

  if (c == 'a')

    return true;

  else if (c == 'b')

    return true;

    [... Omitido por brevedad...]

  else if (c == 'z')

    return true;

  else return false;

Por otro, 'TestCharSwitch', que realiza la misma comprobación pero con la instrucción switch:

static Boolean TestCharSwitch(Char c)

  switch (c)

    case 'a': return true;

    case 'b': return true;

    [... Omitido por brevedad ...]

    case 'z': return true;

    default: return false;

La prueba envia un millón de veces el caracter 'z', que obliga a 'TestCharElseIf' a recorrer todas sus condiciones, mientras que 'TestCharSwitch' lo encuentra de forma más rápida como muestra el resultado:

TestCharIfElse: 57 ms.
TestCharSwitch: 12 ms.

Casi 5 veces más rápido en este caso.

Optimización de la evaluación de condiciones | vtortola.NET

Crossposting desde ElBruno.com

CLR String Interning

vtortola — Fri, 05 Oct 2007 02:31:55 GMT

Un String, es un tipo de referencia especial llamado inmutable, que quiere decir que el dato almacenado en el heap no se puede cambiar, cuando asignamos un nuevo valor a una variable de este tipo, un nuevo dato es generado en otra posición del heap y su dirección de memoria asignada a dicha variable, el dato anterior queda listo para ser GarbageCollected. Bien, pues este comportamiento que ... a unos les gusta más... a otros menos... se ideó así para evitar condiciones de anticipación en entornos multithreading tanto por motivos de consistencia como de seguridad, y tiene la evidente desventaja del engorro de memoria y trabajo extra para el GC que provoca.

El String Interning es una técnica de optimización que aplica el CLR sobre los String, que consiste en que los literales de este tipo de nuestro dominio de aplicación, son almacenados en un HashTable interno, de forma que si dos variables tienen el mismo valor y este ha sido internado, ambas variables apuntan a la misma referencia. Esto es facilmente comprobable con este simple código:

String s1 = "Darker than BLACK";

String s2 = "Darker than BLACK";

Console.WriteLine(Object.ReferenceEquals(s1, s2)); // True

Ó por ejemplo:

String s1 = "Darker than BLACK";

Console.WriteLine(Object.ReferenceEquals(s1, "Darker than BLACK")); // True

Este proceso de internamiento se lleva a cabo por el JIT de forma dinámica, y como decía, solo sobre los literales, si el String es el resultado de una operación no es internado:

String s1 = "Darker than BLACK";

StringBuilder sb1 = new StringBuilder("Darker than BLACK");

Console.WriteLine(Object.ReferenceEquals(s1, sb1.ToString())); // False

Igual pasa con el resto de operaciones...

String s1 = "Darker than BLACK";

Console.WriteLine(Object.ReferenceEquals(s1, "Darker than"+" BLACK")); // True

Oh Wait! Que sucede aquí? Pues que el CLR como siempre, optimizando al máximo, entiende esa concatenación de literales como un literal tal cual porque inevitablemente va a resultar en dicho dato jejeje, ... un poco más dificil:

String s1 = "Darker than BLACK";

String s2 = String.Empty;

foreach (char c in s1) s2 += c;

Console.WriteLine(Object.ReferenceEquals(s1, s2)); // False

Podemos insertar directamente un String en la tabla de internados mediante el método String.Intern que nos devolverá un String apuntando al dato internado, si no existiese lo crea:

String s1 = "Darker than BLACK";

String s2 = String.Empty;

foreach (char c in s1) s2 += c;

Console.WriteLine(Object.ReferenceEquals(s1, s2)); // False

s2 = String.Intern(s2);

Console.WriteLine(Object.ReferenceEquals(s1, s2)); // True

Cabe destacar, que los String que añadamos a dicha tabla, no pueden ser recolectados por el GC hasta que se descargue el AppDomain, con lo que indica que habrá objetos inmortales en el heap hasta entonces ocupando memoria.

Además, añadir elementos a la tabla de internados también tiene su coste en rendimiento, pero un uso intencionado de esta característica puede mejorar mucho el rendimiento si se aprovecha bien, ya que podriamos realizar comparaciones de Strings con Object.ReferenceEquals en lugar de String.Equals(==), ya que el primero es más rápido al simplemente comparar las referencias, mientras que el segundo primero para saberlo evalua el número de caracteres y si coincide también caracter a caracter, pero claro, esto en el caso de que trabajemos siempre con los mismos String y esten todos internados :P

También podemos simplemente consultar si un String ha sido internado con el método String.IsInterned, que devuelve el String internado en caso de que sí, y nulo en caso de que no:

StringBuilder sb1 = new StringBuilder();

sb1.AppendFormat("{0} is {1}", "Hei", "BK201");

Console.WriteLine(String.IsInterned(sb1.ToString())==null); // True

Console.WriteLine(String.IsInterned("BK201") == null); // False

En el CLR 2.0, este comportamiento es por defecto, y aunque existe el atributo CompilationRelaxations que permitiria anularlo ... el CLR ~~se caga en él~~ lo ignora. En cualqueir caso no se debe desarrollar dando por hecho este comportamiento ya que en futuras versiones del CLR podría cambiar.

Ventaja? Desventaja? Verdaderamente es algo engorroso. Por un lado se suele recomendar no trabajar nunca con String harcodeados (literales) en nuestro código, y por otro siempre que se trabaja con Strings se suele realizar operaciones con ellas por lo que es dificil asegurar que un String a evaluar este internado. Aunque es cierto que como comentaba antes podamos sacar partido a esta funcionalidad en algunas ocasiones contadas, por ejemplo si obtenemos de una BD una serie de cadenas de texto que no van a ser alteradas durante la ejecución y solo se utilizan como referencia de comparación ... podemos sacar partido a Object.ReferenceEquals para su evaluación.

Y después de este largo post, que no tiene más utilidad que ser una curiosidad insana del CLR, aún te quieres devanar los sesos un poco más ... realmente ... ¿el método String.IsInterned funciona bien?

String s1 = "Black Shinigami";

StringBuilder sb = new StringBuilder("Black Shinigami");

String s2 = sb.ToString();

Console.WriteLine(String.IsInterned(s1) != null); // True

Console.WriteLine(String.IsInterned(s2) != null); // True

Console.WriteLine(Object.ReferenceEquals(s1, s2)); // False

Según este código, el CLR entiende que s1 y s2 estan internados, pero realmente solo lo esta s1, aunque s2 contiene un dato internado ... la posición del heap a la que apunta dicha variable no es la que esta internada ... ¿que sucede? Pues ya que en los foros del MSDN ~~no saben~~ no entienden mi inglés xD ... la solución me la ha dado el fabuloso libro CLR via C#, donde se explica que el HashTable de las String internadas, usa el dato como key y la dirección de memoria del dato internado como valor, lo que explica que el CLR busca el dato contenido en s2 como clave en el HashTable y obtiene la dirección de memoria en el heap de s1, que es la que devuelve exactamente ... sabiendo esto podemos usar un método mejor:

static Boolean IsThisInterned(String str)

  return Object.ReferenceEquals(String.IsInterned(str), str);

Ya finalizando, aclarar que el String Pooling es una técnica similar pero distinta, que aplica el compilador a las Strings cuando genera los metadatos, de forma que si hay varias Strings literales con el mismo dato en el código fuetne, se introduce una sola vez en los metadatos y todas apuntan a esta. De esta forma se reduce el tamaño final del ensamblado. Esto es algo que ya hacían de forma parecida los compiladores de C/C++.

Como nota final diré que si, que me encanta de Darker Than BLACK :D, de hecho me estoy descargando ahora mismo el último episodio, algo triste pero impacientemente esperado a la vez.

Hasta otro capítulo de cosas que valen para poco.

CLR String Interning | vtortola.NET

Crossposting desde ElBruno.com

Se publicarán las fuentes de la BCL de .NET

vtortola — Thu, 04 Oct 2007 12:53:00 GMT

Gran noticia que me llega a través del correo de Avanade, Releasing the source code for the .NET Framework Libraries :D

Iran incluidas en la salida de .NET 3.5 y VS2008, aunque es posible que esten disponibles para descarga en breve. Se publican bajo la licencia opensource de Microsoft MS-RL.

Se comenzará con la publicación de:

NET Base Class Libraries
- System
- System.IO
- System.Collections
- System.Configuration
- System.Threading
- System.Net
- System.Security
- System.Runtime
- System.Text
ASP.NET
- System.Web
Windows Forms
- System.Windows.Forms
ADO.NET
- System.Data
XML
- System.Xml
WPF
- System.Windows

En el artículo se ven instrucciones para integrar el depurado con VS2008 de forma que se pueda seguir la pila de llamadas a través de estas fuentes.

"Tener acceso al código fuente e integración con el depurador de las librerias del .NET Framework será realmente valioso para los desarrolladores en .NET. Ser capaz de avanzar instrucción a instrucción y revisar el código fuente proporciona una mejor idea de como las librerias están implementadas y permite a los desarrolladores construir mejores aplicaciones e incluso hacer un mejor uso de dichas librerias."

Más info también en el blog de Shawn Burke.

Se publicarán las fuentes de la BCL de .NET | vtortola.NET

Crossposting desde ElBruno.com

Medir la velocidad de un Stream

vtortola — Fri, 28 Sep 2007 22:42:46 GMT

Cosilla curiosa que nunca había hecho antes, medir la velocidad de lectura de un Stream, por ejemplo para saber a que velocidad en Bytes/s descargamos de un NetworkStream, ó de un FtpDataStream, ó para saber como de rápido lee nuestro disco duro ... ya sea con fines meramente estadísticos ó para encontrar el tamaño de buffer adecuado ... Es un procedmiento muy sencillo, se trata de dividir los bytes descargados entre los milisegundos transcurridos (cuantos bytes por milisegundo) y multiplicarlo por 1000 (un segundo). Para ello nos apoyamos en la clase para realizar mediciones de tiempo con precisión, StopWatch.

En este ejemplo de una descarga FTP, tenemos un FtpDataStream de donde leemos los datos y un FileStream donde los guardamos. Se podría hacer con practicamente cualquier Stream. Adicionalmente declaramos una variable global a la clase Int64 donde almacenar la cantidad de Bytes leidos y un StopWatch global también para poder consultarlos desde otros métodos:

private Stopwatch downloadStopWatch = new Stopwatch();

private Int64 downloadedBytes=0;

Cuando vamos a iniciar la lectura, iniciamos el StopWatch y vamos incrementando los bytes leídos:

using (FileStream fs = new FileStream(this.localDirectory,

       FileMode.Create,FileAccess.Write, FileShare.None))

using (Stream strm = ftp.GetResponse().GetResponseStream())

  // Inicio el cronómetro

  downloadStopWatch.Start();

  contentLen = strm.Read(buff, 0, this.bufferLength);

  // Incremento los bytes leidos.

  downloadedBytes += contentLen;

  while (contentLen != 0)

    fs.Write(buff, 0, contentLen);

    contentLen = strm.Read(buff, 0, this.bufferLength);

    // Incremento los bytes leidos.

    downloadedBytes += contentLen;

  // Paro el cronómetro.

  downloadStopWatch.Stop();

Cuando queramos saber la velocidad, por ejemplo en KBytes/s podemos invocar a un metodo/propiedad-get tal que así:

public Single DownloadSpeed

get

    Double bytesPerSecond;

try

      bytesPerSecond = (this.downloadedBytes /

                        downloadStopWatch.ElapsedMilliseconds) * 1000;

    catch (DivideByZeroException)

      // El StopWatch marcaba 0 milisegundos.

      bytesPerSecond = this.downloadedBytes;

    return (Single)(bytesPerSecond / 1024);

Nota: Ojo, se puede dar el caso de que consultemos la velocidad y la descarga no se haya iniciado aún ... ó que ni siquiera haya pasado 1ms ... por lo que debemos controlar la división por cero y devolver en dicho caso los bytes transferidos hasta el momento, que serán 0 si la descarga no ha comenzado y X si ha comenzado ya :D ... Yo siempre me pongo en el peor de los supuestos por si acaso !!!! xD

Medir la velocidad de un Stream | vtortola.NET

Crossposting desde ElBruno.com

Evaluando el modelo

vtortola — Wed, 19 Sep 2007 03:04:54 GMT

Antes de empezar a desarrollar una aplicación, es conveniente revisar el diseño lógico para asegurar que es esta completo y correcto. Esto viene a ser evaluar el diseño en los siguientes terminos:

Evaluación de ejecución:
- Rendimiento.
- Escalabilidad.
- Disponibilidad.
- Recuperación.
- Seguridad.
Evaluación de la arquitectura:
- Mantenibilidad.
- Extensibilidad.
Evaluación de los requerimientos:
- Casos de uso.

La evaluación del rendimiento determina la velocidad de ejecución de la aplicación. Desde el diseño lógico, tiene dos puntos fundamentales:

Las capas: Asegurar que no se ha dividido en demasiadas capas. Normalmente 3 son suficientes, aunque puede necesitarse más si existen motivos razonables.
Los niveles de abstracción: Hay que evitar niveles de abstracción innecesarios en las clases. Un abuso podría producir una perdida de rendimiento al forzar al flujo de ejecución a pasar por demasiados objetos.

A nivel de diseño lógico, evaluar el rendimiento queda limitado a la búsqueda y supresión de redundancias.

La evaluación de la escalabilidad determina la capacidad de la aplicación para adaptarse al aumento de carga y/ó número de usuarios. Es importante asegurar que dispone de una ó varias capas intermedias separadas, de forma que dichas capas puedan ser puestas en otras máquinas, como por ejemplo en un servidor de gran capacidad mediante Remoting.

La evaluación de la disponibilidad y recuperación determina la capacidad de la aplicación para recuperarse y tomar contramedidas en situaciones catastróficas. Es importante asegurar que las clases pueden:

Usar transacciones fiables, ya sean de base de datos, MSMQ, System.EnterpriseServices, DTC, ...etc... De forma que en caso de falla no quede una operación colgada a mitad de realizarse.
Reconstruir archivos de datos y configuración corruptos por un fallo de continuidad en el hardware, como una perdida de alimentación.
Tomar fuentes de datos ó servicios redundantes en caso de perdidas de conectividad ó fallos del hardware remoto.

La evaluación de la seguridad determina la capacidad de la aplicación para proteger "sus secretos" (contraseñas, cadenas de conexión, datos sensibles, ..etc..). Los pilares fundamentales son:

Autenticación: Solicitar que el usuario se autentique para poder usar la aplicación, por ejemplo a través de 'Active Directory' ó un sistema propio de contrastar usuarios/contraseñas. Es importante que si se usa un sistema propio, no se almacenen las contraseñas si no sus Hash.
Cifrado: Asegurar que los datos sensibles que necesariamente se han de guardar en disco, solo puedan ser usados por el usuario que los creo. Por ejemplo, usando la DPAPI. Se debe reducir al máximo el guardado de archivos temporales con datos sensibles. Crear un almacenamiento aislado es una buena opción para ello.
SQL-Injections: Asegurar que desde ningún formulario de la aplicación ó punto visible se puede realizar una injección de código SQL. La mejor forma de evitar esto es usando parámetros para construir las sentencias SQL.
Auditoria: Se debe auditar los procesos de autenticación y autorización, de forma que podamos comprobar si hay usuarios intentando acceder a datos protegidos ó intentando autenticarse por fuerza bruta.
Firmar los ensamblados con nombres seguros para que solo el autor original de la aplicación pueda substituirlos.

La evaluación de la mantenibilidad determina la facilidad con la que la aplicación podrá se mantenida una vez puesta en producción. Siguiendo un diseño en capas y modular se asegura que los cambios podrán realizarse substituyendo piezas de la aplicación y no la aplicación entera.

La evaluación de la extensibilidad determina si el código de la aplicación es rehusable ó si se puede implementar con soluciones ya hechas, bien en el .NET Framework ó de nuestra propia empresa. Usando código ya existente aseguramos que utilizamos cosas ya probadas y ahorramos costes de desarrollo.

La evaluación de la integridad de los datos determina dos cosas:

La capacidad de la aplicación para mantener los datos acorde al esquema de la fuente, de forma que se respeten resticiones, tipos y contratos, asegurando así que la fuente no rechazará los datos cuando le sean enviados.
La capacidad de la aplicación para lidiar con la concurrencia de los datos. Existen dos tipos de concurrencia:
- Optimista: Los datos no se bloquean mientras estan siendo leidos por otro usuario. Mejor rendimiento pero se tiene el riesgo de que los datos cambien mientras están siendo leidos, y podrían tomarse decisiones erróneas.
- Pesimista: Los datos se bloquean mientras están siendo leidos por otro usuario. Peor rendimiento pero asegura que cuando un usuario lee un dato, ese dato no cambiará hasta que termine de trabajar con él.

La evaluación de los casos de uso determina si la aplicación sigue cumpliendo con los requerimientos. Se intenta buscar inconsistencias ó ambiguedades en el diseño lógico.

Resumen de la lección 3.1 del libro oficial de Microsoft para obtener el MCPD:WinApps.

Evaluando el diseño | vtortola.NET

Crossposting desde ElBruno.com

Creando modelos para desarrolladores

vtortola — Mon, 17 Sep 2007 01:21:22 GMT

Siguiendo con el tema del modelado del software en capas, es el turno de crear modelos físicos más precisos para los programadores que han de escribir el código. Los modelos físicos indican como los programadores deberían desarrollar la aplicación.

Un diagrama de componentes indica los componentes ó paquetes de los que se compondrá la aplicación y las dependencias de estos. Un componente es un conjunto de clases relacionadas formando una unidad distribuible, como una DLL, un control ó un Webservice. Los componentes se representan por rectangulos con dos pequeños rectangulos a su izquierda, en el nombre se indica la capa a la que pertenecen separados con dos dobles puntos ('::'). Otros rectangulos mayores que agrupan varios componentes simbolizan un contenedor de distribución llamado nodo, que suele indicar una separación física, como estar en distinto hardware.

Los diagramas de clases definen las estructura de las clases y las relaciones entre ellas desde el punto de vista de la programación orientada a objetos, sin especificar como interactuan entre ellas, solo un modelo estático. Este modelo que es independiente de la tecnología y lenguaje usado, representa las clases, sus propiedades, métodos, interfaces, herencia, asociaciones, tipos de datos y demás. Las clases deben derivar de la arquitectura propuesta para la solución.

Los diagramas de secuencia muestran como los objetos intearactuan entre ellos durante la ejecución, muestra el tiempo de vida de dicho objetos y los mensajes intercambiados entre ellos. Los objetos se representan como rectangulos en lo alto del diagrama con lineas verticales donde se representa su tiempo de vida y horizontales representando el envio de mensajes a otros objetos.

Un diagrama de colaboración muestra el mismo tipo de interacción que el anterior solo que permite distribuirlo todo de una forma más libre, indicando el orden de los mensajes mediante una numeración.

Un diagrama de actividad ó flujo representa el flujo de ejecución y permite mostrar actividades que suceden de forma paralela (ó multithreading). Se usan para representar algorritmos más complejos.

El pseudo-código no es un diagrama, ni es un lenguaje específico, es una forma de representar el código que ha de realizar el programador de una forma representativa. Es una forma rápida y fácil para los arquitectos y analistas de expresar conceptos a los programadores. Es como cada uno quiera hacerlo, ya sea por facilidad para si mismo ó por facilidad para quien tiene que interprestarlo.

Resumen de la lección 2.3 del libro oficial de Microsoft para obtener el MCPD:WinApps.

Creando modelos para desarrolladores | vtortola.NET

Crossposting desde ElBruno.com

DbTransaction, transaciones en un Db Factory

vtortola — Sun, 16 Sep 2007 21:08:02 GMT

Siguiendo con el tema del DbFactory con las clases de System.Data.Common, que permiten trabajar con cualquier base de datos de la que tengamos un proveedor en .NET, explicaré la clase DbTransaction, el cual permite realizar transacciones en la base de datos (explicación más completa en la versión en inglés).

Una transacción es una operación formada por un grupo de operaciones relacionadas, cada una podría requerir varias operaciones de lectura y/ó escritura en la base de datos, y solo tiene validez si se ejecutan todas. En caso de producirse un error en el transcurso de la transacción, ha de ser posible “deshacer” todas las operaciones anteriores (rollback), en caso contrario se da por finalizada la transacción aplicando los cambios (commit).

Por ejemplo, en un traspaso de dinero entre dos cuentas del mismo banco, la operación incluye primero la substracción del dinero de la cuenta A y su ingreso en la cuenta B, imaginemos que la substracción se realiza correctamente pero hay un error a la hora de ingresar la cantidad en B, en este caso el dinero no quedaría ni en una cuenta ni en otra y podría hasta “perderse”; si esta operación se ejecuta como una transacción, al fallar el ingreso en B, automáticamente se revertiría la substracción en A, con lo que ambas cuentas volverían a quedar en el mismo estado que antes de ejecutarse dicha transacción.

Siguiendo con el ejemplo anterior en DbFactory y volviendo a usar la misma base de datos de ejemplo Northwind que viene incluida en SQL Server 2005 Express, en este ejemplo se realizará la inserción de 5 nuevos empleados como una transacción, si todo funciona correctamente se realizará un DbTransaction.Commit() que finalizaría la transacción guardando los datos, mientras que si en el transcurso de la operación se produjese alguna excepción, se ejecutaría DbTransaction.Rollback() devolviendo a la tabla a su estado original. A partir de este código probad a introducir errores en las sentencias SQL para ver como al saltar una DbException se realiza un rollback.

string provider = ConfigurationManager.ConnectionStrings["SQLServer"].ProviderName;

string connectionString = ConfigurationManager.ConnectionStrings["SQLServer"].ConnectionString;

// Sentencia SQL

string insertEmployee =

  "INSERT INTO EMPLOYEES (EmployeeID, LastName, FirstName) VALUES ({0}, ‘{1}’, ‘{2}’)";

// Obtengo el proovedor.

DbProviderFactory dbpf = DbProviderFactories.GetFactory(provider);

// Creo la conexión y el comando.

using (DbConnection dbcon = dbpf.CreateConnection())

using (DbCommand dbcmd = dbcon.CreateCommand())

// Configuro la conexión

dbcon.ConnectionString = connectionString;

try

  // Abro la conexión

  dbcon.Open();

  // Inicio la transación

  dbcmd.Transaction = dbcon.BeginTransaction();

  // Si os falla al insertar filas probad esto:

  dbcmd.CommandText = "SET IDENTITY_INSERT Employees ON";

  dbcmd.ExecuteNonQuery();

  ////

  // Inserto a los nuevos empleados

  dbcmd.CommandText = string.Format(insertEmployee, 10, "Simpson", "Homer");

  dbcmd.ExecuteNonQuery();

  dbcmd.CommandText = string.Format(insertEmployee, 11, "Szyslak", "Moe");

  dbcmd.ExecuteNonQuery();

  dbcmd.CommandText = string.Format(insertEmployee, 12, "Carlson", "Karl");

  dbcmd.ExecuteNonQuery();

  dbcmd.CommandText = string.Format(insertEmployee, 13, "Leonard", "Lenny");

  dbcmd.ExecuteNonQuery();

  dbcmd.CommandText = string.Format(insertEmployee, 14, "Gamble", "Barney");

  dbcmd.ExecuteNonQuery();

  // No ha saltado ninguna excepción,

  // todo ha ido bien, hago commit y salvo la operación.

  dbcmd.Transaction.Commit();

  Console.WriteLine("Transacción OK!");

catch (DbException dbex)

  // Algo salío mal, deshago la transacción.

  dbcmd.Transaction.Rollback();

  Console.WriteLine(dbex.Message);

Nota: Aunque en el ejemplo se componen las SQL "a pelo" por brevedad, lo recomendable es usar parámetros con DbParameter.

DbTransaction, transaciones en un Db Factory | vtortola.NET

Crossposting desde ElBruno.com

DbParameter.

vtortola — Sun, 16 Sep 2007 20:56:14 GMT

Para evitar problemas de seguridad en ADO.NET 2.0 es recomendable componer las sentencias SQL a base de parámetros en lugar de construir las cadenas manualmente en base a las propiedades .Text de los controles u otros orígenes. De esta forma evitamos fallos de seguridad potenciales (ie: SQL Injection) y otros problemas menores. Siguiendo con nuestra DB Factory donde mostré como utilizar la Fábrica de objetos de ADO.NET 2.0 para construir objetos que pueden manejar cualquier base de datos, ahora le toca el turno a la clase DbParameter para añadir parámetros a las sentencias SQL de nuestra DB Factory.

[more]

DbParameter, también es una clase abstracta de System.Data.Common que especializan todas las clases con las que estamos más acostumbrados a trabajar, como SqlParameter, OracleParameter, … etc.. Por lo que seguimos con las mismas ventajas y pegas que las que tenemos en general con Db Factory, la ventaja de la gran versatilidad y la desventaja de no poder acceder a las propiedades especializadas de la clase derivada, ambas causadas por el polimorfismo

El ejemplo, que usa los mismos datos de conexión y BD que el artículo sobre DbFactory, representa como insertar un trabajador en la tabla 'Employees':

string provider = ConfigurationManager.ConnectionStrings["SQLServer"].ProviderName;

string connectionString = ConfigurationManager.ConnectionStrings["SQLServer"].ConnectionString;

// Sentencia SQL

string insertEmployee =

  "INSERT INTO EMPLOYEES (EmployeeID, LastName, FirstName) VALUES (@ID, @LNAME, @NAME)";

// Obtengo el proovedor.

DbProviderFactory dbpf = DbProviderFactories.GetFactory(provider);

// Creo la conexión y el comando.

using (DbConnection dbcon = dbpf.CreateConnection())

using (DbCommand dbcmd = dbcon.CreateCommand())

  // Configuro la conexión

  dbcon.ConnectionString = connectionString;

try

      Console.WriteLine("Ejecutando SQL con un obteto de tipo {0}.",

                         dbcon.GetType().Name);

      // Abro la conexión

      dbcon.Open();

      // Si os falla al insertar filas probad esto:

      dbcmd.CommandText = "SET IDENTITY_INSERT Employees ON";

      dbcmd.ExecuteNonQuery();

      ////

      dbcmd.CommandText = insertEmployee;

      // Parámetros

      DbParameter dbparam = dbcmd.CreateParameter();

      dbparam.DbType = DbType.String;

      dbparam.ParameterName = "NAME";

      dbcmd.Parameters.Add(dbparam);

      dbparam = dbcmd.CreateParameter();

      dbparam.DbType = DbType.String;

      dbparam.ParameterName = "LNAME";

      dbcmd.Parameters.Add(dbparam);

      dbparam = dbcmd.CreateParameter();

      dbparam.DbType = DbType.Int32;

      dbparam.ParameterName = "ID";

      dbcmd.Parameters.Add(dbparam);

      // Inserto a los nuevos empleados

      dbcmd.Parameters["NAME"].Value = "Valeriano";

      dbcmd.Parameters["LNAME"].Value = "Tortola";

      dbcmd.Parameters["ID"].Value = 15;

      dbcmd.ExecuteNonQuery();

      // No ha saltado ninguna excepción,

      // todo ha ido bien. También podríamos

      // haberlo hecho como una transación :)

      Console.WriteLine("Inserción OK!");

    catch (DbException dbex)

      Console.WriteLine(dbex.Message);

DbParameter.| vtortola.NET

Crossposting desde ElBruno.com

Localizar carpetas especiales de Windows

vtortola — Sun, 16 Sep 2007 03:48:14 GMT

Esto lo ví una vez y a raiz de una pregunta en el foro lo busqué de nuevo. Se trata de como localizar las rutas a las carpetas especiales de Windows desde .NET, aunque existe una variable de entorno %homepath% apuntando a nuestra carpeta personal en el sistema, no hay ninguna para llegar a carpetas como 'Escritorio', 'Mis Imágenes', 'Mi Música', ... etc ... y dependiendo del idioma en el que este el sistema operativo, pueden llamarse 'Desktop', 'My Pictures', 'My Music', ...etc...

Existe una enumeración System.Environment.SpecialFolder que apunta a dichas carpetas, para obtener la ruta se usa el método System.Environment.GetFolderPath:

//Obtengo la ruta de "Mis Imágenes"

String ruta = Environment.GetFolderPath(Environment.SpecialFolder.MyPictures);

Las rutas especiales que podemos encontrar son (sacado del MSDN):

ApplicationData: Directorio que sirve de repositorio común de datos específicos de la aplicación para el usuario móvil actual.
CommonApplicationData: Directorio que sirve de repositorio común de datos específicos de la aplicación que todos los usuarios utilizan.
CommonProgramFiles: Directorio de componentes que se comparten entre distintas aplicaciones.
Cookies: Directorio que sirve de repositorio común para las cookies de Internet.
Desktop: El escritorio lógico en vez de la ubicación física del sistema de archivos.
DesktopDirectory: Directorio que se utiliza para almacenar objetos de archivo físicamente en el escritorio.
Favorites: Directorio que sirve de repositorio común para los elementos favoritos del usuario.
History: Directorio que sirve de repositorio común para los elementos del historial de Internet.
InternetCache: Directorio que sirve de repositorio común para los archivos temporales de Internet.
LocalApplicationData: Directorio que sirve de repositorio común para datos específicos de la aplicación que el usuario no móvil actual utiliza.
MyComputer: La carpeta "Mi PC". La constante MyComputer siempre produce una cadena vacía ("") porque no hay ninguna ruta de acceso definida para la carpeta Mi PC.
MyDocuments: La carpeta "Mi PC".
MyMusic: La carpeta "Mi música".
MyPictures: La carpeta "Mis imágenes".
Personal: Directorio que sirve de repositorio común para documentos.
ProgramFiles: Directorio de archivos de programa.
Programs: Directorio que contiene los grupos de programas del usuario.
Recent: Directorio que contiene los documentos utilizados más recientemente por el usuario.
SendTo: Directorio que contiene los elementos de menú Enviar a.
StartMenu: Directorio que contiene los elementos de menú Inicio.
Startup: Directorio que se corresponde con el grupo de programas Inicio del usuario.
System: Directorio del sistema.
Templates: Directorio que sirve de repositorio común para plantillas de documentos.

Localizar carpetas especiales de Windows | vtortola.NET

Crossposting desde ElBruno.com

Los pools de programadores

vtortola — Sat, 15 Sep 2007 05:37:48 GMT

Me gusta todo lo relacionado con IT, puedo construir lo que que quiera, mi herramienta es un ordenador y mis materias primas la imaginación y el conocimiento, el límite esta en cuanto puedo aprender, eso me hace sentirme... bien. Empece en telecomunicaciones, pasé a sistemas y fortuitamente empecé a programar con VB6 y después con Delphi, cuando descubrí C# y .NET decidí dedicarme únicamente a ello pues me encantaba, me resultaba creativo y divertido. Llevo escasos dos años en el mundo del desarrollo en continuo avance para mejorar, pero últimamente estoy algo desmoralizado pues después de haber estado este tiempo desarrollando en plan "ágil", ahora he chocado frontalmente con los conceptos de software factory y pool de programadores, formas de convertir el desarrollo en una cadena de montaje sin sentido supuestamente en pos de la máxima productividad y a mi parecer en decrimento de la calidad, la innovación y la creatividad, formas que ya no me parecen divertidas ni motivadoras.

Verdaderamente pienso que el único propósito de estos 'pools' es convertir a los programadores en partes facilmente intercambiables de un equipo. Un equipo de desarrollo ágil es reducido pero necesita buenos profesionales, que cobrán más ó se ha invertido tiempo/dinero en formarlos, y que el día que deciden irse causan un verdadero problema pues no son piezas facilmente reemplazables. Sin embargo en un pool tienes unos pocos analistas y muchos programadores nóveles totalmente reemplazables. En el mejor de los casos con miras a ser analistas también en el futuro lejano, pues no se llega a analista codificando los diseños de otros, si no trabajando con los analistas y haciendo algo de vez en cuando, aunque sea pequeño. En el peor de los casos subcontratados, en outsourcing ó cualquier otro termino relacionado con el body shopping con la esperanza de que la empresa anfitriona los ponga en plantilla después de 6 ó 12 meses, ó quizás nunca.

Frecuentemente leo el blog de Rodrigo Corral, que escribe mucho sobre metodologías ágiles como Scrum y acabo de leer un post sobre los pools de programadores digno de elogio, no hay una sola frase en ese post con la que no este de acuerdo, me ha hecho recordar "a que vine a .NET" y en cierta forma ... recuperar un poco el ánimo al ver que no me equivoqué, si no que simplemente estoy donde no debo estar.

No puedo añadir nada más a su genial artículo, recomiendo su lectura.

Los pools de programadores | vtortola.NET

Crossposting desde ElBruno.com

Modelado en capas.

vtortola — Fri, 14 Sep 2007 01:45:36 GMT

El modelado en capas de un sistema representa como se planea dividir el código en partes lógicas ó grupos. La abstracción del código en capas permite mejorar, reparar y reemplazar partes de la aplicación de forma sencilla y sin que afecte a las demás. Además provee una representación lógica y clara de la aplicación.

El modelo en capas más comun es el de tres capas, presentación, lógica de negocio y base de datos. El model n-capas extiende este modelo de forma que cualquier capa puede dividirse en subcapas, aportando así mayor claridad.

La capa más alta es en la que se interactua con el usuario, la capa más baja donde los datos son almacenados/recuperados y las capas intermedias son las encargadas de realizar el procesado de datos, el movimiento de estos de la base de datos al usuario y el control del estado de la aplicación.

El número de capas que ha de tener una aplicación viene definido por los requerimientos de calidad de servicio, a más altos y exigentes, más capas, pero esto también aumenta el tiempo de desarrollo.

Las capas que comunmente pueden conformar una aplicación Windows son:

Interfaz de usuario: Provee la interfaz con la que interactua el usuario. Es responsable de obtener datos de la capa siguiente, mostrarlos, validar entradas de datos, enviarlos a la siguiente capa. Puede dividirse en:
- Pesentación: Define únicamente la parte de presentación de la interfaz de usuario. Normalmente esta en los archivos *.Designer.cs.
- Código de la interfaz de usuario: Donde los programadores ubican el código para interactuar con la interfaz de usuario respondiendo a eventos.
- Código de interacción con la lógica de negocios (Business Façade): Esta capa podría usarse para separar totalmente la intefaz de usuario de la lógica de negocio, de forma que podría ser facilment substituible.
Capa Intermedia: Donde se ubica la lógica de negocio, aunque también suele incluir cosas como cacheo de datos, registro de actividad, gestión de errores ... etc.... Enterprise Library es un ejemplo de esto. Puede dividirse en:
- Capa de negocios: En esta capa se ubican los objetos de dominio y sus reglas de negocio, formados por componentes carentes de estado (stateless) que trabajan con System.EnterpriseServices, objetos que son pequeños programas para procesar información, DTOs a través de Remoting, ..etc..
- Capa de aplicación (ó Servicios de aplicación): Es la capa de mantenimiento general, se encarga normalmente de los requerimientos de calidad de servicio, como las caches, la gestión de excepciones, rendimiento, ..etc.. Enterprise Library es un ejemplo de este tipo de capa.
- Capa de acceso a datos (ó Servicios de datos): Abstrae la obtención y almacenamiento de datos en la base de datos. Una forma de aislarse más de la Capa de datos real.
Capa de datos: Representa como se gestionan los datos en la base de datos a través de la aplicación. Normalmente es una base de datos relacional como SQL Server.
- Capa de acceso a datos: Igual que la capa de datos de la base intermedia.
- Procedimientos almacenados: Representa los procedimientos almacenados nativos ó administrados con los que se manejan datos en la base de datos.
- Servicios de integración: Representa como la base de datos trabaja con otras fuentes de datos.
- Tablas, logs y indices de la base de datos: Los datos en la base de datos.

Una vez definidas las capas es importante ubicarlas bien dependiendo de la arquitectura del sistema y los requerimientos. Por ejemplo, si nuestra aplicación será un SmartClient que se distribuye por internet y no puede acceder directamente a la base de datos, podemos hacer que el cliente conecte a la capa de negocios de un servidor mediante, por ejemplo, Remoting, de forma que la parte servidor pueda validar todas las entradas/salidas de la BD.

Resumen de la lección 2.2 del libro oficial de Microsoft para obtener el MCPD:WinApps.

Modelado en capas. | vtortola.NET

Crossposting desde ElBruno.com

vtortola

Recorrer una estructura en arbol con multiples hilos: ThreadedTreeBase

Recorrer una estructura en arbol con m&#250;ltiples hilos

Cliente FTP as&#237;ncrono

Extendiendo un ProgressBar. FlatProgressBar.

Optimizaci&#243;n de la evaluaci&#243;n de condiciones

CLR String Interning

Se publicar&#225;n las fuentes de la BCL de .NET

Medir la velocidad de un Stream

Evaluando el modelo

Creando modelos para desarrolladores

DbTransaction, transaciones en un Db Factory

DbParameter.

Localizar carpetas especiales de Windows

Los pools de programadores

Modelado en capas.

Recorrer una estructura en arbol con múltiples hilos

Cliente FTP asíncrono

Optimización de la evaluación de condiciones

Se publicarán las fuentes de la BCL de .NET