Pepi, Luci, Bom y otros ORMs del montón

Pues aprovechando que me han pasado una interesante dirección sobre ORMs, mchos de ellos gratuitos. Me decido a echarles un ojo y ver como los demás se enfrentan a los mismos problemas que nosotros. El primero que he estado mirando ha sido Gentle.NET. Lo primero que me llama la atención es la calidad de la ayuda, bastante clara y con ejemplos. Pero no nos dejemos engañar por el envoltorio y pasemos al contenido;

• En lineas generales es bastante parecido a nuestro enfoque, esto es, usar atributos para definir el mapeo para la clase y las propiedades, aunque en sus atributos permiten definir restricciones del origen de datos como campos Not null, etc. Esto en principio no lo veo muy útil, salvo el caso de definir si el campo PrimaryKey es autogenerado o no, el poder definir este comportamiento sí puede llegar a interesarnos cuando nos enfrentemos a origenes de datos que no generen automáticamente los identificadores.
• Este ORM permite trabajar directamente con la clase que implementa la persistencia para cargar o guardar objetos, esto hace posible que las clases no tengan que heredar de ninguna clase base, a costa de guarrear el código. Aunque también dan la posibilidad deheredar de la clase Persistent, que aporta funciones de persistencia a los objetos, aunque para cargarlos del origen de datos es necesario seguir accediendo a la clase gestora. Todo esto creo que ensucia el código y dificulta establecer un patrón de trabajo, considero mucho más claro nuestro enfoque de heredar SIEMPRE de una clase base que contiene un gestor que nos provee las capacidades de cargar y guardar objetos.
• Con respecto a las listas de objetos su solución no acaba de separar la capa de negocio y la de datos, como muestra el que para hacer una búsqueda de objetos cuyo nombre contengan la palabra "Antonio", se deba, a nivel de negocio, añadir los % al patrón. Esto claramente debería ser trabajo del gestor, ¿que pasa cuando trabajamos con access? ¿habría que generar el patrón de busqueda como "%Antonio%" o "*Antonio*" dependiendo el caso?.
• Otra cosa que me llama la atención de las listas es que estas consulta devuelve IList, ¿no implementan IBindingList las listas devueltas por el gestor?
• También abordan el problema de los campos nulos pero de una manera diferente y es añadiendo a los atributos de la propiedad que valores se tomarán como nulos para los tipos de datos que no aceptan nulos (DateTime, Decimal y Guid). Aquí sigo viendo más elegante nuestra solución de tener una segunda propiedad para cada uno de estos campos que nos indique si el campo es nulo o no.
• Por último la solución aportada para el control de concurrencia, que no es más que añadir un campo más en la tabla de tipo entero que sirva para almacenar la verisón de la fila, si bien es sencilla y robusta no aporta tanto significado como usar un campo fecha. En este punto hay que adoptar una u otra solución. O nos complicampos la vida con los problemas derivados de que arios equipos tengan distinta fecha usando un TimeStamp , o simplemente controlamos la concurrencia sin almacenar la fecha de la última modificación usando un entero.

Resumiendo, despues del ladrillazo. Está claro que elegir una solución u otra a cada problema muchas veces solo es cuestión de gustos. Lo que si está claro es que para diseñar un ORM hay que superar ciertos obtaculso muy claros:

1. Como mapear el objeto de negocio al origen de datos.
2. Como permitir objetos almacenados en multiples tablas y tablas que alamcena multiples objetos.
3. ¿Heredar de un objeto base que provea la funcionalidad de cargar y guardar o atacar siempre a la clase que implementa la persistencia?
4. Como obtener listas filtrando por ciertas propiedades.
5. Como contemplar el caso de campos nulos en el origen de datos que no pueden ser nulos en el negocio.
6. Como controlar la concurrencia.
7. Como forzar el cacheo o no de los distintos objetos.

Sin duda, como resolver estos 7 problemas definirá la calidad del ORM.