Espacio de Dario Quintana

Hace unos días había dejado el enlace en las lista de C# del MUG (Argentina), y para que no digan que en este blog solo posteo código, hoy les dejo un videito para que se entretengan un rato. Por cierto, sería muy interesante saber cuales serían las nuevas features de C# 4.0, habrá que esperar.

C# 4.0: Meet the Design Team

Este release lo estaba esperando desde hace mucho tiempo por parte de Db4o, y los que siguen a Db4o de cerca creo que también.

Para los que no están familiarizados, Db4o corre sus aplicaciones en ambas plataformas: Java y .Net. El mayor trabajo se realiza en Java, que luego mediante Sharpen se realiza la conversión hacia C#, si bien no el 100% de Db4o.Net está generado, la mayoría lo está.

• How To Setup Sharpen

• Example Conversion

• Sharpen Command-Line Arguments

• Sharpen Annotations

Espero que sirva !

Ya está para descargar Mono.Sms, hosteado como proyecto en Code Google.

Los binarios han sido probados en Mono 1.2.4/.Net Framework 2.0

Este es el trunk, pueden descargar el código fuente con un cliente de SVN como Tortoise SVNsi usan Windows.

• http://monosms.googlecode.com/svn/trunk/

Aquí están los binarios/setup para descargar:

• http://code.google.com/p/monosms/downloads/list

 Para dejar comentarios creé este grupo en google:

• http://groups.google.com.ar/group/monosms/

Voluntarios, envien los parches, reporte de issues/bugs aquí:

• http://code.google.com/p/monosms/issues/list

 El código fuente se puede compilar usando NAnt. He incluido el archivo default.build en el SVN para este fin.

En este post previo, hablábamos sobre las iteraciones en C# y donde dije que Mono me resultó un poco más rápido en Linux a diferencia con Mono en Windows y .Net Framework de MS. Bueno aquí les muestro las resultados de las ultimas corridas de cada uno para que vean. La clase con la que probé se encuentra aquí: Iteraciones.zip

Con .Net Framework de MS:

Con Mono en Windows:

Con Mono en Linux:

A pedido del público, voy a hacer este post donde mostramos las formas de Iterar en C#. Estuve mirando que tengo muchos accesos al blog con estas palabras: Iteraciones en C#, entonces, hablemos de ello.

Carga de una lista:

List<string> list = new List<string>();

list.Add(“Visual Basic Dynamic”);
list.Add(“IronPython”);
list.Add(“Ruby”);
list.Add(“Javascript”);

Iteremos !

1. Utilizando foreach:

foreach(string item in list)
{
    Console.WriteLine(item);
}

2. Utilizando IEnumerator:

IEnumerator<string> ie = list.GetEnumerator();

while(ie.MoveNext())
{
    Console.WriteLine(ie.Current);
}

 3. Utilizando for:

for(int i = 0; i < list.Count; i++)
{
    Console.WriteLine(list[i]);
}

 4. Usando metodo .ForEach(System.Action<T>):

list.ForEach( delegate(string str)  { Console.WriteLine(str); } );

 5. Metodo 4, pero sacando ventaja de la inferencia de tipos:

list.ForEach(Console.WriteLine);

¿Cuál es más rapido? No me atrevo a decir que método es más rapido, he hecho una clase de prueba [Iteraciones.cs], con 10000 iteraciones (nunca tengo tanto para iterar), y llegué a resultados similares.

Con Mono en Linux, he notado un poco más de rapidez que con Mono en Windows, inclusive más rapidez que con .Net de Microsoft. En Windows y Linux (Ubuntu 7.04) he usado Mono 1.2.3.1 version.

Caracteristicas de la laptop: Procesador Intel Core 2 Duo T5600 1.83GHz, 512Mb DDR2-667.

Considero que todas las formas son claras, son estructuras bien conocidas y cualquiera de ellas resulta facil de leer. Hay que usar la que más convenga llegado el caso. Por ejemplo:

1. for es más útil cuando conocemos los limites de la iteración, y también si queremos en todo momento consultar por qué número de iteración vamos.

2. foreach es para ir tratanto cada ítem dentro de su estructura. No es muy útil si se tiene que hacer castings por cada ítem.

3. IEnumerator, es para aplicar el patron iterator sin ninguna duda. Y así ir iterando al siguiente item.

4. ForEach, sin duda la ventaja de este este método es la única linea que se necesita. Se trata de una estructura que recibe como parámetro un delegado Action<T>, y dentro de sí, existe una iteración. Mono realiza esta iteración usando un foreach, y el .net framework de ms usa un for. Cuestion de gustos quizas. 

Estuve jugando con los Métodos Extendidos en C# 3.0, y la verdad que esta feature hace que el código sea más legible.

string[] terminos = new string[] { “gurí”, “guaina”, “tereré”, “mate” };

            foreach (var item in terminos)
                Console.WriteLine(item);

Utilizando estas extensiones de métodos:

public delegate void VoidsHandler<T>(T param);

    public static class DarioExtend
    {
        public static void ApplyToAll<T>(this IList<T> lista, VoidsHandler<T> handler)
        {
            foreach (var item in lista)
            {
                handler(item);
            }
        }

        public static void WriteLine<T>(this IList<T> lista)
        {
            foreach (var item in lista)
            {
                Console.WriteLine(item);
            }

        }
    }

La forma de imprimir podría cambiarse por:

terminos.ApplyToAll(item => Console.WriteLine(item));

ó por esto:

 terminos.WriteLine();

Spring.Net es uno de los frameworks más conocidos para implementar Inyección de Dependencia (también conocido como Inversión de Control -IoC). Otros que nos permiten hacer este trabajo son: PicoContainer, ObjectBuilder, Windsor Container.

Basicamente, qué queremos lograr? Fácil, crear nuestros objetos, sin importar quién me provea la implementación.

En vez de hacer esto:

(1) Cliente obj_cliente = new Cliente();

Podemos hacer esto:

(2) ICliente obj_cliente = (ICliente) AppContext.Instance.GetObject(“Cliente”);

Expliquemos, en (1) le estamos diciendo a obj_cliente quién va a crearlo: new Cliente(); Es decir, le estamos diciendo quien le va a proveer de la implementación, y nunca vamos a poder cambiar esto, a menos que lo hagamos y volvamos a compilar. En (2) es distinto, estamos pidiendo una implementación, pero no sabemos quien nos la va a dar. Solo sabemos que quién nos proveea la construcción, va a implementar la interfaz ICliente. AppContext es un wrapper que hice para crear un singleton del contexto de toda la aplicación (está en el codigo fuente que se puede descargar más abajo).

El lugar donde le decimos qué clase se va a encargar de la implementación, es en el app.config (en una de las tantas lineas para configurar Spring.Net):

<object name=”Cliente” type=”Entities.Cliente, Entities” singleton=”false”/>

En esta línea de código Entities.Cliente es la Clase que nos proveerá la implementación, y Entities es el assembly (que TIENE que estar en la carpeta de salida, donde está el .exe). También podemos ver cuan fácil es implementar un singleton de esta manera, solamente escribiendo singleton=”true” (ú obviandolo, es el valor por defecto), entonces no tenemos que hacerlo programaticamente.

Para el ejemplo lo que hice es organizar los proyectos de esta forma:

Lo que hariamos normalmente es referenciar Entities desde todas las partes del proyecto, en vez de esto, lo haremos con Entities.Contracts que contienen las interfaces, de modo que siempre programaremos contra las interfaces, nunca contra la implementación. Los proyectos no poseen relación de conocimiento con Entities, en ningún momento se lo referencia.

El tip del día: Hay que programar contra las interfaces.

Descargar codigo fuente [Proyecto hecho con SharpDevelop]

Donde más podemos utilizarlo ? En la capa de acceso a datos, podríamos persistir los objetos con db4o, y en otra implementación lo podríamos hacer usando NHibernate! Y esto lo lograríamos creando una interfaz IBaseRepository que tenga metodos como Guardar, Eliminar, Buscar y luego crear las implementaciones para cada uno de los providers por ejemplo BaseRepositoryDb4o y BaseRepositoryNH.

Espero que sirva!

Una herramienta muy importante de NHibernate, a la vez, deseable por los ORM, es la generación de código.

Para generar el DDL de la base de datos, nos podemos valer de la información del esquema, que nos brindan los archivos de mapeo ó mapping files: hbm.xml.

Un vez que tenemos bien configurados estos archivos, podemos generar las tablas con solamente incluir un par de sentencias en .Net y configurar un archivo xml. Tambien se tiene que tener referenciado a NHibernate.

Código en C#:

using System;
using NHibernate.Cfg;
using  NHibernate.Tool.hbm2ddl;
public class MyClass
{
    public static void Main()
    {
            Configuration config = new Configuration();
            config.Configure();
            SchemaExport exporter = new SchemaExport(config);
            //exporter.SetOutputFile(@"c:testDDL.sql");
            exporter.Drop(true, true);
            exporter.Create(true, true);
    }
}

Archivo hibernate.cfg.xml (debe ir copiado en el directorio de salida):

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration  xmlns="urn:nhibernate-configuration-2.0" >
 <session-factory name="NHibernate">
	<property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
	<property name="connection.driver_class">NHibernate.Driver.FirebirdClientDriver</property>
	<property name="connection.connection_string">
	ServerType=1;
	User=sysdba;password=masterkey;Database=C:ruraldata.fdb;
	Pooling=false
	</property>
	<property name="show_sql">true</property>
	<property name="dialect">NHibernate.Dialect.FirebirdDialect</property>
	<property name="use_outer_join">true</property>
	<property name="query.substitutions">true 1, false 0, yes 'Y', no 'N'</property>

	<mapping assembly="RuralSolution.Entities" />

 </session-factory>
</hibernate-configuration>

En este caso es la exportación del schema de una base de datos Firebird embebida.

Esta herramienta me ha sido de mucha utilidad. Estoy desarrollando una aplicación en SQL Server 2005 y NHibernate, pero, me dí cuenta que la aplicación debía ser portable, de modo que tuve que migrar la base de datos a una portable, y como Firebird está pasando todos los test de NH, la elegí. Ya tenía los hbm, así que no requirió trabajo demás.

Importante para la generación con Firebird: en el directorio de salida entonces tendriamos que tener: fbembed.dll, FirebirdSql.Data.FirebirdClient.dll, y hibernate.cfg.xml.

Si quieren saber como trabajar con MyGeneration y Firebird embedded léanse este post de mi amigo Matias.

Inspirado en este post, decidí hacerme un ejemplito de predicados en .Net y así utilizar el patrón especificaciones.

Un predicado es un delegado que apunta a funciones que devuelven un valor booleano y aceptan un objeto genérico.

Vamos a ver una forma interesante de hacer filtrados en base a ciertos criterios de selección utilizando estos dichosos predicados de .Net.

Ciertamente podríamos implementar esto de la forma que siempre se hace, realizar un filtrado, iterando en una colección, y preguntando si tal elemento, se corresponde con el criterio elegido. Por ejemplo: recorrer la lista y vamos preguntando: este cliente…tiene correo gmail ?

Podría esbozarse un código como este:

 static public IList<Cliente> HasGmail(IList<Cliente> lista)
        {
            IList<Cliente> lista_resultado = new List<Cliente>();

            foreach(Cliente c in lista)
            {
                if(c.Email.Contains("@gmail.com"))
                {
                    lista_resultado.Add(c);
                }
            }
            return lista_resultado;
        }

Y se llamaría así:

IList<Cliente> usuariosDeGmail = ClienteFinder.HasGmail(lista);

Pero ahora bien, se podría objetizar el código, y hacerlo un poco más flexible, y hacer uso de predicados.

Podríamos reemplazarlos por esto:

IList<Cliente> usuariosDeGmail = 

                new ClienteFinder(lista).Find(EmailSpec.HasGmail);

Parecería estar más complicado, pero el concepto es sencillo y aplica el patrón de especificaciones, mediante predicatos genéricos.

Vamos al codigo de la entidad de negocio de la cual tenemos un listado y la queremos obtener por un criterio: la entidad Cliente.

public class Cliente
    {
        public Cliente()
        { }

        public Cliente(string nombre, string email)
        {
            this.nombre = nombre;
            this.email = email;
        }
        private string nombre;

        public string Nombre
        {
            get { return nombre; }
            set { nombre = value; }
        }

        private string email;

        public string Email
        {
            get { return email; }
            set { email = value; }
        }

    }

El código principal sería así:

 static void Main(string[] args)
        {
            CargarLista();

            //IList<Cliente> usuariosDeHotmail = new ClienteFinder(lista).Find(EmailSpec.HasHotmail);
            IList<Cliente> usuariosDeGmail = new ClienteFinder(lista).Find(EmailSpec.HasGmail);

            foreach (Cliente cliente in usuariosDeGmail)
            {
                Console.WriteLine(”Email: {0}”, cliente.Email);
            }

            Console.Read();
        }

Veamos el código de las especificaciones que se puede aplicar para obtener distintos criterios de filtrado:

public class EmailSpec
{
    public static Predicate<Cliente> HasHotmail
    {
        get{
            return delegate(Cliente cliente)
            {
                return cliente.Email.Contains("@hotmail.com");
            };

        }
    }

    public static Predicate<Cliente> HasGmail
    {
        get
        {
            return EmailSpec.MethodHasGmail;
        }
    }

    public static bool MethodHasGmail(Cliente cliente)
    {
        return cliente.Email.Contains("@gmail.com");
    }

    public static Predicate<Cliente> HasYahoo
    {
        get
        {
            return new Predicate<Cliente>(EmailSpec.MethodHasYahoo);
        }
    }

    public static bool MethodHasYahoo(Cliente cliente)
    {
        return cliente.Email.Contains("@yahoo.com");
    }

}

Aquí podemos ver, primeramente el uso de retorno de delegados usando Métodos anónimos (en HasHotmail), delegados con inferencia de tipos (en HasGmail) y la forma natural de usar un delegado (en HasYahoo). Estas son tres formas de hacer lo mismo, y yo recomiendo usar métodos anónimos que se vé en la propiedad HasHotmail y en este caso, el código se vuelve mucho más chico.

 public static Predicate<Cliente> HasHotmail
    {
        get{
            return delegate(Cliente cliente)
            {
                return cliente.Email.Contains("@hotmail.com");
            };

        }
    }

Vemos que la propiedad es de sólo lectura, y que también, retorna un predicado, que hablando mal, devolvería la función que se encargaría de la evaluación…y esa función…devolvería un booleano…true OR false, si cumple ó no. Muy prolijo no ? Sería lo mismo hacer:

  public static Predicate<Cliente> HasHotmail
    {
        get{
            return delegate(Cliente cliente)
            {
                if(cliente.Email.Contains("@hotmail.com"))
                    return true;
                else
                    return false;
            };

        }
    }

Ahora veamos el código de ClienteFinder:

public class ClienteFinder
{
    private IList<Cliente> _lista;

    public ClienteFinder(IList<Cliente> lista)
    {
        _lista = lista;
    }

    public IList<Cliente> Find(Predicate<Cliente> predicate)
    {
        List<Cliente> encontrados = new List<Cliente>();

        foreach (Cliente cliente in _lista)
        {
            if (predicate(cliente))
            {
                encontrados.Add(cliente);
            }
        }

        return encontrados;
    }

}

Lo importante acá es el constructor, que va a recibir la lista a ser filtrada. Y también el método Find, quien va a recibir el predicado correspondiente al criterio de selección. Es decir que Find puede recibir cualquiera de las tres especificaciones que preparamos: HasHotmail, HasGmail, HasYahoo, y realizar el filtrado en base a ellas.

Recursos:

• El código completo usando predicados se puede encontrar aquí.
• El código sin predicados, de la manera silvestre está aquí.
• Para los que leen VB.Net aquí les vá…no pidan Metodos anónimos.
• Sigo recomendando este artículo: Create Elegant Code With Anonymous Methods, Iterators, And Partial Classes
• Post anterior sobre: Delegados, Eventos y Métodos anónimos
• Y en esté artículo, se explica el porqué, los métodos anónimos C#, no son closures, soportadas nativamente por Ruby. Pero esto es tema para otros post, pero les dejo la inquietud.

Introducción: Implementando una interfaz gráfica con windows forms, teniendo un MDI principal y un par de formularios hijos, vi la necesidad que en un momento dado, un formulario hijo realice algo que el padre tiene que interceptar, y tomar cartas en el asunto. En este caso necesitaba setear la propiedad Text del MDI, a partir de alguna acción de un formulario hijo; algo sencillo.

En C# y sin la posibilidad de usar algo análogo al namespace My, que posee la gente de VB.Net, tuve que recurrir a un Eventos y Delegados,…y ya que estamos…Métodos anónimos.

En VB.Net, estando en formulario hijo con el namespace my seria algo bastante tonto:

My.Forms.MDIMain.Text = nombredeltitulo

En C# me las arregle con un mecanismo que permita que el padre (MDI principal) se quede a la “escucha” de un evento, y así iniciar acciones, pero con información que le provee el hijo. Es decir:

• Los metodos a ejecutar: son del MDI principal
• Y la información necesaria -los parametros- : provienen del form hijo.

Ahora bien, como se podrían implementar estos tres conceptos juntos para resolver esto ?

Ahora pasemos a un ejemplo donde se vé una interacción entre los objetos:

using System;// Declaracion del delegado

public delegate void EventHandler(string str);

public class Program
{

    public static void Main()
    {

        TestHandler tb = new TestHandler();

        //Tres maneras de hacer lo mismo

        //1- asignacion comun

        tb.Evento += new EventHandler(MetodoStringToUpper);

        //2- asignacion por inferencia de tipos

        tb.Evento += MetodoStringToLower;

        //3- asignacion con metodo anonimo

        tb.Evento += delegate(string str)
        {
            string otrostring = String.Format(“Metodo Anonimo: {0}”, str);
            Console.WriteLine(otrostring);
        };

        tb.Disparar(); Console.ReadLine();

    }

    public static void MetodoStringToUpper(string str)
    {
        Console.WriteLine(str.ToUpper());
    }

    public static void MetodoStringToLower(string str)
    {
        Console.WriteLine(str.ToLower());
    }

}

class TestHandler
{

    //Evento de tipo EventHandler

    public event EventHandler Evento;

    public void Disparar()
    {

        string mystring = “Dario.Net”;

        //Disparo el evento, con un string de parametro

        Evento(mystring);
    }

}

Primeramente declararemos un delegado: EventHandler, que podrá apuntar a metodos que contengan como argumentos el tipo string y que no retornen valores (void).

Luego en la clase TestHandler se declara un evento: Evento, del tipo EventHandler (nuestro delegado).

Y la funcion: Disparar(); se encargará de disparar el evento con un string como argumento: mystring=”Dario.Net”.

Vayamos al Main().

Instanciamos un objeto del tipo TestHandler, con el operador += y vamos agregando al evento, todos los métodos que queremos que se ejecuten, uno tras otro.

Luego invocamos a Disparar(). y se invocan, en este orden los tres métodos: MetodoStringToUpper,MetodoStringToLower y el querido metodo anónimo.

Cosas a notar:

El que dispara el evento es el TestHandler, y le pasa un parámetro: mystring.

Los métodos están en el Main, pero esos métodos se ejecutarán por el hijo…cosa loca no ?

El método anonimo: es como si fuera un metodo más, pero definido en el momento de su uso, e inline (buenísimo!)

Bien, ahora que vimos el ejemplo (y espero que lo hayan entendido), imaginemos algo: hagamos de cuenta que Program es el Main, y TestHandler es el Form1. Y podemos solucionar facilmente el problema que plantee al comienzo…y muchos más!

Para profundizar les recomiendo este artículo.

Saludos y dejen comentarios.