Realización de consultas asíncronas

En este artículo se habla sobre los accesos asíncronos a base de datos, y dice que se aplica a 2 aspectos: la conexión con la base de datos, y la ejecución de un comando (consulta). Por si alguno no lo sabe, con asíncrono queremos decir que el lujo del programa no se queda bloqueado esperando la respuesta de la base de datos, como es habitual, sino que puede seguir haciendo otras cosas mientras se obtiene la respuesta (y así ofrecer una mejor sensación al usuario, que de lo contrario puede pensar que el programa está colgado cuando lo que está es esperando a la base de datos).
Parece ser que este asincronismo sólo está disponible en el framework 2.0 de .NET, no antes, lo cual me resulta extraño cuando ya era posible en ADO 2.5 (en VB6). Tal como antes, no he elaborado mucho esta información, aunque en una primera me da la impresión de que la complicación que requiere y la sobrecarga que causa hacen que sólo deba aplicarse cuando es seguro que la consulta tardará bastante. Si no, los cambios de contexto necesario (entre las hebras) serán más lentos que la propia ejecución de la consulta. ¿Es esto posible? Cuestión de probar con consultas rápidas (la mayoría), a ver qué pasa, y si usamos esta funcionalidad siempre en nuestro acceso a datos o sólo cuando se solicite expresamente.

Autogenerando la ayuda

Como hace tiempo que no publico nada, hoy lanzo algo muy poco elaborado, pero para cubrir la nómina. Se trata de un proyecto para la generación automática de ayuda sobre .NET, nDoc. Es un proyecto de código abierto (está en SourceForge) que aporta la funcionalidad de javaDoc a .NET. No sé si hay otras alternativas además de nDoc, si Microsoft está detrás o en cambio tiene otro proyecto para esto (porque algo tiene que tener, están hartos de verlo en java).
También me gustaría saber cómo elaborar más esa ayuda, ya que realmente javaDoc genera ayuda para el programador (lo cual es útil), y nDoc lo hará igual para los summary que estamos añadiendo al principio de los métodos (con ///), pero ¿cómo generar ayuda para el usuario? ¿Cómo específicar qué hace cada elemento de un interfaz de usuario, añadir imágenes e hiperenlaces (referencias mutuas), etcétera? Esto creo que queda aún muy lejos de la tecnología actual, por lo que hay que especificarlo manualmente en el bloc de notas (que es como el lenguaje ensamblador de las ayudas).

Filtrando colecciones

Estamos trabajando en EColBase, nuestro objeto genérico y raíz de las colecciones de nuestros objetos de negocio. Para ofrecer el filtrado, la ordenación... sobre una colección seguramente lo implementemos con una vista sobre un EColBase, para repartir más la funcionalidad, y para separar 2 comportamientos distintos: filtrar una colección ya cargada, y cargar una colección ya filtrada. El primer caso será el de la vista, y el segundo caso será que en lugar de cargar la colección con todos los datos de la tabla (algo que no haremos nunca salvo excepciones) pasaremos un filtro en la SQL que nos devuelve la tabla desde la que cargamos la colección. Ambos filtros, el de la vista y el de la colección (BD) deben ser coherentes y homogéneos, es decir, no usar una nomenclatura para uno y otra distinta para el otro, aunque su eficiencia y comportamiento difieran (esto estará claro por el contexto en que hacemos el filtro, sea la vista o la colección). Un modelo muy elegante y sencillo para realizar filtros es el findByExample() de este ejemplo de la web de hibernate, donde se crea un objeto de negocio ficticio y se rellena con los valores que queremos que tengan los resultados. Esto ofrece poca potencia: no permite OR, sólo AND; para hacer los filtros LIKE debemos incluir los comodines en el objeto de negocio; debemos omitir todas las reglas de negocio, lo cual no sé si será sencillo en objetos complejos; debemos crear objetos hijos (también ficticios) para realizar filtros en los que se involucren varias tablas (como albaranes que contengan el artículo determinado); no se pueden definir filtros como mayor, menor o filtros de fechas avanzados (sólo el mes de marzo, entre una fecha y otra, etcétera)...
Por todo esto, es claro que es necesario un sistema de filtros avanzados: una estructura donde indicar propiedad y filtro, siendo este filtro dependiente del tipo de datos de la propiedad, y compuesto por operador y valor (o valores), como menor que 14, o entre 1/jul y 31/jul, o como 3a semana de marzo de 2005. Esto deberá implementarse de forma que sea reutilizable entre la vista y la colección, aunque la forma de utilizar los filtros establecidos en dicha estructura sea distinta en cada caso.