IDisposable Thoughts

Honey… where is my coding t-shirt?

Hey there! Thanks for dropping by Theme Preview! Take a look around
and grab the RSS feed to stay updated. See you around!

Posts Tagged ‘development’

.NET y Configuraciones – Parte 8

La última vez que conversamos acerca de configuraciones sacamos a relucir lo sencillo que es agregar soporte para funciones de validación callback, y antes de eso comentábamos lo sencillo que era agregar soporte para validación de forma declarativa usando los atributos de validación incluídos en la Configuration Framework de la .Net Framework.

Hoy seguiremos caminando en el soporte de validación customizada de secciones y elementos de validación, pero esta vez creando nuestros propios atributos de validación customizados.

Atributos de Validación

Un atributo de validación nos permite validar los elementos o secciones de nuestra configuración de .Net, simplemente tenemos que adornar ese elemento con el atributo en cuestión. La .Net framework nos incluye algunos atributos ya dentro de la caja, pero podemos agregar los nuestros propios de forma sencilla.

Realmente un atributo de validación costa de dos clases: La clase que marca el atributo (un atributo marcador) y la clase que ejecuta la acción de validar (el validador). Como podremos notar en este lado de la framework se utilizan los atributos de una manera muy particular (y que en lo personal me gusta) de mezclar el atributo como marcador pero no como ejecutor.

Usemos un simple ejemplo, imaginemos que necesitamos validar la entrada de correos electrónicos, como todos sabemos, podemos seguir un par de reglas expuestas en una serie de RFC’s acerca de direcciones de email. Bueno, comencemos por la clase que hace realmente la validación, esta debe heredar de la clase ConfigurationValidatorBase y luego el override de los métodos CanValidate (que nos dice si podemos o no validar el tipo en cuestión) y Validate (quien realmente realiza la validación).

using System;
using System.Configuration;
using System.Text.RegularExpressions;

namespace Cprieto.Samples {
    public class EmailValidator : ConfigurationValidatorBase {
        private const string Word = "[^\\x00-\\x1F^\\(^\\)^\\<^\\>^\\@^\\,^\\;^\\:^\\\\^\\\"^\\.^\\[^\\]^\\s]";
        private const string IpEntry = "\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\]";
        private static readonly string Domain = string.Format("({0}+(\\.{0}+)*", Word);

        private static readonly Regex EmailRegex =
            new Regex(string.Format("^{0}+(\\.+)*@{1}|{2})$", Word, Domain, IpEntry), RegexOptions.Compiled);

        public override bool CanValidate(Type type) {
            return type == typeof (string);
        }

        public override void Validate(object value) {
            var item = (string) value;
            if (!string.IsNullOrEmpty(item) && !EmailRegex.IsMatch(item))
                throw new ArgumentException("value is not a valid email");
        }
    }
}

Bien, ahora simplemente creamos el atributo marcador, este debe heredar de ConfigurationValidatorAttribute y la parte importante de este es el override de la propiedad ValidatorInstance que retorna una nueva instancia de nuestra clase validadora.

using System.Configuration;

namespace Cprieto.Samples {
    public class EmailValidatorAttribute : ConfigurationValidatorAttribute {
        public override ConfigurationValidatorBase ValidatorInstance {
            get { return new EmailValidator(); }
        }
    }
}

Ahora simplemente lo aplicamos a nuestra sección de configuración:

using System.Configuration;

namespace Cprieto.Samples {
    public class SampleConfigurationSection : ConfigurationSection {
        [CallbackValidator(Type = typeof(PortValidator),
            CallbackMethodName = "Validate")]
        [ConfigurationProperty("port", DefaultValue = 80)]
        public int Port {
            get { return (int) this["port"]; }
        }

        [ConfigurationProperty("host", IsRequired = true)]
        public string Host {
            get { return (string) this["host"]; }
        }

        [EmailValidator]
        [ConfigurationProperty("email")]
        public string Email {
            get { return (string) this["email"]; }
        }
    }
}

Y claro, nunca cae de más un pequeño archivo de validación que debe marcar como inválido

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="sample"
             type="Cprieto.Samples.SampleConfigurationSection, Cprieto.Samples.ValidationCallback"/>
  </configSections>
  <sample port="80" host="localhost" email="invalid@@email" />
</configuration>

Bueno, y ahora me queda pensar que escribo para el siguiente post de la serie :) Hasta la próxima!

Cambiando el usuario de un commit en Mercurial

Hoy mi gran amigo José Romaniello (@jfroma) me abarcó con una pregunta acerca de Mercurial un poco curiosa pero bastante bien fundada:

Por un error anterior, necesito cambiar el nombre de usuario que aparece registrado en algunos commits de mi repositorio de Mercurial por otro usuario, cómo puedo hacerlo? ¿tengo que reescribir la historia del repositorio?

Digamos que al principio de mis commits utilizaba el nombre de Santa Clos (digamos que así estaba la máquina con que comencé a trabajar el proyecto) y luego decidí cambiar el nombre a mi correcto nombre de Cristian Prieto, bueno, si vemos el log de commits tendremos algo como lo siguiente:

Powershell-2010-07-06_19.20.15

Bueno, si quieren pueden intentar cambiar la historia con Hg mq, pero una manera mucho más sencilla si tienen su historial local es usar a nuestro amigo “Convert”.

Algunos creen que convert (la cual es una extensión de Mercurial incluida en la instalación) simplemente sirve para convertir de un sistema de control de versiones a otro (entiéndase de Subversion a Mercurial, como nos lo muestra nuestro amigo Fabio), la verdad también nos permite convertir de un repositorio de Mercurial a otro, y en el transcurso de la conversión cambiar los valores de cada uno de los commits, entre ellos, el author del commit. En este caso en particular basta con crear un archivo “authors” que contenga la lista de valores de conversión de los autores, es un simple archivo de texto con retorno de carro. En este caso tendremos un archivo con este simple contenido:

Santa Clos <santa@northpole.net>=Cristian Prieto <me@cprieto.com>

Ahora asegurémonos que tenemos nuestra extensión convert activada, revisen que en su Mercurial.ini tengan la siguiente línea

[extensions]
hgext.convert=

Y basta solamente convertir nuestros repositorios

hg convert --authors authors.txt orig changed

Bien, ahora si revisamos el historial nos quedaría bello, como esperábamos :)

Powershell-2010-07-06_19.28.20

Para saber un poco más acerca de convert, basta con la página del wiki de Mercurial :)

.NET y Configuraciones – Parte 7

Bueno, luego de un largo tiempo de ausencia creo que es hora de continuar con la serie acerca de configuraciones en la .NET Framework. La última vez que conversamos mencionamos la capacidad que tenía una sección de configuración de validar los elementos de configuración, esta capacidad es netamente declarativa a partir de atributos que indican el tipo de validación que debe llevarse a cabo. Como ustedes podrán imaginarse existirán situaciones donde es necesario realizar validaciones afuera de las que ya nos trae la configuration framework.

Existen dos formas de especificar o crear nuestras propias rutinas de validación de la configuración: mediante validation callback y utilizando custom validation attributes. Veremos ambas en esta serie y comenzaremos con la primera: validation callbacks

Validation Callbacks

Imaginemos el siguiente caso hipotético, nuestra sección de validación requiere que se ingrese el nombre o host de la aplicación y el puerto para ese host, la sección en cuestión se vería algo así:

using System.Configuration;

namespace Cprieto.Samples {
    public class SampleConfigurationSection : ConfigurationSection {
        [ConfigurationProperty("port", DefaultValue = 80)]
        public int Port {
            get { return (int) this["port"]; }
        }

        [ConfigurationProperty("host", IsRequired = true)]
        public string Host {
            get { return (string) this["host"]; }
        }
    }
}

Bien, ahora imaginemos que por alguna razón especial el puerto no debe ser ni el 110 ni el 23 (o podría ser cualquier otra regla que a uno se le ocurra). Una forma sencilla de realizar esta validación es usando un método callback, la idea es sencilla, cuando la framework obtenga el valor ejecutará el método o callback de validación pasando ese valor (o el por defecto) como parámetro, dentro del método (o callback en este caso) si no se cumple el requerimiento o validación, se arroja una ArgumentException. Los requerimientos del callback method son sencillos: Debe ser público, estático, ser de tipo void (o una Sub en Visual Basic) y tener un parámetro tipo Object (que recibe el valor a validar). Nuestra simple callback de ejemplo sería algo así:

using System;

namespace Cprieto.Samples {
    public class PortValidator {
        public static void Validate(object value) {
            var num = Convert.ToInt32(value);
            if (num == 110 || num == 23)
                throw new ArgumentException("port must not be 110 or 23");
        }
    }
}

Ahora simplemente le decimos declarativamente a la sección de configuración que use ese callback basta con adornar el elemento con el atributo CallbackValidatorAttribute

using System.Configuration;

namespace Cprieto.Samples {
    public class SampleConfigurationSection : ConfigurationSection {
        [CallbackValidator(Type = typeof(PortValidator), CallbackMethodName = "Validate")]
        [ConfigurationProperty("port", DefaultValue = 80)]
        public int Port {
            get { return (int) this["port"]; }
        }

        [ConfigurationProperty("host", IsRequired = true)]
        public string Host {
            get { return (string) this["host"]; }
        }
    }
}

Es importante que recordemos pasar el tipo del validador (o sea, la clase que lo contiene) y el nombre de la función de callback

Para probar nuestro validador basta con usar el siguiente app.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="sample"
             type="Cprieto.Samples.SampleConfigurationSection, Cprieto.Samples.ValidationCallback"/>
  </configSections>
  <sample port="110" host="localhost" />
</configuration>

Bien, como dijo Porky… los dejo hasta la siguiente entrega donde continuaremos hablando de validadores en las configuraciones de la .Net Framework, Saludos miles a todos :)

.NET y Configuraciones – Parte 5

Aunque hemos creado colecciones de elementos en las secciones de configuración personalizadas no nos dejemos engañar, hay mucho más acerca de las colecciones de elementos de configuración que simplemente conocer como agregar elementos nuevos.

Tipos de colecciones de configuración

Existe un enumerador especial, ConfigurationElementCollectionType, que nos sirve como indicador de “cómo” debe ser el comportamiento de la colección. Al principio uno piensa “¿cómo así el comportamiento? una colección simplemente es un número finito secuencial de elementos”. Bueno, veamos en que difiere cada tipo:

AddRemoveClearMap El tipo por defecto, los elementos de la colección pueden unirse o fusionarse dentro de una jerarquía de archivos de configuración (por ejemplo, la jerarquía en Web.config). Existen operaciones de Clear, Remove, Add que permiten modificar las propiedades heredadas dentro de la jerarquía
AddRemoveClearMapAlternate Igual que AddRemoveClearMap, con la diferencia en que sus elementos ordenan sus elementos en la definición actual antes que la de la jerarquía. Estando los elementos locales antes que los elementos heredados (en la colección)
BasicMap Los elementos definidos en un nivel son compartidos con los de los niveles hijos, pero los niveles hijos no pueden modificar la colección definida por su padre
BasicMapAlternate Funciona igual al BasicMap, pero los elementos heredados son mostrados después que los elementos locales

Las colecciones de tipo BasicMap no poseen operaciones de add, remove, clear. Los tipos Alternate incluyen los elementos padres después de la definición de elementos locales. Lo más común es mantenerse en colecciones de tipo AddRemoveClearMap y utilizar BasicMap cuando realmente queremos asegurarnos que no se debe modificar la colección.

Definir nodos como elementos

Otra opción poco común pero sencilla de hacer es evitar utilizar la palabra add para agregar el nodo a la colección y en vez de eso utilizar el elemento como nodo de la colección. Esto es realmente sencillo y muchas veces nos puede mejorar la claridad del código de configuración. El secreto es simplemente hacer override de las propiedades de la colección que se encarga de retornar los nombres de los elementos en la colección, ElementName y CollectionType, y opcional a ello indicar el tipo de colección que utilizaremos marcando la colección con una propiedad de un atributo, ConfigurationCollectionAttribute.

using System.Configuration;

namespace Samples {
    [ConfigurationCollection(typeof (ServerConfigurationElement),
        CollectionType = ConfigurationElementCollectionType.BasicMap)]
    public class ServerConfigurationCollection : ConfigurationElementCollection {
        public ServerConfigurationElement this[int index] {
            get { return BaseGet(index) as ServerConfigurationElement; }
            set {
                if (BaseGet(index) != null)
                    BaseRemoveAt(index);
                BaseAdd(index, value);
            }
        }

        public new ServerConfigurationElement this[string name] {
            get { return BaseGet(name) as ServerConfigurationElement; }
        }

        public override ConfigurationElementCollectionType CollectionType {
            get { return ConfigurationElementCollectionType.BasicMap; }
        }

        protected override string ElementName {
            get { return "server"; }
        }

        protected override ConfigurationElement CreateNewElement() {
            return new ServerConfigurationElement();
        }

        protected override object GetElementKey(ConfigurationElement element) {
            var value = element as ServerConfigurationElement;
            return value != null ? value.Name : null;
        }
    }
}

Y nuestro archivo de configuración ahora tendría la siguiente forma

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="sample"
             type="Samples.SampleConfigurationSection, Samples.Cfg.AdvancedCollections"/>
  </configSections>
  <sample default="default">
    <servers>
      <server name="default" host="localhost" />
      <server name="another" port="8080" host="192.168.1.1" />
    </servers>
  </sample>
</configuration>

Algunos quizás encontraran esto ligeramente más fácil de leer que la versión original publicada en la parte 4 de esta serie.

Rayos, sin darnos cuenta llevamos ya cinco artículos sobre configuración personalizada en .Net (no se preocupen, aún faltan muchos más), el tiempo vuela cuando uno se divierte :P , como siempre agradezco sus comentarios, tags, pings, whatever… siempre son bienvenidos….

Y bueno, como dice Porky…

.NET y Configuraciones – Parte 4

Hasta el momento hemos tocado la creación de configuraciones personalizadas, elementos de configuración personalizados y la creación de grupos de secciones de configuración personalizados. Es interesante pero eso simplemente es la punta del iceberg de todo lo que dentro del concepto de configuración que nos permite manejar o mover la .NET Framework, hoy profundizaremos un poco más acerca de agregar nuevas características a nuestra configuración personalizada.

Colecciones y listas

Se que muchos hemos visto secciones de la configuración de ASP.NET y notado el uso de colecciones en él web.config, por ejemplo, el segmento de appSettings:

<appSettings>
    <clear />
    <remove name="port" />
    <add name="port" value="81" />
</appSettings>

Luego acceder a tal segmento de la configuración es "relativamente" sencillo, basta con algo como esto:

int port = int.Parse(ConfigurationManager.AppSettings["port"]);

Como habrán notado esto nos permite tener secciones que se comportan como colecciones de valores, que luego pueden ser accedidas por un indexer usando el nombre (en este caso "port") o el índice (en este caso, 0). Estas colecciones también soportan operaciones básicas (remove, clear, add). Crear colecciones de valores para la configuración no es para nada difícil simplemente hay que heredar de una clase abstracta especial, ConfigurationElementCollection

Comencemos por la unidad mínima, digamos que son elementos para datos de servidores

using System.Configuration;

namespace Samples {
    public class ServerConfigurationElement : ConfigurationElement {
        [ConfigurationProperty("name", IsRequired = true)]
        public string Name {
            get { return (string) this["name"]; }
        }

        [ConfigurationProperty("port", DefaultValue = 80)]
        public int Port {
            get { return (int) this["port"]; }
        }

        [ConfigurationProperty("host", IsRequired = true)]
        public string Host {
            get { return (string) this["host"]; }
        }
    }
}

Hasta el momento nada diferente de lo que conocemos. Ahora agreguemos el soporte para la colección de elementos de configuración tipo ServerConfigurationElement

using System.Configuration;

namespace Samples {
    [ConfigurationCollection(typeof(ServerConfigurationElement))]
    public class ServerConfigurationCollection : ConfigurationElementCollection {
        protected override ConfigurationElement CreateNewElement() {
            return new ServerConfigurationElement();
        }

        protected override object GetElementKey(ConfigurationElement element) {
            var value = element as ServerConfigurationElement;
            return value != null ? value.Name : null;
        }

        public ServerConfigurationElement this[int index] {
            get {
                return BaseGet(index) as ServerConfigurationElement;
            }
            set {
                if (BaseGet(index) != null)
                    BaseRemoveAt(index);
                BaseAdd(index, value);
            }
        }

        public new ServerConfigurationElement this[string name] {
            get {
                return BaseGet(name) as ServerConfigurationElement;
            }
        }
    }
}

Obligatoriamente tenemos que implementar los métodos CreateNewElement (el cual creo su nombre e implementación son suficientemente descriptivos) y el método GetElementKey, este nos retorna el valor que tendrá la key del diccionario de elementos. Observen como implementamos los indexers que luego necesitaremos para acceder a los elementos de la colección. Nótese también que nuestra colección esta adornada con el atributo ConfigurationCollectionAttribute, el cual no es estrictamente necesario.

Bien, nos queda simplemente implementar la sección de configuración general, no muy diferente

using System.Configuration;

namespace Samples {
    public class SampleConfigurationSection : ConfigurationSection {
        [ConfigurationProperty("default", IsRequired = true)]
        public string DefaultServer {
            get { return (string) this["default"]; }
        }

        [ConfigurationProperty("servers", IsRequired = true)]
        public ServerConfigurationCollection Servers {
            get {
                return this["servers"]
                   as ServerConfigurationCollection;
            }
        }
    }
}

Nuestra configuración personalizada lucirá algo así:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section
        name="sample"
        type="Samples.SampleConfigurationSection, Samples.Cfg"/>
  </configSections>
  <sample default="default">
    <servers>
      <clear />
      <add name="default" host="localhost" />
      <add name="another" port="8080" host="192.168.1.1" />
    </servers>
  </sample>
</configuration>

Y en nuestro programa podemos acceder a ella de forma sencilla

using System;
using System.Configuration;

namespace Samples {
    internal class Program {
        private static void Main(string[] args) {
            var cfg = ConfigurationManager.GetSection("sample") as SampleConfigurationSection;
            if (cfg == null) return;

            Console.WriteLine("Default item: {0}", cfg.DefaultServer);

            foreach (ServerConfigurationElement server in cfg.Servers) {
                Console.WriteLine("server: {0}, host: {1}, port: {2}",
                    server.Name, server.Host, server.Port);
            }

            ServerConfigurationElement defaultServer = cfg.Servers[cfg.DefaultServer];

            Console.WriteLine("Default host: {0}", defaultServer.Host);
            Console.ReadLine();
        }
    }
}

Como les advertí desde el principio, nada complicado y sumamente útil. Creo que vale la pena mencionar que cualquier comentario, sugerencia, duda u observación soy todo ojos para leer sus comentarios.

Cómo dijo Terminator, volveré…

Mercurial as a Git client

Days ago I just published a short blog post about using Mercurial as a SVN Client, I know, Subversion is the “now-legacy-vcs-system” and Git with Mercurial are the “cool kids” in the school, why not make them work together?

Well, in the same way we could make Subversion works with Hg (using extensions of course) we could make Git works with Mercurial. It requires a little more work in Windows but it stills easy to do. As usual we start with a TortoiseHg installation. I will try to show its installation in a short set of steps:

  • We need to activate the Mercurial Bookmark and rebase extensions (these extensions are included with standard Mercurial installation). Edit your mercurial.ini file and add the following to the [extensions] section
  • [extensions]
    rebase =
    hgext.bookmarks = 
  • HgGit needs a special python library to handle Git repositories, this library is named dulwich. You need to get it from its source repository, clone it in some directory

    hg clone http://bitbucket.org/abderrahim/dulwich
  • Now we need to get the HgGit source code from its repository, let’s clone it from repository

    hg clone http://bitbucket.org/durin42/hg-git
  • This is the hard part, we need to tell to HgGit the location where the dulwich library is installed. Remember, both HgGit and dalwich are Python libraries, so we’ll edit just a file to show where to get dalwich. Go to the place you cloned HgGit search and open the file __init__.py and add look for the following code and add the code highlighted
    import os
    
    # NOTE: Added for tortoisehg compatibility
    import sys
    sys.path.append('write here the directory where dulwich was cloned')
    
    from mercurial import commands, extensions, hg, util as hgutil
    from mercurial.i18n import _
  • Now let’s activate the extension, open again your mercurial.ini file and add the following line to your [extensions] section

    hggit = directory where hggit where cloned\hggit

And that is all, just test your extension installation with hg help extensions And look for hggit

Now you can clone, rebase, push, pull and do whatever you do with mercurial but using remote git repositories, for example, now you can do something like

hg clone http://github.com/castleproject/Castle.Core.git castle

I hope this guide could help you to get more fun from Mercurial, see you later!

.NET y Configuraciones – Parte 3

Ok, hasta el momento ya vimos como crear nuestras propias secciones y valores de configuración, además de darnos una vuelta por las opciones de crear y agregar elementos a nuestras secciones personalizadas. Hoy continuaremos indagando un poco más en el mundo de las configuraciones personalizadas en .NET.

Grupos de Secciones

Imagínense que la configuración de nuestra aplicación es mucho más compleja de lo usual y que además de elementos personalizados necesitamos agregar “subsecciones” de configuración. Dentro de la .Net Framework es algo común en ASP.NET. Crear secciones de configuración no puede ser más fácil, basta con crear las secciones como lo hemos estado haciendo hasta el momento. Tomemos por ejemplo las siguientes dos secciones:

public class SampleSection : ConfigurationSection {
    [ConfigurationProperty("name", IsRequired = true)]
    public string Name {
        get { return (string) base["name"]; }
        set { base["name"] = value; }
    }

    [ConfigurationProperty("port", DefaultValue = 80)]
    public int Port {
        get { return (int) base["port"]; }
        set { base["port"] = value; }
    }
}

public class AnotherSection : ConfigurationSection {
    [ConfigurationProperty("times", IsRequired = true)]
    public int TimesPerDay {
        get { return (int) base["times"]; }
        set { base["times"] = value; }
    }
}

Basta ahora con crear un ConfigurationSectionGroup para obtener ambas secciones dentro de un mismo grupo

public class SampleSectionGroup : ConfigurationSectionGroup {
    [ConfigurationProperty("sample")]
    public SampleSection Sample {
        get { return (SampleSection) Sections["sample"]; }
    }

    [ConfigurationProperty("another")]
    public AnotherSection Another {
        get { return (AnotherSection) Sections["another"]; }
    }
}

Agregarla en el web.config es un poco más laborioso pero continúa siendo sencillo

<configuration>
  <configSections>
    <sectionGroup name="sampleGroup" type="WebApplication2.SampleSectionGroup">
      <section name="sample" type="WebApplication2.SampleSection"/>
      <section name="another" type="WebApplication2.AnotherSection"/>
    </sectionGroup>
  </configSections>
  <sampleGroup>
    <sample name="sample" port="31" />
    <another times="5" />
  </sampleGroup>
</configuration>

Creo que para estas alturas el usarla en el código debe ser algo sencillo y "straighforward"

.NET y Configuraciones – Parte 2

Anteriormente habíamos conversado acerca de como trabajar nuestras propias secciones “customizadas” de configuración usando las facilidades de configuración que nos da la .Net Framework. Como vemos es sumamente fácil crear nuestras secciones “personalizadas”. Conversaremos hoy un poco más de como sacarle mayor provecho y extender nuestras secciones de configuración y así sacar mucho mayor provecho.

Elementos personalizados anidados

Observemos el siguiente snippet de código

public class HostInfo : ConfigurationElement {
    [ConfigurationProperty("server", DefaultValue = "localhost")]
    public string Server {
        get { return (string) base["server"]; }
        set { base["server"] = value; }
    }

    [ConfigurationProperty("port", DefaultValue = 80)]
    public int Port {
        get { return (int) base["port"]; }
        set { base["port"] = value; }
    }

    [ConfigurationProperty("ssl", DefaultValue = false)]
    public bool IsSecure {
        get { return (bool) base["ssl"]; }
        set { base["ssl"] = value; }
    }
}

Aunque nos recuerda a la forma en que creamos una sección de configuración, realmente estamos creando un elemento de la configuración (ConfigurationElement). En otras palabras, podemos tener elementos anidados y de esa manera lograr que nuestros elementos de configuración obedezcan a una más clara semántica. Utilizarlo en la sección de configuración no puede ser más fácil

public class ServerConfigurationSection : ConfigurationSection {
    [ConfigurationProperty("name", IsRequired = true)]
    public string Name {
        get { return (string)base["name"]; }
        set { base["name"] = value; }
    }

    [ConfigurationProperty("host")]
    public HostInfo Host {
        get { return (HostInfo)base["host"]; }
        set { base["host"] = value; }
    }
}

Usarlo no puede ser más fácil que esto

<configuration>
  <configSections>
    <section name="server" type="WebApplication2.ServerConfigurationSection"/>
  </configSections>
  <server name="myconfiguration">
    <host server="192.168.1.1" port="81"/>
  </server>
</configuration>

.NET y configuraciones – Parte 1

Hace unos días 0Gis0 publicó un buen artículo sobre el archivo de configuración en .Net y como crear nuestras propias secciones personalizadas. Bien, he decidido ahondar un “poco” más en el asunto aprovechando el hecho que tengo prometido a un par de amigos desde hace ratos que publicaría acerca de configuración en .Net, es buena idea que antes le den una rápida leída al artículo que en cuestión.

Recapitulando lo que nos menciona nuestra compañera, es sencillo crear una sección personalizada de configuración en .Net, basta solamente de heredar de la clase ConfigurationSection y listo. Bueno, no tan rápido, hay un par de cosas de hacer notar, la sección personalizada de configuración debe exponer propiedades que se mapean a las opciones de configuración, estas propiedades deben estar “adornados” con los atributos ConfigurationProperty y obligatoriamente debemos indicar a que atributo de la sección de configuración a la cual se mapea. A partir de esto usamos el indexer de la clase base y la casteamos al tipo que necesitamos.

public class SimpleConfigurationSection : ConfigurationSection {

    [ConfigurationProperty("port")]
    public int Port {
       get {
           return (int) this["port"];
       }
       set {
           this["port"] = value;
       }
    }
}

Esto correspondería a algo así en el archivo de configuración

<configSections>
    <section name="smtp" type="SimpleConfigurationSection, MyAssembly" />
</configSections>
<smtp port="25">

Simple y sencillo, de igual manera podemos indicar si el elemento es requerido y también el valor por defecto de la propiedad con simplemente modificar un poco el atributo

public class SimpleConfigurationSection : ConfigurationSection {

    [ConfigurationProperty("port", DefaultValue = 80, IsRequired = true)]
    public int Port {
       get {
           return (int) this["port"];
       }
       set {
           this["port"] = value;
       }
    }
}

Simple y sencillo, como lo menciona nuestra amiga. Con esto como base podemos acceder la configuración de forma simple

var config = (SimpleConfigurationSection) ConfigurationManager.GetSection("smtp");
var port = config.Port;

Con esto como base estamos listos para profundizar un poco más en el asunto. En la próxima entrega veremos como definir jerarquías de configuración en nuestras secciones personalizadas.

Saludos!

UPDATE: otros post de la serie han sido publicados

FluentNhibernate y Sql-query

Hoy en la oficina uno de mis compañeros de trabajo me presenta un simple problema muy particular

Necesito llamar a un procedimiento almacenado desde NHibernate, pero estoy usando FluentNhibernate para el mapeo de entidades, ¿hay algo que puedo hacer?

No es algo así como un problema “clásico” el tener que llamar procedimientos almacenados en Nhibernate, pero creo que vale la pena explicarlo.

Digamos que el procedimiento almacenado sea algo como esto

CREATE PROCEDURE [dbo].[usp_GetItemCount](@parentId INT) AS
BEGIN
    SELECT COUNT(*) AS [Total]
    FROM [items]
    WHERE [parent_id] = @parentId
END

Bueno, nada complicado, pero digamos que necesitamos llamarlo desde algún lugar de nuestra aplicación. Digamos que debido a que es algo fuera de la entidad de negocio necesitamos hacerlo usando un servicio. Bueno, escribamos el servicio

public interface ICountService {
    int GetTotal(int parentId);
}

Como recordaran, en NHibernate existe algo llamado named queries utilizadas para ejecutar consultas de SQL arbitrarias en el motor de base de datos, es una herramienta sumamente poderosa, les recomiendo dar una vuelta por la documentación. Una named query se define en un archivo de mapeo HBM al igual que los archivos de mapeo de NHibernate, por lo tanto podemos definir esta named query en el archivo Queries.hbm.xml

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">
  <sql-query name="SampleQuery" cacheable="true"
             read-only="true" callable="true">
    <query-param name="parentId" type="Int32"/>
    <return-scalar type="Int32" column="Total"/>
    exec usp_GetItemCount @parentId = :parentId
  </sql-query>
</hibernate-mapping>

Ok señores, pero digamos que estamos usando Fluent NHibernate para el mapeo de nuestras entidades… Rayos… Bueno, no tanto, en realidad es bastante sencillo, en Fluent Nhibernate tenemos la opción de agregar mapeos de XML al mapeo "fluent"

SessionFactory =
 Fluently.Configure().Database(MsSqlConfiguration.MsSql2008
     .ConnectionString(
         c => c.Server("(local)").Database("Test")
             .TrustedConnection())
         .ShowSql().CurrentSessionContext("web")
         .ProxyFactoryFactory<ProxyFactoryFactory>())
     .Mappings(m => m.FluentMappings.AddFromAssemblyOf<ItemClassMap>())
     .Mappings(m => m.HbmMappings.AddFromAssemblyOf<ItemClassMap>())
     .BuildSessionFactory();

Digamos que el archivo de mapeo de la query se encuentra en el mismo lugar que el de las classmaps de fluent nhibernate. Ahora es sencillo definir el servicio que ejecuta el procedimiento almacenado.

public class CountServiceImpl : ICountService {
    readonly ISessionFactory _factory;
    protected ISession Session {
        get { return _factory.GetCurrentSession(); }
    }

    public CountServiceImpl(ISessionFactory factory) {
        _factory = factory;
    }

    public int GetTotal(int parentId) {
        var total = Session.GetNamedQuery("SampleQuery")
            .SetInt32("parentId", parentId)
            .UniqueResult<int>();
        return total;
    }
}

Simple, sencillo, llano, conciso…

Como siempre para comentarios o lo que quieran decir/compartir/discutir se encuentra la cajita de comentarios en este post… Hasta la próxima!