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.