When should I be cautious using data binding in .NET?
- by Ben McCormack
I just started working on a small team of .NET programmers about a month ago and recently got in a discussion with our team lead regarding why we don't use databinding at all in our code. Every time we work with a data grid, we iterate through a data table and populate the grid row by row; the code usually looks something like this:
Dim dt as DataTable = FuncLib.GetData("spGetTheData ...")
Dim i As Integer
For i = 0 To dt.Rows.Length - 1 '(not sure why we do not use a for each here)'
gridRow = grid.Rows.Add()
gridRow(constantProductID).Value = dt("ProductID").Value
gridRow(constantProductDesc).Value = dt("ProductDescription").Value
Next
'(I am probably missing something in the code, but that is basically it)'
Our team lead was saying that he got burned using data binding when working with Sheridan Grid controls, VB6, and ADO recordsets back in the nineties. He's not sure what the exact problem was, but he remembers that binding didn't work as expected and caused him some major problems. Since then, they haven't trusted data binding and load the data for all their controls by hand.
The reason the conversation even came up was because I found data binding to be very simple and really liked separating the data presentation (in this case, the data grid) from the in-memory data source (in this case, the data table). "Loading" the data row by row into the grid seemed to break this distinction. I also observed that with the advent of XAML in WPF and Silverlight, data-binding seems like a must-have in order to be able to cleanly wire up a designer's XAML code with your data.
When should I be cautious of using data-binding in .NET?
