Data binding, a technique for displaying data without writing any code, has suffered from a poor reputation. In the past, the only applications that could use it successfully were simple report-generating tools or thin database wrappers that were typically written in a high-level language such as Visual Basic or Microsoft Access Basic. These applications were easy to program but notoriously limited, inflexible, and performed poorly.
Almost every data-binding solution suffered from the same well-known problems:
Continuous connection requirements. With traditional data binding, connections are required for long periods of time, usually as long as a window is being displayed. This might be acceptable for a small client-server application, but it won't work in a distributed environment or with a web-based application.
Little customizability. The developer can't control any part of the data binding process, has little ability to apply validation logic, and can't customize the display of most of the controls that support data binding.
Tight coupling. Data binding breaks down the separation needed for good three-tier design. Not only is it hard to reuse and likely to stop working if the structure of the data source changes, data binding code also can't be ported from one programming language or environment to another.
ADO.NET addresses these issues with a customizable and reusable data-binding framework that centers on two classes: the DataView and DataViewManager. This chapter examines these classes and explores the two data-binding models used in .NET: Windows Forms and ASP.NET.