Tiene sentido usar una DAL con un ORM?

Interesantes comentarios de de la lista altnet-hispano. Mi respuesta corta es que NO, que normalmente abstraer el ORM traería casi tanto trabajo como reemplazarlo cuando hiciera falta, y si además por algún nuevo requisito hubiera que cambiar el ORM, seguramente esto sería lo que menos trabajo nos causara.

Incluyo la opinión del superhéroe Ayende: In short, I am completely opposed for even trying doing something like that.

Acceso asíncrono a la DB

Not blocking the thread isn’t actually the most important issue: a connection normally can’t be used asynchronously anyway (i.e. this approach will work only if you send your queries on different connections). Grouping of multiple queries together is normally more important: you anyway can do some work on the client while the query is executed; but if queries are relatively simple, grouping them together saves lots of roundtrips to database. Many ORMs (NHibernate, DataObjects.Net at least) provide support for future (delayed) queries, that are more attractive from this point.

via.

Mini-ORMs

Desde que se publicara Massive, que a mí personalmente me impresionó. Han aparecido algunos mini-orms, como PetaPoco o Dapper.Net (usado en stackoverflow). Realmente lo podríamos llamar la capa de acceso a datos tradicional, pero que con la nueva funcionalidad de C# todo es más fácil. Una evolución de AutoMapper.

public static List<T> AutoMap<T>(this IDataReader dr)
 where T : new()
 {
 Type businessEntityType = typeof(T);
 List<T> entitys = new List<T>();
 Hashtable hashtable = new Hashtable();
 PropertyInfo[] properties = businessEntityType.GetProperties();

 foreach (PropertyInfo info in properties)
 {
 hashtable[info.Name.ToUpper()] = info;
 }

 while (dr.Read())
 {
 T newObject = new T();
 for (int index = 0; index < dr.FieldCount; index++)
 {
 PropertyInfo info = (PropertyInfo)hashtable[dr.GetName(index).ToUpper()];
 if ((info != null) && info.CanWrite)
 {
 info.SetValue(newObject, dr.GetValue(index), null);
 }
 }
 entitys.Add(newObject);
 }
 dr.Close();
 return entitys;
 }

Creo que es esto es otra muestra del rechazo a la over-engineering.

Nueva capa de acceso a datos

Después de mucho tiempo trabajando con el combo Gentle.NET y MyGeneration, va tocando actualizarse a otras herramientas que estén mejor soportadas. Aunque tengo claro que voy a usar nHibernate, aún no tengo claro como usarlo.

– nHibernate y las herramientas Db2hbm y T4 hbml2net, para generar los XML a partir del esquema de db y las clases POCO.

– nHibernate y alguna plantilla de generación de MyGeneration o tal vez plantillas de T4.

– nHibernate + Castle ActiveRecord. Así podría hacer algo muy similar a lo que ya tengo, porque usa atributos para definir el mapeo.

– S#arp architecture.

– Fluent nHibernate, esta es la que más de moda está.

Data Access según Microsoft y Patterns & Practices

He estado investigando que propone Microsoft en acceso a datos, y la verdad es que me ha resultado difícil encontrar algo reciente, actualizado y explicado de una manera clara. Uno un poco antiguo: p&p Repository Factory y otro en construcción y en exclusiva para VS 2010: p&p Data Guidance.

La verdad es que ha sido frustrante tener que buscar algo y encontrarse con documentos anticuados, desactualizados o sin finalizar. Aunque lo que más echaba de menos es un pequeño resumen que explique brevemente e indique las distintas opciones existentes. Ni que decir, que apenas se menciona NHibernate.

Esperemos que con la n-ésima propuesta de Microsoft Entity Framework, se actualicen y aclaren estos documentos y de paso a ver si les da por comentar alguna de las propuestas del exterior: ALT.NET.