Inminente comienzo del proyecto

El comienzo del proyecto ya es inminente, está fijado para el primero de diciembre, cuando se incorporará como becario Jorge y directamente se pondrá manos a la obra con el proyecto Sota.
Hoy voy a dejar por aquí una conversación interesante sobre la inclusión de objetos (entendemos de negocio) en un combobox: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=148896&SiteID=1. Aquí primero vemos cómo añadir objetos a un combo, en lugar de añadir simplemente sus descripciones, de forma que desde el combo tenemos acceso completo al objeto. Puede ser interesante. El objetivo de la conversación es descubrir cómo hacer, si es posible, que se actualicen los textos mostrados en el combo cuando cambiamos la descripción de los objetos. Parece que no es posible automáticamente, pero leeros la historia para conocer el final, no voy a destriparla aquí. Una cosa que se extrae del ejemplo, y que me parece muy necesaria es que todo objeto tenga una implementación del ToString(), sería una norma a añadir a nuestro libro de estilo .net. Pero volviendo a la conversación original, dejo abierta la pregunta: ¿realmente es interesante vincular los combos con los objetos que contienen, o basta con guardar su nombre e id como hemos hecho de toda la vida de Dios?

Binding en .NET 2005

Hemos hablado ya de las opciones para conectar la DAL con el negocio (BL), y ahora vamos a hablar de cómo conectar el negocio con la interfaz. Esta parte la tenía más abandonada porque desde un principio tengo más claro su diseño: hace ya tiempo que leí el artículo que vinculo en este post (el título es un vínculo), Objetos y enlace de datos de Windows Forms, donde detalla cómo hacer que un objeto de negocio se comporte como una fuente de datos. Es muy interesante, y conviene asimilarlo bien, porque aunque con .NET 2005 se han facilitado las cosas, la base que se plantea en ese artículo es la forma más directa de conseguir el binding.
Cuando hablamos de binding, nos referimos a enlazar un control de un formulario (Windows o Web) con un campo de un origen de datos. Típicamente (ya desde VB6) se podía conectar un control con un DataControl, que representaba una tabla (o consulta) de una base de datos, y este enlace va en los dos sentidos: el control carga automáticamente el dato (aplicándole un formato incluso), y al ser modificado actualiza el dato en el origen (después nosotros al hacer un Update sobre el Recordset confirmábamos esos cambios). En .NET la idea es muy similar, pero mucho más transparente, por lo que tenemos más control sobre ella. Y además se nos da la posibilidad de que el origen de datos sea un objeto de negocio en lugar de la base de datos directamente, lo que nos permite aplicar las reglas de negocio que hayamos implementado en esa clase (validaciones, propagaciones...)
Ahora en .NET 2.0 (Visual Studio 2005) se añade la idea de los DataSource, que "facilitan" enlazar los controles a los datos (lo pongo entre comillas porque también meten más objetos en la pomada, lo que en principio añade más complejidad a la idea). Tenemos inicialmente un DataSource (sobre un Dataset), que trae la idea original de VB6, pero otros tipos nuevos, entre ellos un ObjectDataSource, que permite la conexión de controles con las propiedades de un objeto de negocio sin escribir ni una línea de código para la interfaz (en teoría).
Así que una vez que tengamos clara la idea expuesta por el artículo de Lothka, vamos a profundizar por esta otra vía, a ver cual de las dos nos convence más.