I recently heard someone making skeptical statements about a Windows® Forms application and proclaiming surprise that "it even used data binding!" This made me reflect on the history of data binding over the past few generations of development tools. It brought to mind issues that existed across multiple versions of Visual Basic® and Microsoft® Access that left data binding with a bad reputation. Developers, especially the experienced ones, often see data binding as an inflexible and unreliable means of connecting a UI to data, as a technology best suited for demos but not for real-world use. In addition to these concerns, one of the biggest issues many people have with data binding is that it implies a tight coupling between the data and presentation layers of an application—a bad thing in many situations. While some of these issues were valid in the past, data binding in Windows Forms has been designed to avoid or mitigate most of these concerns. The data-binding technology in the Microsoft .NET Framework is customizable, flexible, and (since you can bind to objects, not just to database systems) it does not require you to tie your interface directly to your back-end database. Thanks to these changes, I personally use data binding whenever possible, binding to a DataView or to a strongly typed collection in almost every single one of my projects.

With so many issues resolved I am able to concentrate on my wish list of features. The first I'd like to tackle is the absence of a data-bound control that would allow users to select from a list of radio buttons. In this column, I'm going to look at how you can create your own control to get around this omission from the Windows Forms classes.